It’s a bit early to have formed an opinion on a recently-announced programming language, but as the requisite number of people have asked what mine is (i.e. at least zero) I thought I’d type and see what happens.
Rules in programming tend to be bullshit. This is about one-third of a talk I’m giving later in the year, so I’ll leave that train of thought alone in case anyone’s going to be in the audience.
Anyway, knowing this, we can observe the exceptions to any rule people tend to throw at us about programming languages. For example: “Static types for good engineering, dynamic types for exploration“. Make sure your useing you’re type’s good, and notice how many engineering practices come from programmers who know dynamic languages.
Having thus realised that the rules are nonsense, and that some expert actually sat down and thought about what they wanted to get out of a language in the contexts in which they thought they’d use it. When I did that, I decided on something that goes in entirely the opposite direction to Swift. Starting with ObjC, I’m more likely to end up with Self than with Swift (but then I’ve already told you that I think Sun Microsystems did awesome shit, so that may be no surprise). It probably just means that I’m not an expert, though.
If you’re going to use types, may as well go all-in on using tuples. You’ll probably see plenty of definitions of a tuple, so let me confuse things by adding another:
A tuple is an element drawn from the cartesian product of its member types.
What this means is that unlike boring old-fashioned ordered collections, there’s a known number of things in a tuple and each is of a known type. This is useful for the vexing question of signalling errors, as you can just return something like a
(Result?, Error?) like an industrialised society ought to be doing. It also means that almost every situation in which a method’s interface accepts or returns a collection can be replaced with a situation in which it accepts a known number of things of known type.
But anyway, for the most part our programming languages allow us to accidentally introduce problems that we shouldn’t need to solve, but the biggest problems we actually have to solve lie elsewhere.