Re: [webkit-dev] Swift in WebKit
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] 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
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
[webkit-dev] Swift in WebKit
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 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. 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? Regards, David Farler ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
Hi David, I think it is a bit too early to start using Swift in WebKit, especially since the language is still evolving. Eventually, I think we should start using it, but I’d like for it to settle a bit before we do. - Sam On Jul 28, 2014, at 12:47 PM, David Farler 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 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 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. 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? Regards, David Farler ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
Two concerns that came up today: (1) A binary built with Swift today can only run if the client individual has the same version of Xcode installed. (Is this true?) (2) The language and implementation are still changing in breaking ways. Geoff On Jul 28, 2014, at 2:21 PM, Sam Weinig wei...@apple.com wrote: Hi David, I think it is a bit too early to start using Swift in WebKit, especially since the language is still evolving. Eventually, I think we should start using it, but I’d like for it to settle a bit before we do. - Sam On Jul 28, 2014, at 12:47 PM, David Farler 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 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 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. 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? Regards, David Farler ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 2:57 PM, Geoffrey Garen gga...@apple.com wrote: Two concerns that came up today: (1) A binary built with Swift today can only run if the client individual has the same version of Xcode installed. (Is this true?) Not sure if it's true (I haven't hit this) but I wouldn't be surprised if there are ABI-breaking changes across beta releases, especially regarding the underlying bridging to the Objective-C runtime. I don't know how often that will happen long term. I should mention though that LayoutTestRelay will inherently have a dependency on CoreSimulator.framework inside the Xcode.app bundle, so if LTR is built against a particular location, it will have to either be rebuilt or have its rpath adjusted if using the common /Applications/Xcode.app location, regardless of the language. (2) The language and implementation are still changing in breaking ways. Yep, I concede to this. My only question in response is whether it's valuable to observe those changes in a project like this or even to use a project like this to investigate other points of discussion, like: - Is there one Swift coding style? If not, what's ours? - What do we need to implement in spite of, or for lack of, a standard library feature? Or, just save all that for a rainy day, I suppose. David Geoff On Jul 28, 2014, at 2:21 PM, Sam Weinig wei...@apple.com mailto:wei...@apple.com wrote: Hi David, I think it is a bit too early to start using Swift in WebKit, especially since the language is still evolving. Eventually, I think we should start using it, but I’d like for it to settle a bit before we do. - Sam On 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 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. 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? Regards, David Farler ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
(2) The language and implementation are still changing in breaking ways. Yep, I concede to this. My only question in response is whether it's valuable to observe those changes in a project like this or even to use a project like this to investigate other points of discussion, like: - Is there one Swift coding style? If not, what's ours? - What do we need to implement in spite of, or for lack of, a standard library feature? Or, just save all that for a rainy day, I suppose. Interesting. I think it might be valuable to do these things in a limited project, if we can minimize the downside of breaking changes. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 4:38 PM, Geoffrey Garen gga...@apple.com wrote: (2) The language and implementation are still changing in breaking ways. Yep, I concede to this. My only question in response is whether it's valuable to observe those changes in a project like this or even to use a project like this to investigate other points of discussion, like: - Is there one Swift coding style? If not, what's ours? - What do we need to implement in spite of, or for lack of, a standard library feature? Or, just save all that for a rainy day, I suppose. Interesting. I think it might be valuable to do these things in a limited project, if we can minimize the downside of breaking changes. Geoff I’d also be okay with allowing Swift, in this limited fashion, as an experiment. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
On Mon, Jul 28, 2014 at 12:47 PM, David Farler 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 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 In particular see Maciej's response in https://lists.webkit.org/pipermail/webkit-dev/2011-December/018865.html. 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. 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. It would increase the entry barrier of working on those tools even if they were specific to one platform. 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? 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Swift in WebKit
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
Re: [webkit-dev] Swift in WebKit
On Mon, 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: On Mon, Jul 28, 2014 at 12:47 PM, David Farler 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 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 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. Swift is an unsupported third-party language for people who don't work on Mac or iOS ports. 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. In my personal opinion, hip and exciting should never be a reason to do anything. However, we can agree to disagree here since this is a very subjective topic. 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?* Yes. Every new programming language we introduce into the project introduces a new entry barrier to hack on the project. Namely, everyone who ever has to modify that code need to learn Swift in addition to Objective-C/C++, which is used to write some parts of since Mac/iOS ports. I personally hate Objective-C syntax and would prefer using something like Swift. However, that preference doesn't outweigh the overall cost of introducing a new programming language into the project of this size with so many contributors. 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? There has been no indication that Objective-C will be deprecated anytime soon. 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. That's great to hear since the cost of using Swift is proportional to the number of people who have to maintain the tool. If you're the only who has to touch the codebase, then the cost is virtually zero given that you seem to already know about Swift. 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 and https://bugs.webkit.org/show_bug.cgi?id=135271). It doesn't exist
Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jul 28, 2014 at 8:44 PM, David Farler dfar...@apple.com mailto:dfar...@apple.com wrote: 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. Swift is an unsupported third-party language for people who don't work on Mac or iOS ports. 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. In my personal opinion, hip and exciting should never be a reason to do anything. However, we can agree to disagree here since this is a very subjective topic. 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? Yes. Every new programming language we introduce into the project introduces a new entry barrier to hack on the project. Namely, everyone who ever has to modify that code need to learn Swift in addition to Objective-C/C++, which is used to write some parts of since Mac/iOS ports. I personally hate Objective-C syntax and would prefer using something like Swift. However, that preference doesn't outweigh the overall cost of introducing a new programming language into the project of this size with so many contributors. 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? There has been no indication that Objective-C will be deprecated anytime soon. 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. That's great to hear since the cost of using Swift is proportional to the number of people who have to maintain the tool. If you're the only who has to touch the codebase, then the cost is virtually zero given that you seem to already know about Swift.
Re: [webkit-dev] Swift in WebKit
On Mon, Jul 28, 2014 at 10:30 PM, David Farler dfar...@apple.com wrote: On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, 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: On Mon, Jul 28, 2014 at 12:47 PM, David Farler 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 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 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. Swift is an unsupported third-party language for people who don't work on Mac or iOS ports. 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. In my personal opinion, hip and exciting should never be a reason to do anything. However, we can agree to disagree here since this is a very subjective topic. 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?* Yes. Every new programming language we introduce into the project introduces a new entry barrier to hack on the project. Namely, everyone who ever has to modify that code need to learn Swift in addition to Objective-C/C++, which is used to write some parts of since Mac/iOS ports. I personally hate Objective-C syntax and would prefer using something like Swift. However, that preference doesn't outweigh the overall cost of introducing a new programming language into the project of this size with so many contributors. 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? There has been no indication that Objective-C will be deprecated anytime soon. 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. That's great to hear since the cost of using Swift is proportional to the number of people who have to maintain the tool. If you're the only who has to touch the codebase, then the cost is virtually zero given that you seem to already know about Swift. 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
Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 22:42, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jul 28, 2014 at 10:30 PM, David Farler dfar...@apple.com wrote: On Jul 28, 2014, at 9:31 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, 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: On Mon, Jul 28, 2014 at 12:47 PM, David Farler 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 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 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. Swift is an unsupported third-party language for people who don't work on Mac or iOS ports. 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. In my personal opinion, hip and exciting should never be a reason to do anything. However, we can agree to disagree here since this is a very subjective topic. 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? Yes. Every new programming language we introduce into the project introduces a new entry barrier to hack on the project. Namely, everyone who ever has to modify that code need to learn Swift in addition to Objective-C/C++, which is used to write some parts of since Mac/iOS ports. I personally hate Objective-C syntax and would prefer using something like Swift. However, that preference doesn't outweigh the overall cost of introducing a new programming language into the project of this size with so many contributors. 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? There has been no indication that Objective-C will be deprecated anytime soon. 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. That's great to hear since the cost of using Swift is proportional to the number of people who have to maintain the tool. If you're the only who has to touch the codebase, then the cost is virtually zero given that you seem to already know about Swift. It’s just a proxy to a simulator app's standard file
Re: [webkit-dev] Swift in WebKit
On Jul 28, 2014, at 12:47 PM, David Farler dfar...@apple.com wrote: - Swift is a fully supported, albeit new, language starting in Xcode 6. I think you missed a word off the end of this sentence – Swift support is available in Xcode 6 beta. ;-) Too soon. G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
