Why Apple's Swift might be the new BASIC, and that's no small thing

At Monday's WWDC, Apple made many announcements regarding the future of OS X and iOS. Perhaps the most interesting (and possibly most far-reaching) of these announcements was the surprise introduction of Swift, a new programming language and environment for iOS development.

If Apple can super-charge execution speed while making development much more interactive, that is game-changing indeed.

As you'll see in the following analysis, Swift has the potential to both revolutionize professional app development while at the same time opening the door to more recreational and educational programming.

This dual nature, of both high-performance resultant code and highly interactive development, is something we haven't seen before. If Apple can pull it off effectively, it will be something special.

Why should we care about a new programming language?

Language designers (and students and academics) create new programming languages all the time. I designed a language back in the dark ages that won an academic engineering research award.

There's a big difference between a new programming language and a new programming language from Apple that's intended to be the default iOS language. Any ol' language might, over time, get picked up and used. But with 9 million registered developers and 130 million new customers added in just the last year, you can be sure that Swift is going to experience extreme adoption at a breakneck pace.

Why will iOS developers care about a new language?

Well, that's a very different thing. First, because Apple is putting its stamp of approval on Swift (and tentatively removing it from Objective-C), it means that over time, developers will have to learn this new language.

Think of how you'd feel if one day, the government announced that the new national language would be Klingon. Even if you thought that was the coolest idea ever, you'd still be a bit anxious about how difficult the language would be to learn, and who else you'd be able to talk to.

More to the point, the combination of language plus IDE (interactive development environment) plus API (application programming interface) pretty much determines everything about the level of effort, cost, maintainability, enjoyment, performance, and capabilities of the apps developers produce.

Choosing the right (or the wrong) language can have profound consequences on the lifecycle of a product.

What are the business implications of Swift?

We'll get into the programming effectiveness implications in a later question. For the moment, though, it's important to note that this will have a big impact on the programming training aftermarket, which spans everything from writers of books on the language to online training services (like Lynda.com) even to colleges like UC Berkeley (where I teach object-oriented programming).

First off, you can bet that the products, classes, and training programs for Objective-C will begin to lose steam. If Swift sees big adoption, it will be at the cost of Objective-C, so if you're currently providing an Objective-C training product, expect it to be reaching the maintenance and end-of-life phases over the next few years.

On the other hand, this opens up a wide range of new opportunities for producing materials around Swift, again in the form of books, training services, and academic programs. With 9 million developers, there's certainly a market, but the content of content being taught will need to change.

There are more business implications, but I'll talk about them later on in the article. 

So what makes Swift so special?

First, understand that most iOS (and most Mac) programming has been done in Objective-C, which is Apple's own variant of the C programming language. C was an elegant for its time, but it was designed in the early 1970s, when computer software was vastly less complex than it is today.

A decade later, both C++ and Objective-C were developed, solving some of the same sorts of code scaling and reuse problems, but with different approaches. As we all know, Apple, through its NeXT acquisition, acquired Objective-C, and it became the primary development language for Apple software.

Back in 2012, in my True confessions of a former iPhone developer, I described Objective-C as "It's a lot like someone welded two separate programming languages together and forgot to grind down the rough edges."

That's because the message passing extensions that Objective-C brought to C are coded in a different syntax than the rest of the C code around them. If you write Objective C code, you get lots of code that seems to be bouncing between two completely different languages. It's ugly and inelegant.

Now, I know a lot of you die-hard Apple programmers will sing the praises of Objective-C, and there's no doubt it gets the job done, but there are clearly crufty elements in the language.

The way Apple described Swift is "Objective-C without the C." Based on what we know of these two welded programming paradigms — C's function-based model plus Objective-C's message passing model — we can pretty well assume that Swift will be all about message passing.

If you're not a programmer, don't worry too much about what that means. Just understand that anytime you can streamline code in a way that makes it more holistic, it has a benefit to productivity and maintainability.

There's more to it, of course, and we'll get to that later on.

Next: the art and science of programming...

By the way, I'm doing more updates on Twitter and Facebook than ever before. Be sure to follow me on Twitter at @DavidGewirtz and on Facebook at Facebook.com/DavidGewirtz.

But if it's a new language, doesn't that mean a big learning curve?

Yes. Yes it does. More to the point, there are some very big applications built in Objective-C, and you can't just go and toss out all that code and rewrite it.

There's no doubt in my mind that Apple will continue to support Objective-C for years to come

There's no doubt in my mind that Apple will continue to support Objective-C for years to come — probably for at least a decade. But if Swift does what they want, they probably won't innovate in Objective-C. They'll save that for Swift.

As a nod to the problem of code migration, Apple explained that the back-end elements of their coding system remain the same. Their intent is for modules written in Swift and modules written in Objective-C to coexist, so that developers can start coding pieces of big applications in Swift, yet not need to redo everything.

This has some benefits (and some challenges). If Swift is as fast as Apple claims in execution speed, programmers can rewrite the few performance-bound modules in Swift, link them with the rest of their code, and theoretically see a nice performance bump.

The downside, of course, is that you now have what will seem like three languages melded together, making maintenance all that more of a pain. Over time, however, as more and more of the mainstream Apple developer coding initiatives move to Swift, the homogeneity of product code will increasingly be pure Swift.

What about the execution speed benefits of Swift?

There are two speed-related factors: speed of execution and interactivity of development. It's important to note that you almost never, ever see these two things in the same development environment. You either get super-fast code execution or you get dynamic interactivity.

If Apple can super-charge execution speed while making development much more interactive, that is game-changing indeed.

So what does this all mean? Programming languages are often over-simplistically described as "compiled" or "interpreted."

Compiled languages do all the conversion from the English-like syntax of the source code to machine language prior to execution. This increases execution speed, because none of the translating has to be done when the program runs. C and C++ are traditional compiled languages.

Interpreted languages are, well, interpreted at execution time. For example, in BASIC, if you had a line like PRINT "David is swell", the BASIC interpreter would — right when it's time to run the code — figure out what the PRINT statement did and then run it. This makes for a much more interactive development experience, but also makes for slow executable code.

Since the 80s and 90s, many interpretive languages have implemented a middle ground. Code is "tokenized" (partially compiled for low-level virtual machines) at code-writing time and so execution speed is improved a bit. It's still not as fast as purely compiled code, but on today's processors, the difference isn't generally noticeable.

According to the slides at the Apple Keynote, Swift benchmarks fast. Really, really fast. All programmers like fast code, because fast code makes their applications run more smoothly, which directly improves the user experience.

Apple also showcased Metal, which is a 3D graphics library that they claim brings console-level 3D game performance to the A7 processor in the iPhone and iPad. Epic Games (makers of the Unreal gaming engine), demonstrated some jaw-dropping effects that they said were built with Metal and running on an iPad.

If Swift can really bring major execution speed benefits to developers over Objective-C and if, in combination with Metal, Swift can also bring previously impossible graphics capabilities, these performance improvements (especially as Apple moves to A8 and A9 processors) will almost undoubtedly give developers the tools they need to build some amazing new apps with a depth of capability we haven't seen before.

Swift and the art and science of programming

I often explain to non-programmers that programming can be as much art as science. There is great creativity in the act of programming. But that's often at a price. Programming is extremely time-consuming, and as we saw with Heartbleed and Apple's own "goto fail bug," a misstep can cause epic consequences.

Swift purportedly addresses these issues on two vectors. First, because Swift leaves behind much of the legacy of C (including most or all the pointer management problems that often open the door to security hacks), code built with Swift may well be intrinsically more secure.

Professional programmers will still have to use best practices, appropriate coding models, diligent testing, and careful reviews to be sure their code is ready for prime time, but better sandboxing of the core code will help keep users safer.

But what really excites me (and yes, something from Apple actually does excite me), is the interactive programming nature of Swift. Way, way back in the day, if you learned BASIC, you'd type a line of code and watch the environment respond. You could test each line interactively and see how everything worked.

To some extent HyperCard back in the 80s and early 90s did the same thing, and you can still, today, work with real-time interactive development in Python.

Swift brings this to Xcode. And what's interesting about Swift is that — if it works as Apple demoed — the real-time interactive programming element called Interactive Playground is available for graphics as well, not just the value of text and numeric values. You can actually watch how your user screen behaves as you modify code. It may just be a glorified debugger, but what a glorious debugger it might be!

To put this in non-programmer terms, remember film cameras? We'd all take pictures, but we wouldn't get to see them until we sent them away for processing and eventually got them back. Now, we have Instagram. Huge difference, right?

This is the same magnitude of difference between the edit-compile-test-debug model of professional programming environments and the real-time interaction model of interpretive systems like BASIC and Python.

To be sure, both BASIC and Python have been used to produce professional products, but the problem has always been performance. To get the interactivity, the system has always, always, ALWAYS sacrificed performance.

What I see as potentially game-changing about Swift is it looks to be able to provide the highly interactive programming environment that gives visceral feedback while coding while at the same time providing blistering performance. If Apple really can pull that off and the language doesn't suck to work in, this could be very big.

Next: the bottom line...

By the way, I'm doing more updates on Twitter and Facebook than ever before. Be sure to follow me on Twitter at @DavidGewirtz and on Facebook at Facebook.com/DavidGewirtz.

Time to market implications

This brings us back to more benefits of this environment. While professionals certainly are used to the edit-compile-test environment, if it's possible to have constant edit/test cycles going on until it's time for a big delivery, development time is going to be reduced.

In the right hands, this kind of development environment change could be like getting a few extra programmers for free.

Some companies and individuals will take advantage of that faster development time to do more in a shorter time with a smaller budget, while others will take advantage of that time to do more, and add more capabilities than were possible with the same budgets they worked with previously.

In the right hands, this kind of development environment change could be like getting a few extra programmers for free.

Recreational and educational programming

All of that leads up to the opportunity Swift provides for new programmers. Obviously, new programmers will want to learn iOS programming, given the size of the market. Programmers and developers who want to code as a hobby may well find something as interactive and responsive as Swift as compelling and inviting as BASIC and HyperCard were back in their day.

It's not like Apple needs more programmers, but Swift may become the darling of the programming education community because, for sure, new programmers will be much more comfortable with a cohesive, highly interactive programming environment like Swift than the fragmented, almost-crude, cumbersome programming environment that was Objective-C.

Will app consumers benefit?

I'll end this with a question I'm not sure of the answer to: will app consumers benefit? For sure, some professional app developers who can produce more and more code in less time will produce some new and innovative products, and we'll all benefit from that.

But we also may see more and more shoot-the-balloon-with-a-cannon games because the barrier of entry to app programming is going to go down. That means the Apple App Store — which Apple claims now has 1.2 million apps — will need to vastly improve its app-discovery capabilities so users who need to find apps will be able to find the good stuff, and not have to dig through 500 Flappy Birds clones.

Bottom line

There are still a bunch of "ifs" related to Swift:

• if it's a comfortable language to program in
• if it can deliver the performance Apple promises
• if it is solid and not filled with bugs
• if it's adopted by developers...
• then it could bring substantial (and hard to compete with) benefits for the Apple app ecosystem

We'll have to wait until the fall to see how this fully shakes out, but this is the first thing I've seen from Apple since 2008 that makes me think it might actually be kind of fun to develop for Apple products again.

And it's in that context, as well as the potential accessibility and interactivity of the programming experience, that I think Swift might well be the new BASIC. After all, remember that Apple got its start with BASIC on the Apple II.

In fact, explorers tinkering with BASIC back on the Apple II were really Apple's first customers. Most of them were not professional programmers. They were curious geeks, students, educators, and others wondering what they could make these new, marvelous machines do.

A few years ago, I pilloried Apple for losing track of its roots and restricting the ability of iOS users to build applications of any kind. In fact, when I first started developing iPhone apps (I wound up building 40 silly little pinpoint apps), Apple would not allow any books to be written on the topic, and put everyone programming for iOS under NDA, so there were no educational resources allowed at all.

But that's changed tremendously in the years since the iPhone first came out. And, now, with Swift, the doors for iOS development may well have been blown open to a new generation of programmers who may be able to recapture that exploring spirit of wonder that the first Apple II BASIC programmers had when they got their first personal computers.

If you're a registered Apple developer, you can download the Xcode 6 beta. Even if you're not a registered Apple developer, you can download the Swift programming guide from iBooks for free.

So, what do you think of Swift? If you're a coder, are you going to be adopting Swift? If you're not a programmer, do you think Swift will finally convince you to give it a try?

By the way, I'm doing more updates on Twitter and Facebook than ever before. Be sure to follow me on Twitter at @DavidGewirtz and on Facebook at Facebook.com/DavidGewirtz.