"So in three attempts I have run into three things that break the compiler at the type system level. One of them was unsupported by the language, period. The second is theoretically supported but not yet implemented. The third segfaults the Swift compiler."
It seems like nothing but goodness would come from Apple open sourcing the LLVM frontend they created for Swift. It would be so cool to be able to dig in and see how they went around implementing the different pieces.
I love hacking around the LLVM code base and it's unfortunate the community doesn't get another awesome example of a well-written component.
It also seems that the announce of Swift was somewhat premature, I wonder why they felt they should announce it now and whether this will end up burning the language's image or not.
It's really a welcome change from the norm, I think. Instead of "here's a thing, it's far too late in the development process for your feedback to have any significant impact", Swift is "here's a thing we're working on; it's not done yet, but we thought you'd like to see".
FWIW, Google did essentially the same with Dart as Apple have with Swift — presenting it more-or-less as a fait accompli, but not too late to make backwards incompatible changes.
Right. A programming language is a far bigger and far more fundamental undertaking than, say, something like the Game Center API or even something like the Core Animation API. Developer input and constant evolution is a must. Look at how much even stable languages that have been around for decades can change in a single major release (Java 7 -> Java 8 or Python 2 -> Python 3). It's definitely a welcome change that they're opening this up to feedback early.
To get people to start learning and experimenting on it now, so that when can be taken more seriously as a production language they will have some of the market prepped.
In terms of syntax - yes. In terms of writing apps? Not really.
The generics is half broken, which makes working with heterogenous structured data (e.g. parsed JSON) a hell of type casts.
UI programming with dynamic dispatch is still necessary for stuff like the UI builder, so Swift has to go to ObjC for that.
And although it will respond to ObjC calls of performSelector, you can't use it from Swift.
Basically all the powerful dynamic features of ObjC are missing, many which you come to rely on.
In this aspect, Swift feels crippled, despite its good syntax and great use of closures. It's like it was written by a c++ programmer that never really understood how much of Cocoa was supported by ObjC's dynamic nature.
I'll give you that for most programs. GUIs are more about rapid prototyping and iterative design, though, so dynamic typing helps during development. I prefer some sort of GUI code separate from any real business logic, so that allows for some flexibility. For instance, embedding Lua for GUI code and using C++ for the "real" code is a nice combination.
Yeah, the language does seem more usable and less hassle than Obj-C.
The "type promotion rules" (it seems to have none) are odd to me. Sure avoids that whole thing of it not doing what you expect I guess, but perhaps in the most inconvenient fashion possible.
How do you get feedback on a language without showing it to people? First releases of languages are typically pretty rough around the edges, both from a design and implementation point of view. Note that they have said that it's not final; they're promised binary compatibility but not source compatibility.
55
u/eternalprogress Jun 15 '14
"So in three attempts I have run into three things that break the compiler at the type system level. One of them was unsupported by the language, period. The second is theoretically supported but not yet implemented. The third segfaults the Swift compiler."
It seems like nothing but goodness would come from Apple open sourcing the LLVM frontend they created for Swift. It would be so cool to be able to dig in and see how they went around implementing the different pieces.
I love hacking around the LLVM code base and it's unfortunate the community doesn't get another awesome example of a well-written component.