[webkit-dev] Swift in WebKit

[David Farler]

> On Jul 29, 2014, at 00:14, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> 
>> On Jul 28, 2014, at 8:44 PM, David Farler <dfarler at apple.com> wrote:
>> 
>>> On Jul 28, 2014, at 17:10, Ryosuke Niwa <rniwa at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20140729/bb69c172/attachment-0001.html>