Language and Runtime.
The separation of concerns between the programming language and the program itself is being muddled in the systems arising today. Hardly any new language is excluding garbage collection from its list of features—something that I’m beginning to form a negative opinion on. I spend my entire day working on top of the V8 VM. For all the complexity inside my laptop the complexity so close to the surface of what I do, V8, is the most impenetrable. The complexity arises not from the task I am attempting to accomplish: to build a fast hello-world web server. The task is simple: issue accept(2), recv(2), send(2), close(2) system calls in that order - over and over and over - but rather from the JavaScript programming language.
The features hanging off many programming languages are questionable. Does writing an ideal hello-world web server in 5 lines of code require garbage collection, operator overloading, classes, meta-programming, constructors, a user-space scheduler, coroutines? Must the language provide any of these constructs in order for a non-expert to write a simple hello-world web server? What is the minimal amount needed for a “easy” and “dynamic” feeling environment? I don’t know but there is one design constraint I want.
The language and the runtime should be separate. Language should describe the computation while the runtime actions should be described. C is the best example here: the language contains no notion of I/O, no thread primitives, no garbage collection. C translates rather directly into CPU instructions. Libraries provide everything else.
Actually there is a small problem of how C is used in practice: the runtime loader. A simple printf("Hello, World\n") program will execute a hundred thousand instructions before it gets to the bit of setting up the write(2) system call to the TTY file descriptor.
GCC’s practice of dynamically linking to libc by default is a conflation of concerns. Runtime loading, like garbage collection, should not be a function of the language.
Users must understand their creations and the first and foremost is making every single instruction made by that program an explicit statement given by the programmer. Language should describe instructions directly. Modules, libraries provide collections of abstractions.
There a common belief that in order to build large abstractions language sugar is necessary. This is obviously not the case: vast complex programs have been written in C. The complexity does not explode exponentially in, say, the Linux kernel because they lacked language sugar. At most the complexity induced by lack of language sugar (classes, operator overloading, constructors, etc) is a constant multiple.
A good programming language would have a simple print-hello-to-TTY program that compiles into an executable of less than 100 instructions.