My talk at App Builders 2016 was on Apple’s best programming language. Spoiler alert: it’s Dylan. Or is it?
I chose a few properties one might wish to find in programming languages, then demonstrated how these were all present in the Dylan language. I also took a dig at certain other languages, which do things in ways that could be seen as less good than Dylan’s. For example, did you know that there’s a programming language out there which distinguishes constant from variable values with the words let and var, rather than using the arguably more readable constant keyword?
Now here’s a thing: of course there are many things iOS app programmers could have been using if we didn’t want to use Objective-C, without the addition of Swift. Indeed, a few months before Swift was introduced I enumerated some of these alternatives on this very blog. However, many of us chose to use Objective-C rather than any of the alternatives, and then chose Swift when that alternative was presented.
Similarly, Apple could have pursued any of those alternatives, and indeed did pursue quite a few of them. What would the world look like if Apple had invested in MacRuby? It would have Swift in it, we know that because they did and it does.
At the end of my talk, I invited the conference to discuss what it was particularly about Swift that led to its brisk success, when it can be considered equivalent to many existing alternatives in numerous ways. Here are some of the suggestions (none of them from me, all from the audience):
- Apple now isn’t the same as Apple in Dylan’s time
- “Halo effect” from iOS
- people only want to use first-party tools
- Objective-C pain provided the opportunity
- big enough community to reach critical mass
That leads me to wonder how closely related the conditions for “better” and the conditions for “accepted” are, whether there are “better” things out there for programmers that haven’t been adopted, whether those things truly are better, and how aware we all are of the distinction between being better and being popular when we make engineering choices.