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.
Working for a well known chip company here. I'm one of the DB guys. I know we dumped out in-house iOS team when the whole "port to Swift" BS started. Management took one look at the cost and out-sourced the lot to east Europe.
gcc has an Objective-C compiler. It’s just as standard as the C and C++ compilers, though your package manager almost certainly have it as a separate package from the C and C++ compilers (which are, themselves, also usually separate).
It’s not particularly difficult to get your hands on an Objective C compiler.
...And that was true of Obj-C for the last 30 years, so... yeah, solid argument there....
Obj-C was not developed by Apple. It was used by Apple (and, btw, NeXT), but it was developed separately from Apple by StepStone.
Because Apple used Pascal, then extended it to object pascal. Then people wanted C, but they needed object semantics to port the object pascal libraries and C++ wasn't ready and was ugly as sin, so they went with Objective C, which is uglier. They were swept along with the stream like everyone else.
The real problem with Swift is not the language, it's that when you try to use swift to program a mac or iphone, you spend most of your programming time interacting with the libraries in arbitary ways invented by Apple and every example on the internet seems to be written in Objective-C. You're left guessing at what the Swift equivalent would look like.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Every linux distro that installs the gcc suit has an objective-C compiler ...
And if you really want to: a Switft compiler to, directly from swift.org: https://swift.org/download/
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
You have your history completely wrong.
Objective-C was created by Dr. Brad Cox in the Mid 1980s - https://en.wikipedia.org/wiki/...
Objective-C is a mashup of ANSI C and Smalltalk. Smalltalk is the original Object Oriented programming language created by Alan Kay in the 1970s. Alan Key coined the term, "Object Oriented", to describe Smalltalk. He later said, "I coined the term Object Oriented, and I promise, C++ is not what I had in mind." He has also said he wished he called Smalltalk "Message Oriented" because messages are the key, not objects.
Steve Job's NeXT Computer Corp. used Objective-C to create NeXTstep graphical frameworks currently known as Cocoa (Foundation Kit, App Kit, etc.) and Cocoa Touch (UIKit etc.) NeXTstep shipped commercially in October 1988.
Apple purchased NeXT in December 1996, and NeXtstep eventually became Mac OS X and iOS.