“The naming of cats is a difficult matter, It isn’t just one of your holiday games.” The naming of programming languages is also important. As with any project a name is needed to be able to refer to, and it inevitably will set expectations and flavour to some degree.
I’ve had a few different thoughts about names. My first idea was “plato”. Plato was a philosopher and is particularly known for drawing a distinction between the real and the ideal. All things in the real world, circles and squares and so forth, are just poor shadows of the perfect circles and the perfect squares that exist in the ideal, or “Platonic” plane.
I actually think Plato had this backwards (though I haven’t read his work so quite possibly misunderstand him and misrepresent his ideas here). To my mind the ideals that we think about are poor approximations to the real world which, after all, is the reality. The process of thinking (which is what philosophy tries to understand) involves creating abstractions that map on to real world objects and events, and in trying to find the abstractions that are both general enough to be useful, and precise enough to be truthful.
I see the role of a programming language being to fill exactly this gap. It needs to address real world problems and tasks, but does so by generalising and abstracting and treating them mathematically. In a sense the program exists in the Platonic plane while the implementation exists in the real world, and the language has to ensure effective communication between the two.
So “plato” is not a bad choice, but it isn’t the one I’m going to use. I actually think “plato” would be a great name for a “platform” – like “Android” or “Gnome” or whatever. They both start “plat”…
My next thought was to name it “Knuth” after Donald Knuth who has had some influence of my thinking as you will see in future articles. The naming of language after dead mathematicians has some history (with Pascal and Ada at least), but as Mr Knuth is still alive, using the name “Knuth” doesn’t fit that pattern. And it would probably be a bit pretentious to try to use such a name for a little project such as this. So that name is out.
While dwelling on my real motivation for this language, I realised that it really is quite strongly influenced by my personal experience of the last few decades of programming. This should be no surprise, but it is worth acknowledging. It is easy to pretend that one is being broad minded and considering all possibilities and creating a near-universal design, but that is only a pretence. The reality is that our values are shaped largely by our past hurts, and these can only come from our past experience. I must admit that I am escaping from something, and that something is primarily “C”.
I’ve used C quite happily since the mid ’80s and enjoyed it but have always been aware of deficiencies and it is really these that I want to correct. I’ve watched other language appear and evolved and there have been good ideas but I’ve not found any really convincing. Python has a lot going for it and I tend to use it for GUI programming, but when I do it just reminds me how much I like static typing.
So this language is to be my escape from C (at least in by dreams) and should be named as such.
C is seen to be a successor of B, which in turn grew out of BCPL. So the joke at one time was to ask whether the next language could be “P” or “D”. Of course it turned out to be “C++”, a joke of a different kind. And then “D” came along anyway.
What do I want to call my successor of “C”? The answer is easily “Ocean”. Oceans are critical to life in many ways, but dangerous too – they need to be understood and tamed. Oceans are big and wide with many unknown and unexpected inhabitants. If I want an arbitrary name for something else related to “Ocean”, I can use “Pacific” or “Indian” or “Atlantic”. And of course an “Ocean” is like a “C”, but more so.
Having admitted that Ocean will follow on from C in some ways, I should explore a little what that means.
Primarily it means that Ocean will be a compilable language. I’m not at all against interpreting and JIT compiling but I don’t like to require them. The runtime support code should not need to include an language parser, unless explicitly requested. This means for example that a function like “eval”, which can be given some program text is completely out. Similarly interpolating variable names into strings with “…${var}…” is not an option.
Some degree of introspection is probably a good idea – I haven’t really decided yet – so it may be possible for a program to manipulate language objects. But this must not be part of the core language and it should only exist as a library for programmers with particular needs who are willing to pay the cost.
It also means that the programmer should have a lot of control. I’m not sure exactly what this means yet, but in general the programmer should feel fairly close to the hardware, and have an easy clear idea of when runtime support with help out and when it will stay out of the way. Certainly the program should have a fairly clear idea about how their constructs use memory and use CPU.
Static typing is a “must have” for me. This is essential for the compiler to be able to find bugs, and I trust compiler coverage a lot more than test coverage (though that is important too). There is certainly room for runtime type flexibility such as variant records, or values which can be real or NULL. These need to be available, but they should not be the default.
So that is what C means to me: static typing, compilable, and fine control. And that is what “Ocean” must contain – at least.
Now to be fair I must address the question of whether and these early design decisions fit with my philosophy stated early – particularly aiding clarity and minimising errors.
Static typing is almost entirely about minimising errors. By having types declared that the compiler can check, fewer mistakes will make it to running code. The equally enhance clarity by making clear to the reader what type is intended for each value.
“Fine control” is sufficiently vague that it could mean anything. I justify it by saying that it allows clear expression of precise low-level intention.
“compilability” really hinges on the lack of “eval”, though static typing is often related. “eval” effectively permits self-modifying code, and this is extremely hard for the compiler to assert anything concrete about at all. So I feel fairly comfortable asserting that “eval” is a great way to introduce hard-to-detect errors, so it should be avoided where possible. If some limited for of “eval” turns out to be particularly valuable, that can certainly be revisited when the time comes.
So while my language has no content, it now has a name: Ocean, and even a website: http://ocean-lang.org/. Anything could happen next… but it will probably be something lexical.
