One of the fun things about Apple’s new programming language “Swift” is the hate it gets from academics and lovers of existing languages like Java and C#. In truth, when you look at Apple’s requirements, they had little choice but to create something like Swift. I thought I’d review some of those requirements.
Objective-C is dead: Buffer-overflows have made all C-based languages obsolete (C, C++, Objective-C), but also, that bizarre SmallTalk syntax had to go.
Academic languages suck: The top 10 languages programmers use were created by other programmers, not university professors in their ivory towers. Academic languages like OCaml aren’t viable choices for Apple.
C Syntax is a must: While getting rid of pointers, any new language still has to follow C syntax – the syntax that 99% of programmers know and are comfortable with.
A stable language: New-fangled languages like Rust, Dart, and Go are rapidly changing. Had Apple picked one, they would’ve frozen it then forked it – a worse sin than creating a new language. In many ways, Swift is a fork of Mozilla’s Rust language.
Cocoa compatible: Academics think people can start over from scratch. They can’t. Apple has to live with their legacy Cocoa app/OS API. While any language (like Java, C#, or JavaScript) can work with Cocoa in theory, it would have ugly warts. Seamless integration almost demands a new language.
Objective-C compatible: Customers/developers have already made a huge investment in code. Again, this almost demands a new language – one that can be called from and can call into Objective-C. Swift does this surprisingly well, Java/C# can’t do this at all.
It happened at reference-counting: Apple chose reference-counting instead of garbage-collection for Cocoa and Objective-C. Once that decision was made, they effectively took Java and C# out of the running, forcing the creation of a new language
Debugging, debugging, debugging: Academics hate good debuggers, using them only as a last resort to fix bugs. Professionals use them routinely, to debug even working code, to double-check and understand it. Swift’s “playgrounds” are a huge innovation in such debugging.
Compile all languages: We used to have this hierarchy of languages, compiled interpreted, and p-code. Now all languages are compiled/JITted. This has allowed Swift to be simultaneously a “compiled” programming language and an “interpreted” scripting language.
At least you got functional: Academics hate imperative languages like C, but love functional languages like LISP. After three decades, it appears functional concepts are finally making it into mainstream languages, including Swift. This pisses me off, because I hate academics so very much. Functional programming is okay, though.
Conclusion
I write this blog post in reaction to this Slate article, where a left-wing complains about Apple being individualistic instead of collectivist in supporting an existing language like Java. It’s a truly silly article. Apple has hard requirements. Apple can no more ignore their legacy than Intel could ignore x86 compatibility. Something that looks an awful like Swift is Apple’s only solution.
In my experience, it doesn't matter how much it is like C, if it is a functional language, most current programmers will not be able to figure it out. It's a very different way of thinking, and I haven't seen too many people able to make the switch. They have too many patterns in their head that are now useless. :D Also, loops. ;)
ReplyDeleteRob, I think you just don't hate academic infosec research enough :-) Most of it is even worse than you think....
ReplyDeleteKatie,
ReplyDeleteYea, I think Apple will loose a lot of programmers who can't wrap their minds around functional programming.
However, JavaScript has shown that functional features in a language can be successful, with lots of people doing JQuery or NodeJS without realizing that what they are really ding is LISP. I think they still don't understand functional programming, but just know how to use the specific JQuery or NodeJS patterns.
In the end, since all other new languages have functional features, Swift had to add them, too. Once you've got automatic memory management, "functional" becomes free, so you might as well add it.
Interesting analysis, but it's worth pointing out that for many years, Java was actually used as an alternative language to Objective-C in Apple's frameworks via the "Java-Cocoa bridge". It was deprecated in 2005 because it didn't prove popular enough to maintain. While there were also some good technical reasons why maintaining (or even reintroducing) the Java bridge would not be a great idea, it's not fair to say that Java "wasn't an option". I agree that creating Swift probably was still the best choice. It seems to reflect a decent attempt at a consensus of what's practical and popular with other newer languages, while maintaining strong compatibility with Apple's frameworks (Cocoa/Foundation/etc.), which represents the real investment and benefit for both Apple and their developers.
ReplyDelete> Buffer-overflows have made all C-based languages obsolete (C, C++, Objective-C)
ReplyDeleteI strongly disagree. Buffer overflows have not made C obsolete; constants have.
From the Swift docs: "Swift also makes extensive use of variables whose values cannot be changed. These are known as constants, and are much more powerful than constants in C."
All constants are constant, but some constants are *much* more constant than others ;)
Greg -- variables in a functional language are not the same as variables in an imperative language. They're "constants" but not that kind of constant. Heh. It's just the way functional languages are.
ReplyDeleteGo is rapidly changing?
ReplyDeleteGo has kept backwards compatibility since March 2012, which had allowed it to thrive as shown in trends.google.com: http://www.google.com/trends/explore#q=golang
Putting in the same bag as Dart, that reached 1.0 last November, or Rust, that it's still far from reaching it, is just wrong.
Given that this "sandboxes" have nothing to do with debugging and everything to do with REPL (loved by academia and, i think, invented by it) it's all very interesting.
ReplyDeleteC is just NOT obsolete. C++ is still heavily used in many areas where performance is critical.
ReplyDelete@Andrew Au: thumbs up, ask a system programmer / engineer to write in Java ;)
ReplyDeleteI think Swift will help introduce developers to functional programming because it offers baby steps. You can use Swift with all legacy Foundation stuff and use existing design patterns or you can move to the new Swift standard library and use functional style programming with Algebraic types and pass by value.
ReplyDelete