An extract from David Moon's presentation of "Lunar":
Most current-day programming languages seem to be based on the idea that computation is slow, so the user and the compiler must work hard to minimize the number of instructions executed. Thus in most programming languages certain data types such as numbers are a special case which does not fit well into the general type system of the language, and hardware details such as the number of bits supported by an integer add instruction show through in the language semantics. Compromises to minimize instructions extend so far as to make familiar-looking operators like + and < behave in unintuitive ways. If as a result a program does not work correctly in some cases, it is considered to be the programmer's fault. But it is really the language designer's fault.
This made sense when Fortran and BCPL were designed in the 1950s, or when C++ was designed in the 1970s. But it makes no sense today.
It does not reflect the realities of modern hardware, where computation is almost free, memory size is almost unlimited (although programmers' ingenuity in creating bloated software apparently knows no bounds), and the principal limit to performance is the cost of communication.
...
Today's languages contain far too many features that do almost the same thing but have slightly different performance characteristics, for example regular and virtual functions in C++. This just encourages programmers to waste time on micro-optimization when they could instead invest time understanding the large-scale behavior of their program and optimizing that. Furthermore excess features make programs more complex and harder to understand.
As inspiration for the source of this:
Lunar can also be viewed as an exploration of what Lisp would be like if pared down to what I view as its essential principles, with historical accidents and dead-ends stripped away. Perhaps shockingly to some, I view both Lisp's syntax and its data structures' basis in CONS as two of those accidents.
I have been developing Lunar as a hobby, with the idea of creating a programming language which does everything the right way for once. You know it is right when both simplicity and power are maximized, while at the same time confusion and the need for kludges are minimized.