On Jul 28, 2014, at 17:10, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
> On Mon, Jul 28, 2014 at 12:47 PM, David Farler <dfar...@apple.com
> <mailto:dfar...@apple.com>> wrote:
> Hello all,
>
> I have the following bug to help build out support for layout tests in the
> iOS Simulator.
>
> iOS Simulator LayoutTestRelay
> https://bugs.webkit.org/show_bug.cgi?id=135269
> <https://bugs.webkit.org/show_bug.cgi?id=135269>
>
> I'd like to include this as a new tool written in Swift.
>
> Why I think it's fine in this case:
> - This tool is specific to the iOS and OS X platforms
> - Swift is a fully supported, albeit new, language starting in Xcode 6.
> - Swift is probably the best way to get Objective-C bridging "for free" in
> the long term
> - Swift supports script-like "immediate mode" with good JIT-compiled
> performance
> - The tool's size and scope is sufficiently small with no complex or
> WebKit-specific dependencies
>
> There is a precedence of WebKit rejecting the use of new programming
> languages in the past:
> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html
> <https://lists.webkit.org/pipermail/webkit-dev/2011-December/018837.html>
Precedence drives opinions of law, for which reinterpretations are considered
to be an unfortunate correction. I don’t think it should be invoked to hamper
creativity or reject something “new”. Still, the main difference to that case
is that Swift is not an unsupported third-party language, it won’t require
installation of new software, and it’s not for cross-platform automation.
> In particular see Maciej's response in
> https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html
> <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.
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.
> I understand that its freshness and continual evolution means that we won't
> reviewer support relative to our C family languages. I would argue that it
> will be difficult to subjectively tell when the time is "right", that a good
> way to solve that is to start using the language itself, and take an
> incremental approach to crafting the Swift story in WebKit. Using it for some
> simple tools is a good place to start.
>
> Could you clarify what the advantage of using Swift is? Personally, I'm not
> interested in learning a yet another platform-specific language to hack on
> WebKit.
Sure. There is a book, website, blog and conference touting the advantages of
Swift. :) I’m not going to fall into the trap of trying assume responsibility
for articulating what has already been said there because I’ll surely not do as
good of a job, but I’ll provide some enticing bullets below. If you took the
time to learn and use it, I think you would appreciate the advantages and
disadvantages more and would be excited for its future. I am.
For this project, I think it’s a valid exploration for code that would already
have to use platform-specific Objective-C. Of course, I wouldn’t presume to
argue that all of OS X and iOS WebKit code should move to Swift at this point.
However, I reject thinking that leads one to only consider a new possibility
when the current situation is unbearable or even painfully obvious.
> I'm not saying that Swift is a bad language or anything but I don't want to
> start having people writing random programming languages such as Haskell,
> Scala, Go, Rust, etc... deemed hip/cool at the time to create new tools in
> WebKit.
Of course. The main difference is that I don’t deem it hip; it’s a fully
supported, productized language that ships with Xcode and it’s only going to
grow in use on OS X and iOS. Even so, that Swift is hip and exciting shouldn’t
be ignored. Developing WebKit should be as exciting to hack as much as it is an
exemplary web framework too, as both motivations work together to make it
better.
> It would increase the entry barrier of working on those tools even if they
> were specific to one platform.
It is something new to learn. Is it a barrier? I don’t think so. I think it’s
an opportunity. We assumed Objective-C in the first place because it was the
only way to write apps and frameworks on OS X and iOS. Now that's no longer
true and, while both languages are supported, if someone didn’t think it was
the way forward, I don’t think it would exist in the first place since
Objective-C does a pretty good job already and it could’ve been extended
incrementally. That’s my perspective. Obviously it’s not going anywhere anytime
soon but, if Objective-C were deprecated in the future, and we suddenly decided
we needed reviewers who knew Swift, where would we look?
> e.g. what should GTK+/EFL contributors do if they wanted to modify the way
> webkitpy works and needed to make changes to your tool? Or do you think such
> a scenario is extremely unlikely?
Given the pace of webkitpy development … :)
I do think it’s unlikely. It’s just a proxy to a simulator app's standard file
descriptors which are only accessible indirectly and I’m happy to say that it
somewhat pays for its debt by removing lots more platform-specific code than it
creates (https://bugs.webkit.org/show_bug.cgi?id=135374
<https://bugs.webkit.org/show_bug.cgi?id=135374> and
https://bugs.webkit.org/show_bug.cgi?id=135271
<https://bugs.webkit.org/show_bug.cgi?id=135271>). It doesn’t exist to automate
but make it possible to run layout tests on the simulator with the current
tools. Essentially, it pretends to be DRT/WKTR, so it has the same I/O behavior
requirements as those tools.
>
> The larger discussion of using Swift in larger AOT-compiled contexts but is
> probably going to happen in this thread anyway, so let's have it:
>
> What of future use of Swift in WebKit?
>
> I would really like to know why we should use Swift in WebKit at all in the
> current stage?
>
> - R. Niwa
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
Reasons to not use it at the current stage:
- Needs more standard library features (IMO)
- Possible ABI changes
- Possible syntax changes
- No Swift++, have to use C or Objective-C call sites
David
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
