Think Different

Author of Magical Record and current Coursera iOS engineer Saul Mora gives his analysis of the history of programming and the value that Objective-C still holds even after the introduction of Swift.

What is Swift trying to bring us? Objective-C has been the lingua Franca of iOS and Mac developers for a generation for good reason, it’s awesome. While Swift is the new hotness, let’s not be in such a hurry to toss out the language that has brought Apple back from the times when it was doomed.

---

Think Different (0:00)

The whole term “thinking different” came from Apple and their marketing campaign. The thing about working on Apple stuff is that it changes really, really fast. Already this year has had a ton of different frameworks and things: iOS8, CloudKit, new dives, a new XCode, and WatchKit. Change happens a lot in this space, and one of the highlights was Swift.

But what was Swift as a language going to mean? The dynamic nature of Objective-C was what made it so awesome. I’ve had experience knowing different languages and facing challenges programming, so when it came to the introduction of a new language, I knew to ask a really important question: What can you do in Swift that you couldn’t have already done in Objective-C?

Objective-C Worked Fine (3:45)

Objective-C did (and still does!) work fine. The compiler doesn’t crash, and SourceKit doesn’t have its daily seizure. With Swift, you’ve all figured out how to clean your drive data, reboot XCode and maybe your machine, but the debugger doesn’t even work. Objective-C was awesome because it worked. Some things that we thought Swift would be really good for were reducing code duplication, generics, optionals, and type collections.

Less Code (5:20)

A (programming) language must be parsed by people, not just compilers.
—Bret Victor

Swift may let you write less code, but you need to be able to read the code. The International Obfuscated C Code Contest has great examples of code that is short but looks bad. Short code is not always the reason that we want to change our language up. It’s good to write short code, but the idea is that as humans we have to read the code. You can write bad code in any language, and that’s going to include Swift.

Feature Comparison (7:51)

Both languages have object-orientedness as well as some functional elements. Swift is not a pure functional language and Objective-C has some functional elements. The typing system is not necessarily tied to the functional or objective-oriented paradigm. Swift has strong types, but I really like Objective-C’s suggested type system where you give the compiler a hint, and if it doesn’t figure it out it just crashes.

Other features in Swift include name spaces, which can be handy, and first class functions. Operator overloading was also a big feature. It has full unicode strings, which Objective-C can do some of but not quite everything. Dynamic dispatch is my favourite feature of Objective-C that doesn’t yet exist in Swift, although I believe Chris Lattner has said that will be an opt-in thing in later versions of Swift.

More important features include semicolons and curly braces, which help keep scope very explicit. Square braces are confusing; the dictionary operator in Swift uses square braces. Swift also has the ability to use emojis as names of variables, functions, and classes. Lastly, Swift is more modern than Objective-C.

Modern (10:35)

A programming language that implements new and recently developed language syntax, tools and ideas as primary characteristics.
-Modern Programming Language Definition

What does modern mean? Back in the ’60s, functional programming was modern. Object-oriented progrmaming was new and modern, but what is that now? Programming languages evolve because we learn from our past mistakes, and so we have new features, paradigms, and tools that come from growing our knowledge over the years. Swift wants to provide the same functionalities, but faster and better and with extra power.

A Quick Look Back (12:12)

There’s a lot of awesomeness in computer history, and I love being able to visit the Computer History Museum to see actual history. The ENIAC was programmed not with a keyboard and a screen, but with a programming manual and cables. The manual had accumulators and physical function tables, compared to virtual function tables in our languages now. Eventually we figure out that we could use punch cards and physically enter in codes that tell computers which switches go on and off in the CPU.

Assembler (15:39)

Once we got tired of that, we figured out to make the assembler, the first of which was created and developed by Nathaniel Rochester for the IBM 701. He helped found the whole field of artificial intelligence in the ’60s. The assembler developed all the machine code and gave us something like assembly, so we still had to deal with things like memories and locations, but in a way that was more readable for us. Then on top of that, we could now build all these awesome languages, like LISP, Simula, and Logo.

In all of that binary assembly programming, there were no subroutines. In languages like Logo, you could make subroutines out of things like programming a square, and it was actually a big revelation to have subroutines in your code. Then you had functions and procedures - a lot more organization. Then the big paradigm shift in Smalltalk was message passing. You can actually really learn how to make your Objective-C code better by reading about Smalltalk.

Interface Builder (23:59)

The book that introduced the world to Objective-C was called Object-Oriented Programming. It was published in 1986 by people at Stepstone, which was eventually bought by a small company called NeXT.When Steve Jobs introduced NeXTSTEP 3.0 in 1992, the analogy was that we had an object-oriented cake built in Objective-C and Interface Builder as the frosting. Interface Builder was what made Objective-C super awesome, and so what does Swift have? I think Playgrounds are one of the better features that came out of the WWDC announcement. You can do 3D simulations in Playgrounds and sync things really easily.

So, why Swift? (30:38)

My original question was, what could you do in Swift that you couldn’t have done in Objective-C? I think we’re beyond that kind of point in programming languages these days, since they’re capable of doing a lot of different things. Maybe what we should be asking is, what should we ask Swift to do that would be hard or impossible in Objective-C? We’re at the point in time where we can definitely influence what is going to happen in Swift, but we don’t have to necessarily throw away Objective-C either.

If we want to change our entire paradigm of programming, we want our language to do a lot more, like generating test cases like this tool Fox. This tool actually generates some kind of edge cases for all of your code, and at runtime to test the edges of your apps. Concurrency could also be improved, because there’s a lot of synchronization and other issues. You can’t really interact with the concurrency model in the UI. One of the inspirations for Playgrounds was something called LightTable. It’s an editor that allows us to get immediate feedback on things that are happening and really see how values flow through the entire program, because it separates your code by functions. This is a new kind of debugging, one that lets us understand our code in a much deeper way that we could before.

I think that in the future, programming is going to be less about the language and more about higher level concepts where we’ll deal with neural networks, reactive programming, and other things. As we’ve walked through all these examples, we’ve seen that each new paradigm has let us think in larger and larger abstractions. When we get to the future, the languages are going to probably be all encompassing.

Q&A (39:13)

Q: If not Apple, who’s leading the charge that will eventually lead us to the futuristic programming like what we saw in the Star Trek clip?
Saul: I don’t know the answer to that. My guesses would be places like Google, which is doing a lot of AI work, or MIT and places like that. IBM with Watson, which was demonstrated in Jeopardy.

Q: Think about the language and syntax, disregard some of the environmental immaturities that currently exist. If Swift worked correctly, what should it do? Would it provide any benefits to a team in terms of productivity or expressiveness, compared to working in Objective-C?
Saul: That’s a really big hypothetical. I think I’ve been working at it long enough to have a valid answer. It can be hard to decipher things in Swift as it is now. Things like applicative functors and currying made sense to me because I’ve read it on blogs, but my coworker just couldn’t understand it. That’s the hard thing about going to a new language - you have to learn new vocabulary and syntax, while bringing everybody with you too. Going forward, Swift as a language will benefit everybody by being able to take the best of functional programming and the best of object-oriented programming.

Q: Do you think that Apple will actually move tooling forward or will we stay with what we’ve done?
Saul: I’ve wished for better tooling for years. What’s different in this particular case is the fact that Playgrounds are such a new thing for XCode. It’s a very useful feature just being able to try out things without having to open a new project, and it’s a really great teaching environment. I’m cautiously optimistic that this is a direction that they will at least explore, but I don’t have any inside knowledge on that.

Q: How much do you think that being close to the metal correlates with efficiency in programming?
Saul: Honestly, I don’t think that’s as important these days. Some people think Objective-C is close to the metal now, but Swift and Objective-C are actually peers. They’re both running on top of the LLVM runtime and the Objective-C runtime. Just because CPUs are really tiny, it doesn’t mean there aren’t cables to connect. I think close to the metal is less meaningful going forward, and the bigger concepts are what matter. They’ll make us more productive in the long run.

Q: In terms of behaviour of usrs, what do you think would be necessary to convince people to switch to Swift?
Saul: I think the trouble is that the crashes are not a good thing, and there’s a lot of learning curve. When I first started Swift, I was really hesistant, even though I have some experience in going from language to language. It was the tooling and the immature tooling that bothered me, so it’s going to take tool sets getting better. It’s probably going to take another year or two before the compiler calms down.

Q: When you say that it’s not as important that we’re lower level against the hardware, what do you feel about the whole metal APIs that came out? When the say that you can get close to the hardware what do you feel about that?
Saul: From my perspective, Metal is more of a marketing strategy. What they’ve done under the coverage is really reduce a lot of the work that the higher level language has to do. I guess the big advancement in Metal is that they’ve made optimizations in the rendering pipeline that makes things fast.

---