I'm not as in love with Swift as I was when it first came out after having used it for some small hobby projects. I agree that it doesn't solve any of the big problems in software development, and more just amalgamates ideas from multiple languages (bringing them into the Cocoa world which is a good thing) and makes things safer.
However, a lot of Sinclair's arguments are misguided/misplaced/misdirected. Let me address each of his 4 core issues:
Databases & Persistence – This is almost certainly a library issue rather than a language issue. As others have pointed out, third party libraries solve this problem quite well on other platforms and there's no reason they can't be solved just as well with Swift. In fact isn't that kind've what Realm is doing?
Automated RESTful APIs - I don't think I even need to explain for the crowd here why this is a library issue and not a language issue.
Triggers & Responses – Swift actually has some rudimentary support for this in the form of Property Observers (didSet, willSet). These aren't useful for all of the same scenarios as KVO, but they're a start and I see this as an area that is clearly getting renewed attention with Swift.
UI Layout - How did he manage to criticize this issue so much and not mention Interface Builder? If you're primarily doing your layout in code, you're doing it wrong. I've been fighting AutoLayout a lot the last week, so I'm not in a mindset to give IB too much praise. AutoLayout in IB is still buggy and still has some ridiculous error messages, but I don't spend my days doing geometry calculations as he seems to imply. I'd like to see IB improvements, but again this is not a language issue.
So, it sounds like Sinclair mostly wants better libraries and better tools. Don't we all?
To my understanding, his point is that we need database persistence, automated RESTful APIs, triggers and responses and better ways to do UI layout, but what we got was Swift which doesn't address any of these things. The things we actually need.
So we end up with a new language which we have to spend time mastering, and when we are done doing that, we still need to fix those problems we had before we got Swift, so what is the point? Why do we need Swift?
Welcome to Tautology Club! If Tautology Club is the sort of thing you like, you will like Tautology Club. Alternatively, you will find that you like Tautology Club if that is the sort of thing you like.
In other news, you might have checked some of the other posts here that explain why some of these problems are, or at the very least can be language problems, before letting loose the snark.
Often better libraries and tools can only be built on a better language. That's easy to say and very, very difficult to pull off, but when it happens the result is like magic.
I recently encountered this when I was getting into the nix package manager. At first I thought it was ridiculous that they had invented a whole new language just to describe packages. It was a lazy functional language at that, obviously an exercise in academic preening. Boy was I wrong. Because it's lazy you can have a program that describes a whole Linux distribution, and only run the parts that are necessary for the task at hand: installing nginx or whatever. Outside core they use all sorts of non-trendy languages, but the core is written in a new language with carefully-designed characteristics.
The result is amazing, as much of an advance as going from manual to automatic memory management.
It seems to me that the OP's complaint is that Swift wasn't designed to make better libraries and tools possible, but rather to work well with the ones we already have.
>Often better libraries and tools can only be built on a better language.
Precisely. For example, a lot of Cocoa these days relies on dictionaries and/or stringly-typed identifiers: KVC, KVO, Bindings, Archiving, CoreImage attributes, CoreData's interface to the database etc, etc. Autolayout also uses a separate string-based language.
There are a lot of problems with this approach, not the least of which are performance, code bloat and lack of any kind of compile-time checking.
Polymorphic Identifiers[1] in Objective-Smalltalk[2] are an attempt at addressing these issues (and others). The paper shows why you actually need a small amount of language support to successfully build libraries that address these issues.
I wish I could complain about how Swift's approach to these issues is so much inferior to mine (grin), but there just isn't anything at all. If anything, support for solving these sorts of problems is thinner than in Objective-C. Yikes!
Another issue is the large-scale structure of applications...their architecture: target/action, delegates, bindings (again), notifications, view-controller segues etc. are all architectural connectors, and a large part of what makes Cocoa so powerful. However, these types of connections (-> configurations) can only be described in ad-hoc ways in code, or in a different ad-hoc way in IB. Various inspectors of a GUI builder are not really the proper place to describe the overall architecture of your program.
There have been many systems/languages for describing such high-level architectures, for example ArchJava or ACME. In Swift? Crickets.
When direct language support for a feature is not present, dynamic messaging has been a great way of making library features available as if they were built-in language features. Swift makes this harder or downright impossible.
> Swift wasn't designed to make better libraries and tools possible
Yep. In fact, it's arguably a step back even compared to Objective-C. Which is sad.
> but rather to work well with the ones we already have.
Except that it doesn't really work all that well with existing ones either. Objective-C interop seems to clearly be marked "legacy", with the default apparently non-interoperability.
On the flipside, it could be that Apple is laying the groundwork (as they tend to do) to evolve these more advanced features into the language. One could imagine Swift becoming quite divergent from Objective-C in the future, but for the initial release it would have been foolish for any number of reasons to try to introduce anything other than a small step forward from Objective-C.
Yes, I was hoping for this as well, and yes, taking it in small steps is probably the right approach.
Alas, the steps Swift is taking all seem to be going in the opposite direction: more compile-time, more strictness, less dynamicism. As has been written before: Swift is not a better Objective-C, it is a better C++.
I really hope I am wrong about this, but given the current direction, the expressed philosophy and values as well as the predilections of the people involved, I don't see the direction changing from the initial vector.
There is no less dynamicism in swift than in objective-c. What there is, is a replacement for the C. Which is precisely what they said they were going to do. C, of course is not dynamic, and the replacement is not either.
I'm not disputing the idea that instead of replacing the C, Swift's designers could have focussed on enhancing the message passing component, but I would argue that doing so without also replacing the C would have been a mistake.
Perhaps the dynamic elements will also be overhauled over time.
>There is no less dynamicism in swift than in objective-c.
Huh?
"Requiring dynamic dispatch is rarely necessary."
"The bad news is that, by default, your objects will no longer work with KVO or swizzling. If the designer of a class doesn’t anticipate a reason for a particular method or property to be dynamic, that lack of foresight gets baked in at compile time."
If that is not correct, I'd love to hear about it!
> Swift's designers could have focussed on enhancing the message passing component,
That would have been great.
> doing so without also replacing the C would have been a mistake.
Absolutely. But really they've replaced the "Objective" and enhanced the C. After all, Objective-C is a blend of Smalltalk and C. If you remove the C, what is left?
>Perhaps the dynamic elements will also be overhauled over time.
Maybe. So far, that "overhaul" seems to be mostly de-emphasis, deprecation and removal. :-(
Swizzling can't be mentioned with a straight face in an argument about brittleness.
But, I'll concede that KVO won't work with arbitrary properties of binary libraries you receive or that Apple builds into the platform, assuming they use swift and choose not to mark them dynamic.
So in this sole regard, swift is less dynamic.
I guess it remains to be seen whether this actually becomes a problem.
>This is almost certainly a library issue rather than a language issue.
Is Cocoa a language or a library?
IMO the criticisms really apply to Cocoa, not Swift.
Or rather - they're complaints about the fact that Swift could have been designed to simplify common Cocoa boilerplate, but instead it seems to be Yet Another Blub (c) 2014.
What's going to have more of an influence on developer productivity - a novel type inference scheme, or an OS API that works so well you don't need to keep writing the same boilerplate over and over, or go looking for 3rd party libraries to fix its deficiencies?
Agreed, DB & Persistence and automated restful APIs are library problems, and ones pretty well solved by some existing solutions. Realm is awesome, and solves both pretty well.
Personally, I love Swift, and after having written a medium sized application in Swift over the course of about a month, I can say I saw significant productivity gains over objective-c.
Honesty, if you use Swift as just a 'Better Objective-C', then it isn't that much better.
However, if you abandon the Java/Objective-C style of one file per class, traditional OO, and instead program as if it were lisp, using a file per 'topic' to build up solutions out of func and structs and iteratively develop protocols and classes as needed to integrate with the UI, you will find that it is a much superior language to Obj-C.
The OP is certainly doing it wrong with his air coding approach - which makes sense in objective-c, where the building blocks are so heavy, but with Swift you can just get something simple working, and then iteratively refactor, with the type system acting as your support for correctness.
If there is a problem with Swift it is that knowledge of Objective-C doesn't provide any real clue as to how to use Swift effectively. For me that knowledge came from having also built shipping products using Clojure, Scala, and Ruby.
Tldr; If you program Swift as if it were obj-c, you will be disappointed. It takes a different style to get any real leverage from it.
Sometimes, data is just stupid, and doesn't deserve anything more than an associative array between plucking it from the DB and casting it off as some JSON. Writing a bunch of do-nothing classes and then bitching about deserializing and reserializing them seems like folly to me.
Classes make sense when you use polymorphism and have a set of behaviors clumped together and multiple implementations. If it's just one call with multiple strategies, use a function call with a defined signature (func pointer type, delegate, whatever). If the "class" is nothing but magic bean "[sg]et-foo; [sg]et-bar; [sg]et-blah; ..." (with no validations, calculations or any other kind of value added), why are you writing it? (and why do I have to read it?) Use a struct/record/tuple if there is a lot of code that might typo the property names, or just an associative array if the usage is an automated pass-through with little to no looking inside.
Some parts of an app benefit much more from functional composition than a big bunch of make-work objects that make a loud clunk when you whack 'em with a stick.
From my conversations with iOS developers, those libraries don't come close to the robustness and simplicity of equivalent java/android libraries like retrofit, gson/jackson, coupled with RxJava... Etc.
I do think a large part of that is due to lack of generics that allow the code to recursively deserialize nested classes and collections without any extra boilerplate other than the class definitions.
I know for a fact that mantle just can't do that with obj c in its current form.
>I do think a large part of that is due to lack of generics that allow the code to recursively deserialize nested classes and collections without any extra boilerplate other than the class definitions.
Huh? Completely automatic serialization (called activation/passivation) was in the original Stepstone Objective-C, described in Brad Cox's book[1]. No generics required at all, just a modicum of introspection.
are actually already addressed very nicely by some of the third party libraries available for Java. You're exactly right that the combination of typed collections and annotations makes this much easier in Java. If you lay out your model classes properly then JSON serialization/deserialization is a one-liner.
And his third point, the complexity of auto layout, is much less of an issue with Android's layout system, which is much saner for the typical kinds of grid layouts you encounter in real apps.
This is why I've always had a hard time understanding why people say building Android apps is harder than iOS. Sure you have to support a wider variety of devices and dealing with low-level stuff like GL shaders or the camera can be painful. But for typical apps that are basically just list views into some kind of backend data store Android is way easier, IMO. And with the recent proliferation of iOS device sizes and aspect ratios the days of drag & drop UI in iOS are long gone.
I take it you're not an iOS developer? If you're not building responsive UIs with auto layout you're doing it wrong and doing it right is way harder than it was back in the golden era of photoshop-based pixel perfect designs.
Actually I am an iOS developer, and it's much easier to make a responsive UI using autolayout than it ever was to translate someone's photoshop into a pixel-perfect UI, especially if your product is being developed iteratively and is actually subject to change.
Development for iOS has become much easier over time.
You're the first person I've heard say that. It's much better than it was but it's still the most write-only layout system I've encountered in many many years of building UIs on all kinds of platforms. I'm finding all kinds of broken UI in published iOS apps now. iOS apps used to be easier because they didn't need to be responsive. Android used to get a lot of jeers because Android devs had to deal with these issues from day one.
That applied to tablet apps only, which Android devs justifiably ignored. Android devs never had the luxury of assuming devices were of any particular point size, which is something iOS devs did habitually until now.
Enjoyed this piece. You could argue that a few of the new features in Swift do offer more concise syntax e.g. inferred types and the ability to use map/filter – leading to reduced lines of code similar to ARC (but not quite as transformative as reducing state and memory bugs).
Nevertheless I would be interested in creating a framework to tackle the model/persistence/networking/reactive boilerplate issue. I imagine it would be very popular.
I'm starting to the feel same way about swift. While the syntax is less verbose which I prefer. It feels that its just incremental improvements to objc.
I was extremely excited about swift when it first came out and I played around with it initially in beta. However after working on an app in Swift now I can't help but feel like some of the hoops you have to jump through for it make it a tremendous pain in the ass.
There's a lot of manual management of potential null-values. Which may be a good thing for app stability but is ugly in code. Currently you also get a lot of mysterious crashes and very often the debugger is useless when you do. So it's back to print statements to find errors. As the language and runtime matures this will be less the case.
Probably the biggest issue with Swift right now though is that it has to accommodate all the older Cocoa APIs so in practice it's often just a slightly nicer syntax for the same code. Cocoa functions tend to return untyped values or things like NSArray so you have to do a lot of manual casting, etc.
Yeah, all of the manual casting (which I feel like sometimes takes more trial and error than it should to get to compile) and the awkward null checking are the two most painful points. The debugger being basically useless is a problem, but it's something that will get fixed eventually. I have less faith in the first two points though because initially they were less painful but in later betas they became more painful.
With regard to the first two of these points, Databases / Persistence and automated REST APIs I fully agree with the problem and I'm working on it pretty hard. My e-mail's in my profile if you want to chat.
However, the nature of writing a good, broad, solution as a third party is you have to capture some senior engineers for long hours, which costs money. And it's not clear to me if there's enough money available, for a third party to build the kind of broad-reaching solution that would be nice to have.
> Advances in software development are offensive to the practitioners of the technologies made obsolete.
I couldn't get past that part. I've been a software engineer for over 20 years, I love any technology that makes my job easier and allows me to more easily deliver more functionality with higher quality in my products. I can't understand where this mentality comes from.
Well, I had a visual flash of insight on this topic when we got an SGI Crimson in the office. It came with the X-Windows documentation, I'd say at least 3 feet of shelf-space.
The full NeXTStep documentation, including DPS, AppKit, system administration, NetInfo, etc was about a quarter of that.
Again, the previous was just the windowing system, so at most around 1/10th of the scope of the NeXTSTep documentation, and no, the NeXTSTep docs weren't any less thorough or complete.
So, if you've learned and maybe become an expert in the stuff that requires 3 feet of documentation, you're probably not too thrilled about finding out it's been for naught.
The X documentation was 2 volumes: 5 inches total. If you throw in Motif, Display Postscript (which came out in early 90s on SGI) and GL, it's still under a foot. I never had NeXTSTEP manuals, but I did have the OPENSTEP box set which was about a foot thick.
I understand the point you are trying to make, but the truth is an expert would find a lot of similarity in those systems. Even today iOS development feels comfortable and similar to the work I did on SGIs in 93.
The 2 volumes of authoritative X documentation came from Digital Press. X Window System by Scheifler, Gettys and Newman. X Window System Toolkit by Asente and Swick. If you read further in the acknowledgements that you quote, you'll see them listed as primary sources. My copies take up 3.25" on the shelf.
I know we had a lot of the O'Reilly X books floating around. Nobody ever read them, but we felt weird throwing books away. You're right that they got bundled by vendors--I think HP and Sun eventually bundled stuff too. The bundling decision was probably more about trying to justify insanely high workstation prices than an indictment of the complexity of X.
However, a lot of Sinclair's arguments are misguided/misplaced/misdirected. Let me address each of his 4 core issues:
Databases & Persistence – This is almost certainly a library issue rather than a language issue. As others have pointed out, third party libraries solve this problem quite well on other platforms and there's no reason they can't be solved just as well with Swift. In fact isn't that kind've what Realm is doing?
Automated RESTful APIs - I don't think I even need to explain for the crowd here why this is a library issue and not a language issue.
Triggers & Responses – Swift actually has some rudimentary support for this in the form of Property Observers (didSet, willSet). These aren't useful for all of the same scenarios as KVO, but they're a start and I see this as an area that is clearly getting renewed attention with Swift.
UI Layout - How did he manage to criticize this issue so much and not mention Interface Builder? If you're primarily doing your layout in code, you're doing it wrong. I've been fighting AutoLayout a lot the last week, so I'm not in a mindset to give IB too much praise. AutoLayout in IB is still buggy and still has some ridiculous error messages, but I don't spend my days doing geometry calculations as he seems to imply. I'd like to see IB improvements, but again this is not a language issue.
So, it sounds like Sinclair mostly wants better libraries and better tools. Don't we all?