Why do we need a new programming language?
Programming languages are nothing but tools to solve a certain problem. I was always suspicious of claims that a language is a “universal language” that is suited for all sorts of problems. C++ is perhaps the most notorious of those languages. I don’t want to bring all the arguments against C++ that have already been printed lots of times elsewhere. I think languages should be narrower in their purpose which should also make them better suited for the given purpose. Better than a “universal” language in any case.
My background is games programming and in this field the standard solution is, unfortunately C++. There is virtually no alternative. Some game engines, most notably Unity, use C# but that is even worse since it focuses more on the Windows platform, although I believe, there are free C# implementations on Linux. However, C# has other disadvantages, like the Garbage Collector. Garbage collection is the worst of all ideas, mainly because it can defer object destruction to a later point in time, so that the programmer has absolutely no control over the resources to be freed.
Now, back to my original argument. I have been working on games for over 20 years now and I have used C and C++ and I can’t say that I had real fun moments with these tools. There are always problems for which these languages don’t provide out-of-the-box solutions and then there come the libraries. The multitude of libraries out there is staggering, many doing the same things, often overlapping, some doing certain things better, other doing other things better, some buggy here, others buggy there. Some libraries require other libraries, perhaps in a version that doesn’t work on your specific configuration or with a system that a customer might have, which is even worse.
Third party libraries are a nightmare. Of course, one will eventually need some, for instance a fast 3D system is necessary for games and nobody will seriously attempt to write their own, but having to use libraries for simple things like containers, strings, file or multi processing? Here again there are many to chose from, and even though the STL has greatly unified things, it is still a library and it is hellishly complicated, mainly because it does things, which were not considered in the original language definition and now, the library has to rape the language in order to make those things happen. Anybody who has ever dealt with templates of templates in connection with inheritance knows how quickly the STL can get to a level of complication that makes it difficult to write, and more difficult to read programs.
So, one of the things a language should do is to provide all the tools necessary that a programmer will need in his day to day life, so that there is no need for a third party library. This makes the language much larger, but the extra features are rather elementary and the language does not need to provide highly sophisticated abstract concepts so that the same features can be programmed outside of the language. They are intrinsic.
Another flaw of today’s languages is, for those who have experienced old time Turbo Pascal or maybe even Home Computer Basic versions, that they are incomplete with regard to input and output. There are no features for text input and output nor for GUI programming. Again, these things are handled by third party libraries, but what it means for a novice is, that he will not only have to learn the language and it’s probably very complex abstract concepts, but also will have to learn a third party library and possibly the peculiarities of the underlying OS, merely to open a window and perform some input and output. In the old days, one read the Basic manual that came with the computer and was in principle able to write a small game right after finishing the book. That was my experience with several home computers over the years. And the same with Turbo Pascal. A language should contain IO features to handle test related formatting in the console, at least to the level of the Ncurses library and also graphical capabilities. For this, I propose an integral implementation of the X-Windows client library together with a windows manager so that it will be possible to create windows and perform simple text IO as well as drawing commands. Again, this should not go to a level where a 3D game can be programmed with intrinsic commands, but at least mid level GUI applications should be possible with the system.
Today’s computers all have a number of processor cores. Mutlithreading and multi processing programming is a must. Server applications will even need to integrate multiple computers over a network. Therefore Multitasking programming should be part of the language and not only to the extend that a thread can be started and a signal or mutex set, but a full featured system of multiple agents that run in threads and in different processes, locally or remotely and which can exchange messages and enable RPC, all within the language. Of course this requires, that the language also provides a complete network interface.
Finally, another flaw, in my eyes, is today’s focus on Object Oriented Programming. Again, there have been many articles written about the problems of OOP, just search for “OOP sucks” on the web or take a look at this article that describes in great detail the organization of the underlying system in OOP which make it very slow: (http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)
OOP often leads to a huge callstack which is difficult to debug because it is not always clear why a message was sent from one object. Also, in C++ programmers tend to squeeze everything into the class declaration, which results in a list of functions in the IDE which are mostly specialized functions that are part of other functions, quasi a structural breakdown, yet the observer sees all the interfaces in the IDE and is overloaded with interfaces that do not concern him.
Another problem with OOP is the “status” of the object. OOP function interfaces often receive part of their operational data through the function interface and take others from the object itself, which is natural for this type of programming, but it definitely makes Unit Testing more difficult since the data, that define the operation of a function, do not all come through the interface and thus, to test a function in a C++ object, oftentimes the status variables in the C++ class have to be simulated for the test. Not a good solution.
Plus, when defining a function that takes, say two different classes as parameters, it is often not clear whether the function is part of the first class or the second, One can often argue equally strong for both solution and as such, the decision, into which class the function goes, is often arbitrary.
I tried some other languages recently, mostly Ada and Embarcadero Delphi, which is essentially Turbo Pascal, but Ada is vastly over engineered and it’s syntax is even more difficult to get right (just check the Ada section of stackoverflow.com and the type of questions people have who get vexed by unexpected behavior of Ada features) and Delphi suffers from it’s own third party hell where such libraries are also necessary and not easy to install. Besides, Delphi only exists for Windows which is a restriction that I don’t want to accept.
I’m sure there are many more reasons, but I hope the reader will understand why I think that no language on the market fits all my desires, so I really think it makes sense to think about a new language, that is better suited for games and application development.
Now, the reader might think, this is a fools errand, and that would have been true a few years ago. Today, there is LLVM which is a compiler building toolkit that takes care of all the heavy lifting. All that is left is, to define the language and program the front end, that translates the language elements into a precisely defined Intermediate Language (IR). From that point on, LLVM takes over, handles the optimization and the code generation for different processors and Operating Systems. With this toolkit, it is even possible for people like myself, who’s focus has not been compiler building to write a decent compiler as many projects out there show. Many average people have undertaken the task of creating “toy languages”, probably so called because they are afraid of being mocked when they say they “write their own language”. Perhaps they think, LLVM’s promises are too good to be true, but I don’t think they are. I have already played around with LLVM to the point where I could parse complete expressions and print results to the screen via a small runtime library which I wrote in C.
I used Lexx and Yacc to scan the source language, but boy are these two tools screwed up. They work, once you have them going but if you have a mistake in your scripts, god may help you. But writing a lexer and a parser for a specific language isn’t a big problem, so I think, it’s better to write specific code for these parts directly in C. But perhaps I find better alternatives out there and use them.
So LLVM is there, it works, it’s well maintained, even Apple uses it as basis for their C++ compiler, so it must be good. I think it is possible to define and write a language that is better suited for my specific tasks than C++ and that’s what I want to do over the next years. I will post short articles here that describe my progress whenever appropriate. Once I come to the point where I eventually develop code, I will provide all my code as Open Source on one of the share systems out there (https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities) in the hope that some people might find my work useful and will perhaps check it out.
As to my timeline, I am fully aware that this is a lengthy task, especially for somebody working alone and doing it on the side after my main work, so it will be several years probably. Do I expect to finish this task successfully? Not really, but I want to try it at least and if everybody would just let go of any idea that sounds ludicrous, nobody would ever invent anything.