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

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

Summary: Swift has the potential to both revolutionize professional app development, while at the same time opening the door to more recreational and educational programming. If Apple can pull it off effectively, it will be something special.

(Image: CNET/CBS Interactive)

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.

Topics: Mobility, Apple, Apps, Software Development


David Gewirtz, Distinguished Lecturer at CBS Interactive, is an author, U.S. policy advisor, and computer scientist. He is featured in the History Channel special The President's Book of Secrets and is a member of the National Press Club.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • "Swift might be the new BASIC"

    slightly OTT??????
    • Impact ColoSsal

      You'd better Get LOST to GraveYard of MalDroid.

      Thank You, David, This Has Been BEST SUMMARY on Swift So Far Showing The Inplication to Come in Multiple Directions Very INSIGHTFULLY !!!!!!
      • Thanks child

        Back to school now
      • noting how many times iTunes has been hacked,

        including the developer center... or the iPhone SMS hack, or the recent ransomeware attack in Australia, your childish name calling of "Maldroid" as means to suggest iOS is impregnable is laughable. Especially when it's harder to root Kitkat 4.4.2 than it is to jailbreak iOS 7... if the OS can easily be broken that route, then what gems await...
  • Hang on.

    Wasn't there an article yesterday saying the complete opposite to this? That Apple had completely missed the mark with Swift, and that it was "Counter intuitive"?
    • Frankly, I think that accusation was nonsense

      Swift does some nice things.... some of which the others have already done, like inferred typing. There's more logical thinking than in some historical computing as well, with rather than declaring "constant" this or that, you just assign with a "let" statement.

      The really nice thing about Swift - no more semi-colons to end lines. As someone who has worked with both BASIC and C languages, I always thought that was one of the dumbest things about C. Yes it lets you do multi-line statements, but otherwise is just largely clutter.

      Its a big step up for the Mac, though Windows programmers would (rightly) sniff that this is stuff they've all had before for the most part.
      • I agree.

        I just think it's bad journalism having two contradicting articles.

        It's definitely been a step in the right direction for Apple programmers.

        Although I'm not much of a programmer, so my analysis is not really the best. But from what limited experience of C# I've had, it's not completely the best to work with. Maybe it could be a step for Microsoft to follow with something new of their own.

        But again, not being much of a programmer my assessment could be way off.
        • I couldn't disagree more

          In my 15+ years programming, I have found C# to be the absolute best combination of power, ease of use and flexibility of any language I've ever used. I think Apple was the one who learned some things from Microsoft in creating Swift.
        • C# is great

          I've been programming in C# for over 10 years now. I think the language is great, and I would venture to guess that much of Swift was inspired by C#. C# isn't my favorite language anymore, Scala occupies that spot. Judging from what I've seen with Swift, I would also say that Swift is a better language than C#. It doesn't blow C# away, but I think Swift is a bit more powerful and quite a bit more elegant than C#.
      • As a programming of more than 2 decades I have to disagree

        I've been a consultant for many years and have worked in many languages. I have read through the entire Swift quick start and all the articles in Apple's site around Swift. I have not read the iBook yet (and no PDF? Seriously?). With all this in mind, I can say that Swift is still a far cry from Java or C# in its elegance and diversity. Its a far cry from JavaScript in its ability to be dynamic and fluent. Its not even close to being as understandable as say VB or VB.Net to a laymen or novice. About the only thing I can say about it is that it gets rid of some of the C-style clutter such as defined constants and explicit pointers (which is an advantage of Objective-C). Why not just implement the Java API or just go all in on C++? From everything I've read, my next iPhone app is just going to be slightly less painful than the other ones. If your big language claim is "look, we're 20% less painful than we used to be" you're doing something wrong.
        A Gray
        • What can C# do that Swift can't

          I've been doing C# since the 1.0 days. I also looked at the documentation on Swift and I noticed a number of things that Swift does better than C#. Swift has support for tuples, pattern matching, and it has a weak keyword to indicate weak references. C# doesn't have any of those features. Swift also has a succinct syntax for string formatting. It's much cleaner than C#'s String.Format() method. I also think the let binding is substantially more elegant that C#'s readonly or const variables. With Swift I can even use let to create a readonly local variable, something that cannot be done in C#. The only thing that C# seems to have over Swift is Expression Trees, which are awesome but probably not terribly useful in iOS development.
          • Sure C# Can Do Those Things and How About LINQ

            How about the Tuple keyword in C#.
            Or the WeakReference keyword in C#
            For Pattern Matching use Regular Expressions

            C# also has a lot more power in LINQ. There's almost not a project that I've seen which doesn't use LINQ. There's also things such as Async
          • Important Differences

            C# doesn't have a tuple keyword. Instead it has a generic Tuple class. There's a huge difference between a library and full blown language support for tuples. The biggest difference is in Swift I can give names to each value in the tuple. It's a lot easier to make sense of meaningful names than Item1, Item2... properties. C# doesn't have a WeakReference keyword. That is also handled with a class in the library. It works, but it's kind of ugly. I would rather just have a keyword like Swift does. Regular expressions and pattern matching are completely unrelated. Pattern matching is a complicated feature in Functional languages that allows you to do runtime decomposition of objects. I suggest googling about it, because it would take too much time for me to explain it here. Linq is truly awesome. It's also just a straight forward copy of standard functions that exist in pretty much every functional language. Swift has these functions too, they just use the more standard functional names, such as map instead if Select or filter instead of Where. You may be referring to Linq to SQL, but that's what I already referred to when I mentioned Expression Trees. You have a good point on Async and Await. I suspect Swift solves the same problem using Futures, but I need to look that one up. Even so, async and await is easier to use than Futures, but not by a lot.
          • All modern languages can do async

            I've never understood why the "C# only crowd" gets themselves convinced you can't do asynchronous programming or threading in other languages - of course you can!
          • Yeah, but C# does it really nice

            I think what a lot of C# developers are referring to is C#'s async and await keywords. These make it much easier to synchronize results between asynchronous calls. Futures allow this same thing, but async and await is cleaner. Scala is adding async and await, and it works really well. Hopefully Swift will add something like that in the future.

            Scala snippet for checking and adding user using Futures:
            case None =>db.AddUser(userName...).map{newUser =>
            case Some => Future.successful{UserExists(userName)}

            C# snippet for the same thing
            bool userExists = await db.UserExist(userName);
            //Report that the user exists in some way
            return await db.Createuser(userName);
          • there is also .ToString()

            that can do a lot of simple formatting, you do not have to .Format every time.
          • ToString is only good for trivial tasks.

            I know about ToString. Like I said, I've been doing C# for 10+ years. ToString is pretty limited when it comes to string formatting, that's why I end up using string.Format for anything that isn't just completely trivial. Swift's string interpolation capabilities are just much easier to use. Consider the following examples:
            left hello = "Hello world"
            println("printing the variable \(hello)")

            Notice how I can just access the variable directly in the string. That's so nice. There's no risk of my format parameters not matching my format string, and I can just look at the string and see what variables are going to be displayed where. I can even call methods from within my string interpolation expression.

            Here's C#
            var hello = "Hello world";
            Console.WriteLine("printing the variable {0}", hello);

            Notice how I have to line up my argument with the {0} in my format string. This gets much worse as the string gets more complicated. Furthermore this isn't typesafe. The compiler doesn't care if my arguments don't match format sting, because the compiler doesn't know anything about format strings. One of the most common errors I get in my C# code is a mismatch in my format string and my arguments. Resharper helps, but it's nicer if the language just takes care of the issue for me.
          • Fixing error

            Swift line should read:
            let hello = "Hello world"
          • Yeah, this I love

            Even Obj C can do the old C style string replace on {0}.... this is a new way to do it, and a much nicer way if I may say.

          HA, Ha, You're Revealing That Your 2 Decades of Programming Experience End Up Providing You Nothing INSIGHTFUL, LOL Amen.