Swift

If you had told me before WWDC 2014 that Apple would introduce a new programming language, I would sadly shake my head. So many programming languages are created without leveraging any of the lessons of languages that have been around for decades. My general attitude is that there is little reason to create a new language instead of building off an existing one.

So far, however, Swift has impressed me. I can’t really find much to complain about.†

You could argue that in many ways Swift does build off Objective-C rather than being a new language, but that argument sells Swift short. This is a very impressive design.

†OK...here’s a...observation: It seems like having some kind of cycle-detection to augment ARC ought to be there.

Is Apple prepping a new programming language?

waffle → Surpass:

It is my belief that Apple is definitely working on a new language to surpass Objective-C as their intended, primary, publicly recommended programming language...

I’ve been thinking that it seems very strange that Apple’s primary language is (still) Smalltalk grafted onto C.

If he’s right, I hope that, like the A4 processor (which is ARM based) and Safari (which is HTML, CSS, and Javascript based), it isn’t a wholly new language.

Would Smalltalk be a hard sell to developers who have accepted Objective-C?

Apple’s mistakes

From the iPhone OS 4 SDK, section 3.3.1 of the iPhone Developer Program License Agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This is one of the ways that Apple is keeping Flash off iDevices. It—intentionally—keeps more than Flash off of them. (See “Thoughts on Flash”.)

It is, unfortunately true, that cross-platform frameworks often have lousy user experiences. Not merely “un-Mac-like” but just plain bad. It’s true that they often only end up supporting the lowest common denominator. It doesn’t have to be like that, however. Cross platform frameworks can support platform-specific features. I’ve worked on ones that have. It is all too rare though.

There’s also the fact that some apps—especially some games—don’t really need standard user interface elements. Flash (and other options) can work well for these things. If anyone chooses to use Flash for another sort of app, they’ll quickly lose to non-Flash apps. I’m glad not to have Flash in Safari on my iPhone or my iPad, but I don’t mind Flash apps.

Section 3.3.1, however, doesn’t only ban cross-platform frameworks. It bans writing honest-to-goodness Cocoa Touch apps written in any but the specified languages. (“Platform Control” by Mark Bernstein.)

It has been suggested that a compromise might be to require any frameworks to be open source. (“A reconciling proposal” by Michel Fortin.) That way, any developer that needs access to a specific feature can add it to the framework. That’s a good idea. Yet, the truth is that such extensions to a framework can be a lot of work—especially for someone who normally only uses the framework.

Ian Bogost has written that “Flash is not a Right”. He is right, I suppose.

Putting aside rights, however, I have to wonder if this is really in Apple’s best interest. I have to wonder if this is really in the best interest of Apple’s customers. Apple’s biggest mistakes, I believe, are when they try to compete via the law. Whether through intellectual property or license agreements. They compete and win in the market. They don’t need to play the legal games.

Objective-C closures

Apple is adding “blocks” (Smalltalk’s name for closures) to Objective-C. See mikeash.com: Friday Q&A 2008-12-26

This is very interesting, but raises a couple of questions in my mind.

Will it require automatic garbage-collection? I believe Apple has also added the option for automatic garbage-collection to Objective-C as well.

The bigger question, though, is after adding Smalltalkesque objects and message-passing, automatic garbage-collection, and Smalltalkesque closures to C, why aren’t you just using Smalltalk instead?

Objective-C++

It has long seemed to me that C++ and Objective-C are very complimentary. It is interesting that they are actually very easy to combine. The result is known as “Objective-C++”. C++ is nice for “value” classes. i.e. Classes whose instances tend to the value of variables. Operator overloading is particularly nice for numeric classes or “smart” pointers. Exceptions are nice too. (Though I still wish C++ had “finally”. Yeah, I know the usual C++ alternative, but that doesn’t mean it can’t be convenient.) Objective-C is nice for “reference” classes. i.e. Classes whose instances tend to be referenced by pointer or reference variables. Add automatic garbage collection for the Objective-C objects, and you’ve got a really nice set of language features. Last I looked, just about all those pieces where there, but getting them to work together on whatever platform you’re on could be difficult. These days, though, I’m preferring vanilla C, Scheme, or even EcmaScript over C++ or Objective-C.