> On Jul 29, 2014, at 00:14, Maciej Stachowiak <m...@apple.com> wrote:
>
>
>> On Jul 28, 2014, at 8:44 PM, David Farler <dfar...@apple.com> wrote:
>>
>>> On Jul 28, 2014, at 17:10, Ryosuke Niwa <rn...@webkit.org> wrote:
>>>
>>
>>> In particular see Maciej's response in
>>> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html.
>>
>> From the second e-mail:
>>
>> "In conclusion, I think we should be very hesitant to introduce new
>> languages for tools unless there are massive benefits that cannot be
>> achieved with any of the languages that the WebKit project already uses.”
>>
>> I myself am hesitant, hence the e-mail, but I think there is more to the
>> picture here regarding the two languages which I outline below.
>
> I think Swift is worth considering, but I think my argument in that email
> still holds. Any new language added increases the number of languages you
> have to potentially understand to work on WebKit, a number which is already
> quite high (C, C++, Objective-C, Objective-C++, Perl, Python, Ruby, shell
> scripts, probably others).
>
> I feel like there’s not a great basis for approving of Swift when I objected
> to Go, so for consistency’s sake I have to at least mildly object.
>
>> For everyday automation tasks, I agree that we should continue to converge
>> on Python because of its coverage across platforms, one-way-to-do-it-ness,
>> strong style guidelines, large standard library, popularity, easy to learn,
>> etc. It’s one of my goals to do just that and create a strong, unified,
>> hackable, well-documented tools platform. I wouldn't advocate that
>> automation be written in Swift.
>
> Why would this tool be an exception to the general approach of using Python
> for tools? Is it just because of the bindings to the CoreSimulator framework?
> Would ObjC be your only alternative? I have a hard time understanding the
> rest of your message because it’s all about comparing Objective-C to Swift,
> but we don’t normally use ObjC as a tools language.
>
> [snip]
In this particular case, Obj-C is the only alternative. I originally started
this effort with PyObjC and after discussing it more with the framework's
author I was sufficiently convinced it wouldn't be a good idea after some
technical problems.
>
>> Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a
>> stretch to think of these as major achievements:
>>
>> - Modern type inference (although it could’ve gone a few steps further, IMO)
>> - Static types
>> - Sum types
>> - Enforced optional/maybe type
>> - Promotion of immutability
>> - Safer usage or downright omission of pointers
>> - Better numeric type conversion (IMO)
>> - Enforced initialization of objects
>> - Nice Unicode string primitives
>> - Low resistance to reasonable functional programming patterns
>> - Generics with constraints
>> - Pretty fast
>> - Terse syntax
>> - String interpolation with expressions
>> - No class prefixes needed
>
> Why is Objective-C the relevant point of comparison here? We don’t use much
> Obj-C in WebKit. It’s basically limited to the glue needed to be a public
> framework on OS X and iOS, and to call system APIs that are only offered in
> Obj-C, often mingled with C++ code. Unfortunately it’s not possible at this
> time to replace Obj-C with Swift for either of these uses. I do think it is
> possible that someday Swift will support that and that WebKit would likely
> make use of it.
>
> Also worth noting: anyone could make a similarly long list of bullet points
> for their preferred language of choice. It would be a bad precedent to accept
> such an argument or we’ll end up with even more different programming
> languages used for our tools.
>
> Cheers,
> Maciej
OK. It sounds like there isn't enough interest so I will rework the patch.
Thanks,
David
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
