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.
Apps written in different languages are hard to compile across platforms.
Please identify the (de-jure) standard for VBA. "Microsoft's current compiler" is not a -standard-.
Don't look for reasons why Swift may be technically superior. Look for reasons why Apple wants Swift to keep developers locked inside the Apple world. Every minute that a developer uses to learn Swift, is a minute not spent on learning a non-Apple technology.
The only criteria that's relevant if you're already supporting a profitable application on either iOS or OS X platforms - maintainable. How fast does a language enable the rev of your code base, does it abstract your code base above platforms and can its libraries and API's bridge between manufacturer hardware swaps and recompiles without cost of a total rewrite.
Those were lessons learned during NeXT transitions from little to big endian and Mac OS X revs that Apple made 3X/yr during SteveJobs reign.
https://xkcd.com/927/
Escher was the first MC and Giger invented the HR department.
Firstly itâ(TM)s not lock in any more than objc is. No other (serious) platform uses objc. So stop whining about lock in. Programmers on the Apple platforms donâ(TM)t give a crap about that anyway. Weâ(TM)re there because we want to be. And most of us learned objc after learning other languages, because the iOS sdk hasnâ(TM)t been around forever, so we all came from other languages. We arenâ(TM)t so stupid we canâ(TM)t learn something else, kthx.
Secondly it addresses some real pain points from objc. One is verbosity. Another is the fact that nil objects donâ(TM)t crash the app which makes bugs hard to find. Inconsistent message vs function call syntax. Inconsistent property vs method syntax. I could go on and on.
Thirdly it addresses type safety. Objc will let you have an array of id, which is like having an array of java.lang.Object and trusting the programmer to use it appropriately. Anyone who argues that strong type safety isnâ(TM)t better has never worked outside of some niche application. This is enough of a pain point with objc that it deserves its own paragraph.
Fourthly it brings functional programming to the table better than objc. Yes you can pass blocks around in objc but itâ(TM)s syntactically painful where as Swift makes it easy (aka first class citizen).
I could continue but Iâ(TM)m tired of typing on my phone. The point is there actually are plenty of real world gains in Swift.
Outside of /. where everyoneâ(TM)s mind is already made up and Apple is the devil, I donâ(TM)t know anyone that has used swift for real who doesnâ(TM)t think itâ(TM)s massively superior to objc.
Is it finalized? No. Itâ(TM)s a language in flux and theyâ(TM)re taking community feedback too. So everyone is an early adopter by definition and they expect some upgrade pain. Itâ(TM)s really not that bad in practice and Xcode handles 90% of it. Itâ(TM)s no worse than switching to a new iOS version and dealing with depreciations every year.
Again, weâ(TM)ve all chosen the platform and the language because we think itâ(TM)s superior. We arenâ(TM)t stupid. We arenâ(TM)t locked in. We all know other languages. Thanks.
Cue the haters.
There is a pattern and it is like this
- School do not teach anymore why things are done the way they are, the reasons
- Students are not interested, have low attention span, generally consider the teaching "old stuff"
- Computer science is populated by freshers, you are old at 40
the result is:
- Reinventing the same solution, worse
How to stop this total waste of time,money ?
- Keep older developer around and when they say that the "new shiny idea" has been done before, listen to them.
A list of already done things:
1) AI (in the current form), it is Neural net, learned 30 years ago, yes, now you have a supercomputer on desk but it is not new tech and has all the same issues it had before.
2) Blockchain, can anybody think of a revision system ? GIT, SVN ?
3) Languages, lots of them, really, are we so dumb that to save a few keystrokes we produce something that is obscure after the third line ?
Can we agree that all possible logic and consistency tests should be done at "compile time" ? (no Unit testing is not the same thing)
FInally, a question: How do we get rid of the pointy haired boss ? (See Dilbert)
He knows nothing, makes random decisions (on a good day) and sucks half of the budget in bonuses...
> 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.
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?''
Are you saying I can take a Swift app designed for macOS or iOS and recompile on Linux with almost no effort? If most of the frameworks are not ported as well it is not really a viable solution. For C# there is Mono and even this is not getting a huge traction beyond a few projects.
Most programmers aren't going to write directly against a graphics API either, but those APIs are typically consumed by big engines that are written in C/C++, for good reasons, and it is hard to write swift that calls C/C++ and vice versa.
Actually, you should separate the language from (OS-specific) libraries.
For example, we are currently developing a large-scale software consisting of various components.
Some servers are written in GoLang and some others are written in Swift.
The beauty is that the part that is written in Swift can be developed & tested on MacOS directly in Xcode. This server-component is written by a former iOS/macOS-developer, who knows Swift very well.
The runtime environment is Linux. So, we develop on Linux AND macOS (depending on what each developer knows best), in Swift AND GoLang and since all server components communicate using REST-API with each other, nobody really cares which language is used - as long as it works.
Our experience so far with developing server (or: systems-)software with Swift (4.x) is really great. The turnaround times are very short since the developer in question already knew all the Swift-quirks.
Of course, we don't use any macOS libraries at all, only those that come with standard Swift for Linux (plus some FOSS libraries).
When the whole system is up and running, we will evaluate both languages on performance (development- & runtime), cost, maintainability and decide whether we continue doing it in both languages or decide for one or the other.
So, I don't really see a walled-garden here...
Is Linux a 'walled garden' since we can't take software using Linux-specific APIs like cgroups and ALSA and evdev and easily compile/run them on OSes like macOS and Windows?
Exactly this.
So many Slashtards want to assign the epithet "Walled Garden" to ANYTHING Apple does, regardless of how much they Open Source it, or make it as platform-agnostic as possible.
It's just ridiculous.
Indeed. Sell it as the next greatest thing that everybody must use and then, when everybody not too smart is on it, change is so that there is no way out, support on other platforms gets very difficult and independent implementation become non-viable. Pretty classical attack.
And name me other Apple Open Source projects where they have employed your paranoid business plan.
Bonjour: Open Source, and certainly not Apple-Specific.
launchd: Open Source, and certainly not Apple-Specific.
GCD: Open Source, and certainly not Apple-Specific.
Webkit: Open Source, and certainly not Apple-Specific.
Swift: Open Source, and certainly not Apple-Specific.
OpenCL: Open Source, and certainly not Apple-Specific. (In fact, now even Deprecated by Apple).
CUPS: Acquired by Apple, and continues as non-Apple Specific Open Source.
LLVM: Open Source, and certainly not Apple-Specific.
Clang: Not Apple owned, but Apple is the major contributor to the Open Source Project.
ResearchKit, CareKit. Open Source iOS Projects that are apparently not Apple-Specific.
Darwin: Open Source, and somewhat non Apple-Specific. ...and many more.
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