Tim Cook on Coding

I teach programming at a college. I think Swift is the best teaching language I have ever tried, and I've tried many. I can teach almost any basic concept with much more clarity. Swift playgrounds allow me to give students lecture notes with running code and spots for them to do labs. Students really like those. I have even introduced closures to very early learners with surprising success. Being able to write code without all the trappings of a Java class, for instance, allows for rapid learning.

I agree with you that as a professional language for application development, Swift is complex and rich. It is very powerful and I'm enjoying enjoying working in it. It takes some effort to get up to speed, though, and many have to concepts they haven't encountered before. As a teacher I find that to be a good thing but not all enjoy that.

I found C++ less painful to learn and use than Swift (has been so far). My entire undergrad program was based on C++, for everything (except the obligatory ACM recommendation of a semester of Java). If I had a choice, I would go back to C++ before I picked up Swift again. Managing memory is mundane and error prone. Managing Swift's type system is outright hair-pulling-frustrating.

Maybe I'm more of the Python/JS/Ruby mindset, but Swift had me focused in on details that I (or the problem I am trying to solve) do not care about.

I agree with you Michael, I don't think it's as easy of a language to learn as Apple's marketing-speak likes to present it as. It's also not "Objective-C without the C," either. It's a completely different beast... a functional language that has been grafted on to object-oriented system APIs, in order to make it useful to Apple's platforms.

Scott Hanselman said it best when he blogged "Stop saying learning to code is easy." Only in the bubble of Apple marketing-speak parlance is it "easy."

The situation is unfortunate, but Apple went all-in.

Just Wondering what are you views on easy to learn language? Python? Ruby? Lua?

( Or Javascript / VB ..... )

Most people confuse how pretty the syntax looks with how easy something is to learn. Languages that tend to have a C lineage look "good" to people. Languages with lineages to Simula (Objective-C), Prolog (Erlang), etc. tend to be "ugly" and consequently "hard" to learn.

"as the preteens participated in an Apple-designed “Everyone Can Code” workshop, which helps children learn how to build mobile apps, at the Apple Store in Toronto’s Eaton Centre."

If they have to deal with Provisioning, Code signing and getting the App approved for release, it could become traumatizing.

@Ed For basic stuff, probably Python. For more advanced stuff, Scheme. I think both “get out of the way” more than Swift does, allowing the teacher to focus on the concepts. Unless you’re trying to teach type theory, but Swift probably wouldn’t be the choice for that, either.

If your goal is to write apps, rather than learn programming and computer science, you could make the case that Swift is easier than Objective-C (easier to get up and running), although I think Objective-C is much simpler and easier to master. And to be an expert app developer you have to understand Objective-C even if you’re writing in Swift.

In any case, I think this episode says more about Tim Cook than it does about Swift.

Totally agree with you.

Chris Lattner has mentioned that in designing Swift, he wanted to create a language that would scale from low-level systems all the way up to applications and scripting through "progressive disclosure." I applaud him for his efforts, and I think Swift certainly makes attempts to scale in this way, but its fundamentally a safety-oriented systems language. The complex type system and other safety features make Swift a very good systems language, but a really heavy and complex language for application development, learning/education, and scripting.

When they announced Swift, I was hoping that the NeXT history of macOS would lead to a more dynamic language that was well-suited for applications. A higher level version of Objective-C, perhaps even a SmallTalk derivative. Alas, we got Swift, which is a very strange fit for app development due to its heft.

@Jonathan -

Maybe something a little more like Objective-J mixed with ES6?

“We wanted to design a programming language that is as easy to learn as our products are to use.”

Given my ever-increasing desire to slam all my Apple kit out of a third-storey window and just buy a PC, I’d say Tim &co are definitely succeeding all round.

As for Swift, it only proves that great compiler engineers do not make great language designers. Rubberized C++; what a hill to die on.

Ben: “a completely different beast... a functional language that has been grafted on to object-oriented system APIs”

Well that's rubbish. There’s nothing “functional” about Swift: it’s pure imperative sequential banging-the-rocks-together procedural/OO, same as C, C++, Java, JavaScript, Python, Ruby, etc.

FPs are declarative: an FP program describes relationships between its inputs and outputs; the compiler+runtime then figure out how, when, and where best to perform the calculations to convert a given set of inputs to the corresponding output. Basically, FPs automate sequential decision-making so that programmers don’t have to describe an exact, fixed sequence of operations themselves; in much the same way that lower-level languages like Swift and Java automate memory management so that programmers don’t have to muck around with that, baking in inflexible assumptions, introducing errors, and generally doing a lot of low-level grunt work that doesn’t actually contribute anything towards solving the problem the software is supposed to solve.

That so many mainstream programmers nowadays have such atrociously broken [mis]comprehension of computer science only proves that Cook is far, far from the only one talking out his ass.

Jonathan: “Alas, we got Swift, which is a very strange fit for app development due to its heft.”

More precisely, Swift is a very poor fit for Cocoa app development due to its impedance mismatch.

Java and C++ are also popular app development languages, despite being equally heavy. The fundamental difference is that Java and C++ use native libraries designed and built for and with these languages, whereas Swift has been lashed onto the side of an extant runtime, libraries, and idioms, whose philosophy is fundamentally different to its own. Anyone who’s worked with other Cocoa-bridged languages—Python, Ruby, Java, etc—knows from experience that while Cocoa may be a useful adjunct to those languages, they’re a second-rate option for first-class Cocoa development.

Economically, Swift is insane: it would’ve taken Apple a fraction of the time and work to toss it and build a new language that is a first-class Cocoa client. But creating Swift was never about solving Apple’s actual problem (lack of a modern safe apps language), it was about indulging Lattner’s personal pet itch, and then advancing various management careers. Big geek egos and internal empire building; it’s what ran early 90s Apple in absence of strong focused leadership, and now runs it once again.

To make Swift work right as an Apple-OS application platform, Apple must now toss away their entire 30-year investment in Cocoa and start over again from scratch. Which it’s slowly doing, but it’s going to take a decade at least—plenty time for their competitors to get well ahead—and once that rebuild’s complete they still won’t be much further on than they already were, as Swift is stuck just as firmly in the same 1960s mindset and working habits as every other Algol/C-descended language.

Hard to beat scheme as a teaching language.

@has

"As for Swift, it only proves that great compiler engineers do not make great language designers. Rubberized C++; what a hill to die on."

"..it was about indulging Lattner’s personal pet itch, and then advancing various management careers."

---

(*slow claps*) Goddamn man! Your words are exacting, cutting, harsh and completely delicious!

I think you're right. On all of this.

And yes, I stand corrected. Swift has a grab-bag of functional-looking-like things glued on, but it is still an imperative language, just like C# with lambdas and linq is still an imperative language.

I am bookmarking this page. It's so good.

Also @has: Where have you been hiding all this time?

@Deepankar: “Hard to beat scheme as a teaching language.”

Aside from the visually atrocious syntax and preponderance of neck hair, absolutely 100% THIS.

I learned to make my own languages by reading old “how to write a simple Scheme-like interpreter” course notes. It was a true penny-drop moment realizing that 90% of what modern mainstream programmers think of as fundamental/essential/core language features are really just decades of agglomerated layers of ignorance, ideology, cultural dominance, and/or ingrained habit. Languages like Python, Java, Swift, etc are complicated not because they need to be, but because they like to be. Lisps prove how simple languages can and should be, conversely providing users far more power precisely because they don’t force you into thinking and working as some alien language designer decrees, but instead providing you a foundation to grow your own language[s] around yourself.

@Ben: Bootstrapping the new business; just coming up on our first anniversary. High-end packaging artwork automation, powered by my other language, kiwi. And while I might be a little smug that nobody else in the world is anywhere close to matching what we do, if there’s one thing I’ve learned from Apple over the years it’s that the technology bit is the least important component in creating a successful product, successful organization, and successful market. So, busy busy!

> "As for Swift, it only proves that great compiler engineers do not make great language designers."

Agreed.

> Rubberized C++

Not nearly. Swift is much less heavy-weight than C++, it's a much smaller and a much more consistent language. Also, its performance characteristics are often far worse and/or less predictable, and is *not* at all a good fit for systems programming (as someone asserted). Two examples off the top of my head are the "copy-on-write EVERYTHING"-style collections, the other is the lack of pointers. The standard library "UnsafeSomethingPointer" types are so cumbersome to work with that I usually don't bother.

Oh, and by the way: Swift isn't a safety-oriented language! For a safety-oriented systems language, check out Rust. Swift has some safety features (its type systems *isn't* one of them), but it's mostly "try to make this pattern into a language feature so it will be misused less frequently". That's not "safety", but certainly a nice improvement over a completely unsafe language like C, and a goal similar to modern C++ (11, 14, 17), albeit with a completely different mindset and implementation.

> I would’t say that the basics are easier in Swift than in, say, Python. Playgrounds notwithstanding, Swift does not feel like a clean, easy teaching language to me; it’s more of a pragmatic tool for professionals.

Again, not really. I have a *very* slight feeling that you are complaining about Swift being statically-typed (since you keep comparing it to dynamically-typed languages such as Python which you classify as "easy"); however, I do agree that a statically-typed language doesn't have to be so bureaucratic and annoyingly, needlessly restrictive as Swift sometimes is. It's not that these annoying aspects / steep parts of the learning curve make a language a "pragmatic tool for professionals". Swift does have many decisions that aim to keep it familiar to (mostly beginner) programmers coming from other languages. For example, it's a C-style statement language, not a Rust-style expression language. A past-2000 language that is not an expression language "because familiarity" makes me upset. If I were to choose an app development language freely, I would choose Objective-C over Swift at any time for Cocoa, and C++ for other Unix platforms. (I don't even dare to mention Rust, the Dynamic Language Strike force will sass me for writing my own SDL or Cairo or WinAPI or… bindings.) Swift is just too annoying to work with because of the core language.

> To make Swift work right as an Apple-OS application platform, Apple must now toss away their entire 30-year investment in Cocoa and start over again from scratch.

I think that's still a bit of an exaggeration. Existing Cocoa (Touch) classes and C functions work with Swift, albeit at different levels of convenience. Objective-C integration is excellent, C integration is meh, but as a Cocoa (Touch) developer, one tends to interact much more with Objective-C classes than with plain C functions.

Swift is a nightmare when it comes to learning through examples.

When you look for a solution in stackoverflow or the Apple forums, you often end up with solutions that are not compatible with the version of Swift that you're using. So today contributors add which version of Swift their solutions works. But the fact is that you, who do not spend your life checking the Swift mailing list or github repository, don't really have a clue whether the N version of Swift is compatible with N+1 or N-1.

"design a programming language that is as easy to learn as our products are to use." Yeah. No. Clearly not. If that was the main goal (it's most definitely not), they failed. For instance, in Swift ease of learning definitely takes a backseat to one of the main (if not the main) design goals, which is a design optimized for compiling to native code. Two examples: the linking model is that of native code (as opposed to, say, Python's, where the entry point is the file designated as such), and they favored the C++ binding model rather than the Objective-C binding model, which among other consequences means you can't trivially convert treat an object as its protocol-conforming self: https://mjtsai.com/blog/2015/08/03/swift-protocols-arrays-and-casting/ . Worse, sometimes Swift pretends to be easy to learn by papering over the inner realities, like when "in order to claim “approachable scripting language” brownie points, Swift makes top level code the entry point of the process… that is, as long as you write that code in a file called “main.swift” (top level code is otherwise forbidden)." ( http://wanderingcoder.net/2014/10/21/swift-thoughts/ ).

However, while not as good as Python in that regard, Swift has a few things going for it that still make it suitable as a teaching language; at least more so than Java or C++.

- Swift has going for it that it has (for the most part) an overarching design. Language features generally make sense. By comparison, C++ is a kitchen sink, in which teaching can easily get lost. Moreover, it is designed as a whole, not for instance as a separate base language and standard library, which means standard library objects integrate well with language features, even advanced onces.
- But at the same time, Swift avoids all-encompassing concepts, to which Java fell victim, for instance when in order to write a "Hello World!" in Java, you have to first… define a class?!, because in Java classes are Everything, then it has to be "public final", then the main function has to be "public static", etc…
- And more generally Swift strives (besides the few cases I mentioned) to be approachable. Its safety goes a long way towards accompliching that, by avoiding the macho aspect "only the paranoid survive" of C/C++, for instance when students run into their first memory dereference mistake and/or their first memory leak: frankly, those feel like the language is telling you "You made a mistake, and in fact you made it some time ago, but I'm not telling you what or when you introduced it". And when this safety would make it less approachable (e.g. with strict typing), Swift has features like type inference or some implicit conversions so that it is not needlessly complicated.

The result is that Swift has a very manageable learning curve; some parts are harder to learn than others, but if you only need a closure you can use that and don't need to first learn about objects, for instance, which means it's possible to create a teaching course with Swift that progresses without abrupt steps.