Some excellent reminders about empathy, not being a condescending designer, and trying to understand actual people when you build something. It shouldn't be that hard, you're one, and presumably you know some.
The text below was simply excerpts instead of the full transcript. The incomplete excerpts looked like snippets of context to guide people to the middle parts of the video. You actually had to watch/listen to the video to get the full text.
For example, at the beginning, he says the word "tricycle" and when I searched for that word, it wasn't in the text below. That's when I knew it wasn't a full transcript.
Happily, the two co-exist well, and increasingly so. Where one is a better choice for a particular job, you have it. It's just that you now have two tools to choose from.
If you use swift features then your class is inaccessible to ObjC. If you mark your class @objc then you can't use many swift features.
The only thing that works well is writing most of your app in swift and writing ObjC wrappers for C/C++ code, because dealing with C in Swift is atrocious and many libraries simply don't work in Swift because of initialization issues with complex structs.
Also, having two tools to choose from that do practically the same thing is never really a good idea because you waste time trying to figure out whether Swift->ObjC interop is going to fuck you over more than ObjC->Swift interop for this particular class.
Also, once you start mixing code and have your code importing a Swift header and your Swift bridging header importing your ObjC classes you start getting huge compile times as anytime you change an ObjC header your entire swift code has to be recompiled which takes forever because the swift compiler is dog slow.
My advice, pick one language for your project and stick with it, the language I would advise until Apple writes base libraries in Swift is ObjC, because if you run into performance issues C/C++ is going to save your ass far more than Swift will.
And mostly because
var cell = tableView.dequeResuableCell("foo") as! CustomTableViewCell
is MORE typing than
CustomTableViewCell *cell = [tableView dequeResuableCell:@"foo"];
And what the heck does that exclamation mark even do? Will the program then crash on NULL (more unsafe than ObjC) or will it just liquify to Kentucky Bourbon?
Personally, I find the concept of NULL (though toxic) more comprehensible and manageable than all those question & exclamation marks in Swift.
I'm not sure, I've had great fun learning it, and writing it is usually really nice. Sure, there have been pains along the way, but the Apple engineers are doing an amazing job with evolving Swift, intelligently, and very quickly. It is the future, and for many developers I know, it is already part of the present.
It's certainly gotten much better with Swift 2.0, it feels like Apple finally tried to build an app with Swift 2.0 and fixed a lot of the stuff that is horribly broken.
Hearing one of the core engineers from the LLVM compiler team speak at some length about their aims and approach to Swift, it was cleat that they had reflected long and hard on the approaches of many other languages. This engineer had very informed and nuanced views on the strengths and weaknesses of pretty much any other language you asked about. I'm sure Scala was on this list, also "Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list" — http://www.nondot.org/sabre/
Happy memories! Mike Lee's talk was amazing, Laura Savino basically gave a masterclass on presenting, and Maxim Cramer had Twitter on fire. What a wonderful week :)
"Swift is here to stay, but Objective-C is not going to fade away quickly. Many developers have existing codebases, but they also have deadlines, and business decisions. There is no fast way to rewrite an app in Swift. So let’s face it, many of you will probably be writing in Objective-C for a while yet."
