Coding is all the rage. Many are arguing it is an essential skill for the modern economy. They believe it should be an essential part of the school curriculum. Fundamentally, what is being asked in coding is a very difficult exercise requiring skill development that has applicability well beyond coding. These skills are familar to those who do economic modelling. Basically what you have to do is express, in a logical, coherent matter an idea and bring it to its conclusion. For economic theorists, this requires playing around with equations but ultimately the tough work is having to crunch through it and see where you end up. For coding, the task is very similar. What you need to do is run a simulation in your head of the way the code is going to play out and then, afterwards, see that actually works. This is quite a difficult process in terms of learning and response. In fact, recently, an idea has emerged that coding should be more responsive and allow for more iteration without the hard task of having to run the code first in your head.
Bret Victor is a former Apple engineer who has been leading the charge in this. If you have an hour to spare, his talks are very interesting.
Bret Victor – Inventing on Principle from CUSEC on Vimeo.
But if you don’t have that time, the basic idea is that you want to be able to code and see the results of that coding right away. Consequently, you can fix errors quickly and focus on the design of the thing you are trying to produce. Think of it as WYSWYG for coding.
Yesterday, Apple introduced a new programming language called Swift. There are many parts to it. For one, it promises to make the task for coding Apple apps (both iOS and OSX) far simpler. The simplicity is borrowed from languages like Ruby and Python. However, Apple didn’t want to just integrate them into their platform because those languages do not perform as well as Objective-C (which is Apple’s current language of choice). So what Apple did was recombine the best features of other languages and built it side-by-side with Objective-C. In other words, coders have a choice to use the new language or continue with the old. Basically, it is a backwards compatible platform upgrade. Not surprisingly, programmers were very enthusiastic.
What was interesting, however, is that Apple chosen to take Bret Victor’s idea that coding should be responsive and build tools to make that so. Within its core programming software, Apple has introduced an interactive playground for Swift that allows coders to see the results of their choices immediately. This allows them to find problems more easily but also to experiment more freely. Apple is betting that this will lead to apps that are better designed.
Of course, as with everything Apple does, this innovation comes alongside the critique that the new programming language appears to be an Apple-exclusive. Will developers want to spend time learning it when it cannot transfer between platforms? Indeed, there is a sense in which it may make inter-platform programming harder per se — of course, it isn’t harder per se, it is just that Apple made their side easier and, therefore, reduces the incentive to port as the relative costs of doing so have risen. But that is Apple’s problem as well. It has to convince programmers to make a specific investment in it otherwise this programming language will fail. This is one of those issues that we can safely leave to one side and see how it plays out.
More broadly, this speaks to a counter movement to the push for coding in the educational curriculum. If Swift represents the future, it also represents a future where much of the hard tasks in coding are taken away — including the task that could translate to economic modelling. This may cause us to have pause about putting these things in the curriculum but it should also alert us to the notion that maybe economic modelling could be conducted using modern tools in a more responsive way to yield better models.
Digitopoly 
A new ‘exclusive’ programming language is not surprising for Apple – They already use Objective C, which hardly anyone else does.
If you want a programming language you can just tinker around with in a ‘playground’ fashion, why not try JavaScript? It’s interpreted, and runs in any web browser, on any computer.
The example given in the article looks similar to something like GameMaker, and it reminds me of the interpreted BASIC that I learned programming with some 30 years ago. Interpreted, loosely typed languages like this are very good for on-the-fly fixing and immediate feedback, which gets you into a lovely ‘flow’ situation quite quickly.
Unfortunately, when building more complex systems they tend to lose the advantages of slower-to-build compiled languages – things like automated detection of errors and typos – and above a certain complexity become completely unwieldy without an extensive layer of management/documentation/testing. Most interpreted programs run quite happily with code that was generated by the cat wandering over the keyboard, and it won’t be noticed until you try and use that particular bit.
These are similar problems that you get with ‘visual’ code designers. They’re fine, as long as your program can be represented as a two dimensional diagram. More complex than that and the visual representation becomes a burden, not an asset. We gave up on flow charts a long time ago for a reason.
Still, it might put a useful limit on the complexity of apps. After all, they’re only supposed to be little programs.
As far as I can tell Swift isn’t dynamically typed though – it’s got the type inference that I’m familiar with from Scala but I’m sure exists in many other languages. It also has some nice touches like not requiring semi colons, ranges, etc…
Incidentally this whole live programming thing isn’t new either, many languages have REPLs and, for example, Scala has the whole worksheets in the Scala IDE and again, I’m sure there are many other examples of similar systems. So at the end of the day it’s just more of Apple “stealing” ideas and doing them well.
I agree with the point about it being locked into Apple systems means it may not get traction. Because a programming language is more than it’s syntax and standard library. Java is a horrible language by modern standards but the ecosystem that surrounds it is what makes it so productive. So I imagine writing micro services and the like in Swift would be rather neat and having them run as native code would be a bit nicer, deployment wise, than having to run on the JVM but without a package manager, a ton of mature, well tested libraries for everything under the sun, etc it would still be painful to do real work with it… Also having support in a real IDE instead of XCode would be a blessing 🙂
Like so many other people on the net, you like to imagine that because you know Java and don’t know Objective C, that somehow correlates with Objective C being a niche language. Not exactly…
TIOBE has Objective C as their third most popular language on the net with 11% mindshare (with Java and C and #2 and #1 respectively, each with 16%). That’s ahead of C++, C# and the scripting crowd of PHP, Ruby, Python, etc.
I would expect that Swift will, within about five years, have taken the place of Objective C. Apple (unlike, say, Microsoft) has a history of, once they make a decision, pushing aggressively to move it forward rather than dithering and trying to ride two horses simultaneously.
Java will presumably still be doing well because of Android (Google’s language efforts so far with D and Go have been unfocussed, totally decoupled from Android, and that seems unlikely to change).
C will probably continue its way down, so we’ll likely see #1 as Java and #2 as Swift.
Apple must have either have the best computer history research department in the business or a good complement of old farts in their software department. There have been interactive languages since the 1950s and early 60s e.g. LISP, APL, Basic, TRAC. The MIT MacLISP compiler produced numerical code as good as the stock Fortran compiler by the late 1960s. Granted, software engineering is a remarkably conservative field, but it’s good to see Apple dredging up some good ideas from the past.
Another golden oldie revived by Apple is the capability system, originally developed for access control in the 1960s. Anyone who writes applications for the App Store or IOS is familiar with how applications are allocated various rights to print, access the web, write files and so on. Yeah, that idea is at least 50 years old. I’m expecting Apple to move into the 1970s which is when researchers hashed out how to deal with capabilities when one has mutually distrustful chunks of code cooperating on your hardware.
If you look at old software, most of it was around way back when. Steve Jobs admitted to cribbing the early 1970s mouse-windows-icons interface developed at SRI and Xerox. By then, WYSIWYG editors had been around for years as had CAD/CAM programs including some really neat constraint management systems. When the first spreadsheet program was invented in 1979, it was a shock to find something new under the sun. There has been amazingly little software innovation since then.