
Beyond Objective-C, Beyond Swift - mpweiher
http://blog.jaredsinclair.com/post/98402624705/beyond-objective-c-beyond-swift/
======
WoodenChair
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?

~~~
chrisbuchholz
I feel you misunderstood the article.

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.

~~~
pohl
That makes it sound as if a modern language sans the baggage of C was not
needed. It was.

~~~
mpweiher
Hmmm...to me it makes it sound like a modern language without the baggage of C
was and is needed, but Swift is not that language.

~~~
pohl
[language] does not solve [problems not solved by languages].

Film at 11.

~~~
mpweiher
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.

For example
[https://news.ycombinator.com/item?id=8377860](https://news.ycombinator.com/item?id=8377860)

~~~
pohl
"My smartphone didn't palliate my hemmoroids" is no tautology.

~~~
mpweiher
But "[language does not solve] [problems not solved by languages]" is.

~~~
pohl
Your opinion fails to shorten my daily commute – which is the truly pressing
concern.

------
gress
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.

~~~
Roboprog
I like it! Free your mind (from OO tyranny).

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.

~~~
gress
Exactly. And the swift designers realize this which is why they added these
language features.

------
thewarrior
There are libraries that partially solve the persistence issues the author
talks about :

Mantle : -
[https://github.com/Mantle/Mantle](https://github.com/Mantle/Mantle)

MagicalRecord -
[https://github.com/magicalpanda/MagicalRecord](https://github.com/magicalpanda/MagicalRecord)

And RESTkit

[https://github.com/RestKit/RestKit](https://github.com/RestKit/RestKit)

~~~
makeramen
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.

~~~
cageface
Came here to post a similar comment. Two of his bullet points:

    
    
      Automated RESTful APIs
      Expressive Triggers & Responses
    

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.

~~~
gress
"with the recent proliferation of iOS device sizes and aspect ratios the days
of drag & drop UI in iOS are long gone"

This casual false statement makes the rest of your comment seem very
questionable.

~~~
cageface
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.

~~~
gress
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.

~~~
cageface
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.

~~~
gress
> Android used to get a lot of jeers because Android Dwvs had to deal with
> these issues from day one.

No. The jeering was because Android Dev's _didn_ t deal with these issues and
so the apps were just blown up in size, and _not_ responsive.

~~~
cageface
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.

~~~
gress
Perhaps that 'justifiable' ignoring of tablet apps by Android devs is what led
to the total failure of Android tablets.

------
raspasov
React.js/Om
[https://github.com/swannodette/om](https://github.com/swannodette/om) type of
framework would be awesome! The only thing is I don't think UIKit lends itself
nicely to this kind of programming. We're also missing Persistent Data
Structures (in the
[http://en.wikipedia.org/wiki/Persistent_data_structure](http://en.wikipedia.org/wiki/Persistent_data_structure)
not durable sense). I wasn't the first one to think of this :)
[https://twitter.com/michaelklishin/status/474268337665740801](https://twitter.com/michaelklishin/status/474268337665740801)

------
alexjarvis
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.

Also is there a Swift version of ReactiveCocoa?

------
jordanbrown
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.

------
mpweiher
My biggest disappointment with Swift is also not so much the answers they
found, but that they aren't even close to asking the right questions.

~~~
justinreeves
What would those be?

------
akadien
I was excited about Swift. After learning enough to write code that does
something meaningful, I find it boring.

------
jgh
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.

~~~
k-mcgrady
>> '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.'

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.

~~~
cageface
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.

~~~
jgh
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.

------
drewcrawford
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.

------
craigching
> 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.

~~~
mpweiher
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.

~~~
kenfox
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.

~~~
mpweiher
Hmm...there were a lot more than 2 volumes on that bookshelf. And again, that
was just the windowing system.

Amazon [1] suggests that there were at least 8 volumes.

[1] [http://www.amazon.com/Windows-System-Administrators-
Definiti...](http://www.amazon.com/Windows-System-Administrators-Definitive-
Guides/dp/0937175838)

~~~
kenfox
You are seriously trying to add up all the O'Reilly books and compare that to
documentation published by NeXT?

I think I still have my books at home somewhere. They were by Digital Press if
I recall.

~~~
mpweiher
That's what we were provided by SGI as the official documentation.

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...](http://books.google.de/books?id=d8tByjvMmIwC&pg=PR37&lpg=PR37&dq=official+x-windows+documentation+o'reilly&source=bl&ots=moQDks83K6&sig=luh_yofCT0Oh57u7lyr0liqiATM&hl=de&sa=X&ei=87QnVPmHEJPfaJb6gKgL&ved=0CDMQ6AEwAQ#v=onepage&q=official%20x-windows%20documentation%20o'reilly&f=false)

~~~
kenfox
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.

------
_random_
Just use Xamarin.

