Why Apple’s Swift Language Will Instantly Remake Computer Programming
wired.com
wired.com
"Google unveiled a language called Go in 2009, and though it was designed by some of the biggest names in the history of software design—Ken Thompson and Rob Pike—it’s still struggling to gain a major following among the world’s coders. But Swift is a different animal. When it’s officially released this fall, it could achieve mass adoption with unprecedented speed, surpassing even the uptake of Sun Microsystems’ Java programming language and Microsoft’s C# in the late 1990s and early 2000s."
I didn't note any mention of the fact that Objective-C and now Swift are (to a first approximation) the only ways of writing apps for Apple's major products. Go is struggling? They're comparing it to Java, a language intended for universal use, and it hasn't been released yet?
"...an enormous number of programmers have an immediate reason to use Swift. Today, hundreds of thousands of developers build apps for iPhones and iPads using a language called Objective-C, and due to the immense popularity of Apple’s consumer gadgets, these coders will keep building such apps. But Swift is a significant improvement over Objective-C—in many respects—and this means the already enormous community of iPhone and iPad developers are sure to embrace the new language in the months to come."
I understand they help to sell, but I decided to cut down dramatically on the amount of time I spend reading about shit some random guy on the Internet thinks I absolutely need to {stop,begin,avoid} doing, and this rule of thumb helps quite a bit.
Sad to say, I guess that the vast majority of the stuff we read won't make our life appreciably better.
That being said, one might sure find entertainment value in a certain kind of submissions.
Thanks for the pointer, I will give the story a chance.
My biggest issue with Swift is that there often seem to be too many ways to do things. I'm fine with having options, but when there are literally 4 or 5 different ways to accomplish the same things it's going to require development shops to come up with rigid standards about how to do things. Many shops aren't going to know that this will be an issue until later, when trying to integrate the work of different developers / teams on a large project.
The upside of this level of flexibility is that it allows you to quickly port code from nearly any language into Swift since it supports the features of almost every modern language. The downside, of course, comes when starting a new project: you have a lot of decisions to make about how functions will be called, objects instantiated and referenced, etc. If you don't make those decisions up-front, peoples' preferences will take over and you'll get a lot of spaghetti code. I'm not looking forward to starting a project in Swift, that's for sure.
From a technical perspective, I have no complaints: Swift is flexible and powerful without being weighed down by the kludges that Objective-C forced you into. But I definitely see small dev shops having a big advantage with Swift in the beginning: it'll simply take the big guys too long to get their act together.
This is my biggest issue with the Apple libraries in general. It's an artifact of the software's bloodline running back to the 80s.
I don't like the comparisons to Go in this article. I'm an iOS developer who has dabbled in Go, and I'd actually argue the opposite.
For me, there is little reason to immediately switch to Swift. I can still use ObjC, and in fact, I'd expect problems when switching to Swift.
Go, however, had many incentives to learn. Easier deployment, speed, concurrency, etc.
As usual, Wired has over simplified the argument
That's not as bad as JavaScript, but most good languages take longer than that.
Swift doesn't look bad as such to me at a quick glance, just not novel. It's a "why-bother?" language rather than a "ack, no!" language. If C# version 1 was "The Microsoft proprietary version of java" is Swift v1 "The Apple lock-in on current practices" ?
> It's a "why-bother?" language rather than a "ack, no!" language.
The thing is, what is the alternative? They needed easy ObjC interoperability (all the APIs and third party libraries are in ObjC, and will be for a long time), and thus a compatible object model. That would knock out most alternatives on its own. Even if they were willing to compromise on that, and go with more heavy-weight interop, they'd basically be looking at adopting Rust, which isn't finished, or maybe D.
EDIT: On the age thing, by the way, it's also reasonably clear that Swift isn't finished. It should be usable by the time Xcode 6 goes out of beta, but ObjC isn't going anywhere anytime soon, and I expect Swift will continue to evolve for a while yet.
Regardless of the language, the important (and most difficult) part is getting used to iOS framework, the patterns and models it uses, not to mention all the UI widgets and how they interact with each other.
I don't think Swift will make it easier to deal with all that, regardless of how well has been thought out.
Like with C#, a language "officially sanctioned language for the ... ecosystem" is not going to be a radical experiment, it will reflect proven wins.
So it seems that apple made the decision that the benefits of rolling their own take on the current state of the art outweighed the costs associated with rolling their own.
Which ones, exactly, would be better for Apple's purposes?
Or rust, D or go which you mentioned elsewhere. None of therm are ideal, all of them are > ObjC
You could have an open ecosystem where all of them exist. That you don't is an indication of how "Apple's purposes" diverge from programmers' purposes.
But you do, at least for two of them (D doesn't seem to support ARM yet).
Here's Rust: https://github.com/rust-lang/rust/wiki/Doc-building-for-ios
And here's Go: https://bitbucket.org/minux/goios/wiki/Home
Or you could write your iOS app in C, or C++, or Python, or... In all cases, you'll be calling objc_send a lot, and that's the problem. A Swift class can subclass an Objective C class, and implement Objective C protocols; good luck with that in a language with an incompatible object system.
Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense; using existing APIs and third party libraries would be horrendous.
Apple isn't stopping anyone, and Apple certainly isn't encouraging anyone from using any language that doesn't issue forth from Apple.
It also has a bit of Perl, in that its written so that patterns conform better to English speaking patterns. For example, they use the "let" keyword to do constants like:
let appleSummary = "I have \(numberOfApples) apples."
and they use Javascript-like simple concatenation operators like: str = "hello,"
str += " world"
And like Perl, I also like that associative arrays / dictionaries are top level: let people = ["Anna": 67, "Beto": 8, "Jack": 33, "Sam": 25]
After that, it mostly looks like standard evolution. They've taken many of the top, or high use programming patterns of the current day for i-products and rolled them into libraries or main functions to speed up development.It could be good. I do like Javascript and Perl, which look like they had a child with Objective-C. And that article has a point that its only main competitor is Obj-C, which is not much of a fight. Now if they'll only allow you to develop and build on non-Apple hardware.
Additionally some sort of hash/associative array/map data structure at the top level is (thankfully) common at this point.
I haven't followed swift too closely though, so maybe there's other stuff that I would consider more aligned with the spirit of Perl.
let people = ["Anna": 67, "Beto": 8, "Jack": 33, "Sam": 25]
Is this a perl-ism? It's not much more inference than C#: var people = new Dictionary<string, int> {{"Anna", 37}, {"Beto", 8}};
or a JavaScript array of objects.Also "+= " on strings extends beyond just JS (it works in C# too) and likely several others.
Whichever more modern language you're familiar with, you'll probably see an echo of it there.
Swift will be used as a competative advantage or lock in, depending on your level of scepticism.
It doesn't really change the story for developing cross-platform apps at all.
What was the last true innovation from Apple? I claim it was the iPod. The miniaturization of music. Everything since the iPod has been purely derivative of that miniaturization theme.
They've ridden the "Miniaturize all the things" wave hard (and successfully) by adding more features like accelerometers, GPS, faster chips, more colors, etc. to keep the fanboys horny but nobody has been really impressed with a new iDevice for quite some time. Apple is getting stale.
Apple needs a new hardware win that shows that they haven't exhausted their idea bank AND that they still have the marketing savvy to make people want what they've got.
Apple has NEVER been a software company. They are definitely struggling if Swift is the best new things they could come up with.
Where's the hardware?
<crickets>
Trying to use these technologies on another platform would be like trying to develop software using the core of the Python language with none of the standard library or external libraries (imagine they were implemented in another language you couldn't port). Or like implementing just the C# language on another platform, without any of the .NET libraries. It's possible, Mono did just that, but they had to re-implement almost the entire .NET infrastructure from scratch, a task many orders of magnitude greater than just duplicating the language itself.
Not sure I agree. You won't be making a Cocoa UI in it or anything, but if they open source the compiler and modifications to the Objective C runtime, along with the standard library (which is really light right now; you have to use Cocoa for very simple things), it should be useful enough, with GNUStep.
I do like Swift and it quite possible it will be used on other platforms but I'm not convinced. I haven't really checked out Rust and Go properly yet but compared with C/C++ Swift might be tempting for a new project on other platforms.
Of course, in practice, current development with Swift is mostly pretty dependent on Cocoa, but there's no inherent reason it has to be.
Also a $100 entry ticket to a beta IDE/compiler might hinder said adoption.
https://www.gnu.org/philosophy/free-sw.html https://www.fsf.org/blogs/licensing/gplv3-lockdown http://faif.us/cast/2014/jun/19/0x47/