Beyond Objective-C, Beyond Swift
blog.jaredsinclair.com
blog.jaredsinclair.com
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?
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.
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?
That's how I read the article anyways.
Film at 11.
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.
For example https://news.ycombinator.com/item?id=8377860
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.
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.
[1] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
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.
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.
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."
etc.
See http://mjtsai.com/blog/2014/08/18/its-a-coup/
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. :-(
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.
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?
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.
Mantle : - https://github.com/Mantle/Mantle
MagicalRecord - https://github.com/magicalpanda/MagicalRecord
And RESTkit
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.
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.
[1] http://www.amazon.com/Object-Oriented-Programming-An-Evoluti...
Automated RESTful APIs
Expressive Triggers & Responses
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.
And also GSON from Google.
This casual false statement makes the rest of your comment seem very questionable.
Development for iOS has become much easier over time.
No. The jeering was because Android Dev's didnt deal with these issues and so the apps were just blown up in size, and not responsive.
These days I recommend https://github.com/SugarRecord/SugarRecord http://realm.io and https://github.com/yapstudios/YapDatabase
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.
Also is there a Swift version of ReactiveCocoa?
Any examples? I've only played with it a little but I'm thinking of doing my next app in Swift instead of Objective-c.
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.
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.
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.
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.
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.
Amazon [1] suggests that there were at least 8 volumes.
[1] http://www.amazon.com/Windows-System-Administrators-Definiti...
I think I still have my books at home somewhere. They were by Digital Press if I recall.
I just had a look, and it seems that this was common (see the highlight): http://books.google.de/books?id=d8tByjvMmIwC&pg=PR37&lpg=PR3...
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.