Slashdot Mirror
Four Years On, Developers Ponder The Real Purpose of Apple's Swift Programming Language (monkeydom.de)
Programming languages such as Lua, Objective-C, Erlang, and Ruby (on Rails) offer distinct features, but they are also riddled with certain well-documented drawbacks. However, writes respected critic Dominik Wagner, their origination and continued existence serves a purpose. In 2014, Apple introduced Swift programming language. It has been four years, but Wagner and many developers who have shared the blog post over the weekend, wonder what exactly is Swift trying to solve as they capture the struggle at least a portion of developers who are writing in Swift face today. Writes Wagner: Swift just wanted to be better, more modern, the future -- the one language to rule them all. A first red flag for anyone who ever tried to do a 2.0 rewrite of anything.
On top of that it chose to be opinionated about features of Objective-C, that many long time developers consider virtues, not problems: Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs. [...] It keeps defering the big wins to the future while it only offered a very labour intensive upgrade path. Without a steady revenue stream, many apps that would have just compiled fine if done in Objective-C, either can't take advantage of new features of the devices easily, or had to be taken out of the App Store alltogether, because upgrading would be to costly. If you are working in the indie dev-scene, you probably know one of those stories as well. And while this is supposed to be over now, this damage has been done and is real.
On top of all of this, there is that great tension with the existing Apple framework ecosystem. While Apple did a great job on exposing Cocoa/Foundation as graspable into Swift as they could, there is still great tension in the way Swift wants to see the world, and the design paradigms that created the existing frameworks. That tension is not resolved yet, and since it is a design conflict, essentially can't be resolved. Just mitigated. From old foundational design patterns of Cocoa, like delegation, data sources, flat class hierarchies, over to the way the collection classes work, and how forgiving the API in general should be. If you work in that world you are constantly torn between doing things the Swift/standard-library way, or the Cocoa way and bridging in-between. To make matters worse there are a lot of concepts that don't even have a good equivalent. This, for me at least, generates an almost unbearable mental load.
On top of that it chose to be opinionated about features of Objective-C, that many long time developers consider virtues, not problems: Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature. Define the convenience and elegance of nil-message passing only as a source of problems. Classify the implicit optionality of objects purely as a source of bugs. [...] It keeps defering the big wins to the future while it only offered a very labour intensive upgrade path. Without a steady revenue stream, many apps that would have just compiled fine if done in Objective-C, either can't take advantage of new features of the devices easily, or had to be taken out of the App Store alltogether, because upgrading would be to costly. If you are working in the indie dev-scene, you probably know one of those stories as well. And while this is supposed to be over now, this damage has been done and is real.
On top of all of this, there is that great tension with the existing Apple framework ecosystem. While Apple did a great job on exposing Cocoa/Foundation as graspable into Swift as they could, there is still great tension in the way Swift wants to see the world, and the design paradigms that created the existing frameworks. That tension is not resolved yet, and since it is a design conflict, essentially can't be resolved. Just mitigated. From old foundational design patterns of Cocoa, like delegation, data sources, flat class hierarchies, over to the way the collection classes work, and how forgiving the API in general should be. If you work in that world you are constantly torn between doing things the Swift/standard-library way, or the Cocoa way and bridging in-between. To make matters worse there are a lot of concepts that don't even have a good equivalent. This, for me at least, generates an almost unbearable mental load.
Please identify the (de-jure) standard for VBA. "Microsoft's current compiler" is not a -standard-.
> Classify the implicit optionality of objects purely as a source of bugs
Among other issues, this remains my biggest complaint.
Obj-C generally "did the right thing" with nil in most contexts. Sure, nil-pointer errors are a pain, but declaring them away and just forcing everyone to type ! everywhere does not eliminate them. It does, however, eliminate the simplicity of binding a nil to a text field and just getting a zero, precisely what has to happen in code now.
Needs to find a way to provide intuitive usage of all those cores. One of the reasons C was so successful was it abstracted the hardware into a human understandable model. One of the problems with all the new languages is they try to fit a square peg in a round hole and ignore how the hardware works. Yes hardware has gotten much much much faster, but so much of that speed has been consumed with layers and layers and layers of abstraction. If someone figures out how to do what C did for uni-processor computers on multi-cores, that will be gold.
I was a huge fan of Objective-C. I still think it's an elegant language. I love the delegate patterns, I love the quirky stuff like method swizzling, I love the runtime message passing.
When Swift first came out, it was really rough. The Obj-C bridge APIs were all using forced-unwrapped optionals and the like, and Apple didn't do a great job explaining why all of that was in place. Only with Swift 2, 3, and 4 did it become clear that you should never force-unwrap unless using some crufty API that required it (which it turns out is almost never these days).
I do miss some things like nested message passing, but I also don't miss a lot of things. I love the map, reduce, and filter capabilities, I like the more nuanced closures vs completion blocks. There are still things that frustrate me, but they generally get better every year. Swift is one of my favorite languages to code in these days.
- Vincit qui patitur.
It is pretty hard to avoid vendor lock-in due to APIs nowadays.
And of all the languages, I daresay Swift is one of the few that's in a clear direction heading away from vendor specificity and toward open access.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
Apple really likes to play up Objective-C as the competitor to Swift, but the elephant in the room is Objective-C++, which (since C++11) is a far better language than either. You can have the late binding of Objective-C objects and the compile-time specialisation of C++ templates and switch between them easily. With ARC, you can store Objective-C object pointers inside C++ collections and have the memory management work properly (which was the biggest irritation of pre-ARC Objective-C++). If you use C++ objects as instance variables in Objective-C, then their destructors run automatically after -dealloc, so the memory management works both ways (you can, for example, use C++11 unique_ptr or shared_ptr to manage ownership of non-Objective-C resources by Objective-C++ objects). Most importantly, it has a trivial way of using C++ libraries, something that Swift can achieve only if you wrap them in [Objective-]C.
I am TheRaven on Soylent News