Which Features Overcomplicate Swift?
It’s even harder to separate out the opportunity cost—how many of the language’s other complexities and inconsistencies would have been reconciled if they hadn’t had to focus on interoperability with a fundamentally unsafe language and runtime with which they share an address space?
While this overwhelms the language’s design, it’s hardly the only example of complexity.
[…]
Crucially, the vast majority of this is incidental complexity, not essential complexity. 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).
Update (2015-05-23): Marcel Weiher (Hacker News, Reddit):
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.
[…]
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).
I like Swift because constantly challenges my skills as engineer, I have to find workarounds to apply all the concepts I know about functional programming, but... this is the current feeling, I don’t know if in a long run this would persist, I can’t image to fight against the language like I have to do sometimes, would make me still happy in 2-3 years, maybe some day I would get tired.
Update (2015-06-11): Marcel Weiher (comments):
Apple used to be very much about going that distance, and I don’t think Swift lives up to that standard. That doesn’t mean it’s all bad or that it’s completely irredeemable, there are good elements. But they stopped at sophisticated complexity. And “well, it’s not all bad” is not exactly what Apple stands for or what we as Apple customers expect and, quite frankly, deserve. And had there been a Steve in Dev Tools, he would have said: do it again, this is not good enough.
Update (2015-06-12): Adam Knight:
Swift is kind of like when you’re a kid and you fill the bag of jelly beans with all your favorite flavors and then reach in and have a handful all at once. Each was a good idea, but together it lacks anything that made any single piece good.
2 Comments RSS · Twitter
@charles: Well said. Special cases are almost never special enough to actually warrant special cases. I can only assume Perl5 was having a major firesale and the Swift designers happened to pass by and thought "What a bargain!"
This is why I believe software designers should be required to do all their user documentation and training too: nothing tightens a design like knowing one day you'll have to shovel all its hairly crap yourself. :)
