<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote type="cite"><div>On Jul 28, 2014, at 8:44 PM, David Farler <<a href="mailto:dfarler@apple.com">dfarler@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On Jul 28, 2014, at 17:10, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" class="">rniwa@webkit.org</a>> wrote:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><br></div></blockquote><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">
</div><div class="">In particular see Maciej's response in <a href="https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html" class="">https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html</a>.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">From the second e-mail:</div><div class=""><br class=""></div><div class="">"<span style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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.</span>”</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>[snip]</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Fine, twist my arm. :) In comparison to Objective-C, I don’t think it’s a stretch to think of these as major achievements:<br><div class=""><br class=""></div><div class="">- Modern type inference (although it could’ve gone a few steps further, IMO)</div><div class="">- Static types</div><div class="">- Sum types</div><div class="">- Enforced optional/maybe type</div><div class="">- Promotion of immutability</div><div class="">- Safer usage or downright omission of pointers</div><div class="">- Better numeric type conversion (IMO)</div><div class="">- Enforced initialization of objects</div><div class="">- Nice Unicode string primitives</div><div class="">- Low resistance to reasonable functional programming patterns</div><div class="">- Generics with constraints</div><div class="">- Pretty fast</div><div class="">- Terse syntax</div><div class="">- String interpolation with expressions</div><div class="">- No class prefixes needed</div></div></blockquote><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Maciej</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>