Language Design
What do I mean? Well, primarily this:Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).The list Rob compiled is impressively well-researched. Although "special cases stopping just short of the general" for me is enough, it is THE cardinal sin of language design, I would add "needlessly replacing the keyword message syntax at exactly the point where it was no longer an issue and adding it back as an abomination of accidental complexity the world has never seen before". Let's see what Gilad Bracha, an actual programming language designer, has to say on the keyword syntax:
This notation makes it impossible to have an arity error when calling a method. In a dynamically typed language, this is a huge advantage.Abandoning keyword syntax at this point in time takes "snatching defeat from the jaws of victory" to a whole new and exciting level!I am keenly aware that this syntax is unfamiliar to most programmers, and is a potential barrier to adoption. However, it improves usability massively. Furthermore, a growing number of programmers are learning this notation because of its use in Objective-C (e.g., the iOS APIs).
Or the whole idea of having every arithmetic operation be a potential crash point, despite the fact that proper numeric towers have been around for many decades and decently optimized (certainly no slower than unoptimized Swift).
And yet, Rob for example writes that the main culprit for Swift's complexity is Objective-C, which I find somewhat mind-boggling. After all, the requirement for Objective-C interoperability couldn't exactly have come as a last minute surprise foisted on an existing language. Folks: if we're designing a replacement language for Apple's Cocoa frameworks, Objective-C compatibility needs to be designed in from the beginning and not added in as an afterthought. And if you don't design your language to be at odds with the frameworks you will be supporting, you will discover that you can get a much cleaner design.
Performance
The situation is even more bizarre when it comes to performance. For example, here's a talk titled How Swift is Swift. The opening paragraph declares that "Swift is designed to be fast, very fast", yet a few paragraphs (or slides) down, we learn that debug builds are often 100 times slower than optimized builds (which themselves don't really rival C).Sorry, that's not the sign of a language that's "designed to be fast". Those are the characteristics of a language design that is inherently super, super slow, and that requires leaning heavily on the optimizer to get performance to an acceptable level.
And of course, the details bear that out: copy semantics are usually expensive, they need the optimizer to elide those copies in the majority of cases. Same with ARC, which is built in and also requires the optimizer to be effectively clairvoyant (and: on) in order not to suffer 30x regressions.
Apart from the individual issues, the overriding one is that Swift's performance model is extremely opaque (100x for turning the optimizer on). Having the optimizer do a heroic job of optimizing code that we don't care about is of no use if we can't figure out why the code we do care about is slow or how to make it go fast.
Jealousy
So what makes little amateur language designer me jealous is that I really do try and get these things right, make sure the design is parsimonious, and these guys just joyfully ignore every rule in the book, and then trample on said book in ways that should get the language designer's guild to revoke their license, yet there is almost universal fawnage.Whoever said life was fair?
As always, comments welcome here or on HN
> I really do try and get these things right, make sure the design is parsimonious, and these guys just joyfully ignore every rule in the book, and then trample on said book
ReplyDeleteYes, exactly! (And I thought I was the only amateur language designer declining to fawn over Swift.)
I'm not a language designer, I'm a "solve problems and get things done" kind of programmer, as I suspect many are.
ReplyDeleteI like swift a lot, not for it's qualities in language design, but because it offers some practical, useful features that Objective-C doesn't have (Generics, type safety), and a few other practical, useful things that other major languages such as C#/Java also don't have (null safety, tuples), and it's also close enough (syntax and conceptually wise) to the other major languages to be easily learned.
Sure, it's full of impurities and holes, but to me it seems to have fewer of those than ObjC or C#/C++. One major gripe I have with "well designed languages" that people talk about such as Haskell or Clojure or whatever is that they focus too much on the mathematical purity side of things, to the exclusion of getting regular simple everyday tasks such as sticking some buttons on a dialog. You can have the best designed language in the world but if I can't use it to solve problems I actually have, or it requires a year's study to learn, it's of no use.
"Jack of all trades, master of none"
ReplyDeleteSoftware industry has two axioms.
1. Projects fail after 5 years.
2. New flavor only last 10 years.
Swift is trying to replace C,C++, Obj-C and incorporate Functional programming.
at the same time sticking with Cocoa API familiarity using LLVM to manage the optimization.
Your ideas might have been listened to in the 90s but today CS graduate you might as well be speaking a foreign language.
Also your analysis doesn't even touch the fact that C++ is the dominant language.
Obj-C only in the conversation because of iPhone. and all the maintainer of that language have since retired from Apple.
@Aynonymous: Well, one of the neat things about ObjC is that it has lasted a good 30 years now, and is still " a great improvement on its successors", to appropriate Hoare's praise for Algol.
ReplyDeleteMr Edwards' defense of Swift seems spookily similar to how I imagine people accustomed to the riot of similar but different tools available with UNIX took to Perl. It's messy but similar enough to things they already know and convenient enough that adopting it and bulling through all the sharp corners and non sequiturs is doable and feels worthwhile.
ReplyDeleteSwift: A Perl for the 2010s. This is a light I hadn't viewed it in before, and yet.
@Jeremy: "Swift: A Perl for the 2010s" I like it.
ReplyDeleteOrion Edwards said:
ReplyDelete"Swift is trying to replace C,C++, Obj-C"
Hmm, I see no evidence that Swift is trying to replace C++. Swift is being pushed as the language for writing software on Apple platforms, which is traditionally Objective-C. There's clear migration guides for Objective-C to Swift, and feature parity (more or less), and great cross-language interoperability.
With C++, none of these are true. C++ has many strongholds, like graphics and games, scientific computing, finance, and Microsoft Windows. Swift hasn't made any efforts to make inroads on any of these. I don't see anyone replacing any C++ code with Swift.
"... it offers some practical, useful features that Objective-C doesn't have (Generics ..."
To be fair, Objective-C does have generics now. They're arguably not as powerful as Swift's, but they do exist.
"people talk about such as Haskell or Clojure or whatever is that they focus too much on the mathematical purity side of things, to the exclusion of getting regular simple everyday tasks such as sticking some buttons on a dialog"
Hmm, I've never heard that. Do you find such tasks difficult in Clojure? I find that when a language is so well-designed that even difficult tasks are easy, that easy tasks are super-easy.