There are large languages, and there are small languages. Some of my favourite languages are in the latter category: Io and Scheme, for example. Swift, tho new, is a large language, in a way that seems to offend some of Objective-C’s fans.
I find this confusing—Objective-C is not a small language unless you consider it as a delta from C, and even that’s a stretch. It’s grown considerably over the years with features like properties, synchronization, myriad annotations for nullability and subclassing semantics; in that light, Objective-C is large, too, and C is not exactly lean.
I mention this because the single greatest source of complication to Swift is Objective-C. Broadly, this surfaces as:
These have little tendrils all over the language, sometimes intertwining: how would Swift-sans-subclassing integrate with Objective-C? Would Apple’s existing developers know how to use it? What about the imperative semantics? It’s hard to disentangle them from the language’s identity, too—one can hardly imagine Swift being very useful if you couldn’t use it to talk to UIKit.
It’s even harder to separate out the opportunity cost—how many of the language’s other complexities and inconsistencies would have been reconciled if they hadn’t had to focus on interoperability with a fundamentally unsafe language and runtime with which they share an address space?
While this overwhelms the language’s design, it’s hardly the only example of complexity. Here are some other notorious complexities:
Crucially, the vast majority of this is incidental complexity, not essential complexity. Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).
What, then, should be removed? It’s probably too late to remove any of that, since no matter how many times they’ve warned people that the language can and will change, change can and will disrupt people who’ve already written nests for themselves in the language (e.g. me). I don’t foresee them replacing
But ignoring the language’s users—as long as we’re dreaming—let’s burn most of the above. Leave us with a small, inexplicably curly-braced, higher-order language of algebraic value types and a semantics for interacting with {App,UI}Kit (while we still have to). We’ll do the rest.
I find this confusing—Objective-C is not a small language unless you consider it as a delta from C, and even that’s a stretch. It’s grown considerably over the years with features like properties, synchronization, myriad annotations for nullability and subclassing semantics; in that light, Objective-C is large, too, and C is not exactly lean.
I mention this because the single greatest source of complication to Swift is Objective-C. Broadly, this surfaces as:
- Features designed to ease integration with Objective-C frameworks and applications, e.g.
dynamic, anything marked as@objc,ImplicitlyUnwrappedOptional, and so forth. - Features designed with current [Objective-]C programmers in mind. The syntax is such; the curly braces, the fact that statements are not expressions, and so forth. Further, the standard library does not employ functional terminology or, generally, functional patterns.
These have little tendrils all over the language, sometimes intertwining: how would Swift-sans-subclassing integrate with Objective-C? Would Apple’s existing developers know how to use it? What about the imperative semantics? It’s hard to disentangle them from the language’s identity, too—one can hardly imagine Swift being very useful if you couldn’t use it to talk to UIKit.
It’s even harder to separate out the opportunity cost—how many of the language’s other complexities and inconsistencies would have been reconciled if they hadn’t had to focus on interoperability with a fundamentally unsafe language and runtime with which they share an address space?
While this overwhelms the language’s design, it’s hardly the only example of complexity. Here are some other notorious complexities:
- Tuples (records, really) are approximately anonymous
structs that you can’t extend or conform to protocols. - Add classes in and you’ve now got three different kinds of product types.
- Protocols, subclassing, and
enumgive you three different kinds of sum types, too. - The distinction between value type and reference type, while fairly well-executed, is nevertheless a complication, and moreover it’s one foisted upon the user.
- While not precisely a matter of design, the half-finished nature of Swift’s
enums means that a lot of complexity gets taken on board as soon as you make them generic, recursive, or both. enumcases act like functions, but are not functions.- Properties act like functions, but are not functions.
- Initializers act like functions, but are not functions.
- You can’t define recursive functions within functions.
- Methods are distinct from free functions.
- You can’t constrain a type’s parameters in its methods, e.g. to provide
concatas a method onArray<T>but only whereT : SequenceType. (You can do this with free functions, tho, which makes the distinction between methods & free functions that much more galling.) - The syntax is not homoiconic. I don’t necessarily feel that every language’s syntax should be, but it does make it more complicated.
- Functions are uncurried by default…
- …except for
selfin methods. - The rules for overriding a superclass’
initare Byzantine to the point of impossibility. - You can write functions using
funcor closures, and these are distinct both syntactically and semantically (e.g. the latter cannot abstract over types). - Only functions and nominal types can be generic; notably,
typealiases & properties cannot be. This includes properties whose values are functions! mutatingapplies only to methods of value types.inoutexists.- The rules for parameter labels are different for free functions, methods, parameters with default values, and curried parameters, and you will never be able to remember them correctly the first time.
- They are also inconsistently required: trailing closure syntax ignores them, as does higher-order function passing.
- Similarly, tuple labels are inconsistently required.
- You can’t define types nested within generic types.
- You can’t define generic types nested within types.
- Swift programs starting with a
#!line are interpreted with different rules than arbitrary application/framework files. - But the main file of the program will be treated like them…
- …but only if it is actually named
main.swift. - Playgrounds get the same treatment as scripts.
- You can’t, in general, define types and functions within e.g. the body of an
ifstatement in a script-context file and expect them to work the way they would at the top level. - The presence of subtyping (both via subclasses & protocols) & associated types requires Swift to have syntax for explicitly constructing constraints.
- The type system is first-order, which comes up in surprisingly common cases—you can’t define a protocol which includes
map! - In some cases, this necessitates boilerplate even worse than that to which we were subjected in Objective-C, because Swift lacks a preprocessor. One could always pipe one’s Swift sources through
m4, of course. - The lack of guaranteed tail-call optimization complicates a lot of patterns which would be much clearer expressed recursively. You can still write these programs recursively, of course, it’s just that you’ll blow the stack for unbounded input.
GeneratorType(and thereforeSequenceType) defy pure implementations for every case except forEmptyGenerator. They are bad.- Since Swift is not self-hosting, it does not get the benefits of a type-safe programming model (“well-typed programs don’t go wrong”). This is evident in the crashers still extant in the compiler and runtime.
- …and many, many more.
Crucially, the vast majority of this is incidental complexity, not essential complexity. Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).
What, then, should be removed? It’s probably too late to remove any of that, since no matter how many times they’ve warned people that the language can and will change, change can and will disrupt people who’ve already written nests for themselves in the language (e.g. me). I don’t foresee them replacing
GeneratorType with Stream any time soon, for example, and that’s a shame.But ignoring the language’s users—as long as we’re dreaming—let’s burn most of the above. Leave us with a small, inexplicably curly-braced, higher-order language of algebraic value types and a semantics for interacting with {App,UI}Kit (while we still have to). We’ll do the rest.
