Lambda the Ultimate

Although I am font of C++ (99% because of templates), I have to admit it is not an elegant language. There are too many things that have to be added, all exceptional cases, and that's a sign of something without solid theoritical foundations.

I've been playing with LISP lately, and I think that what we need is a new programming language with LISP capabilities from one side and with C capabilities on the other. The LISP side would be a language that would allow programs to be executed at compile time, and thus allowing for infinite concepts (including object-oriented programming) and true expandability, and the C side would provide all the known stuff (pointers, structs etc) that are useful at run-time for truly optimized applications plus direct interfacing with O/S and other services.

The old fashioned way to deal with low and high level programming in C is to write functions in C and use a scripting language that calls your C library. This system is nicely preserved in the Linux world. Since this is the 21 centuary why not simply update this concept to functions and components (ie objects) in dll’s and use along with your favorite high, high level language where you can express your concepts freely. Why worry about pointers if you don’t even know how to solve the problem yet?

Embed a scripting language into the compiler outright (Ruby, Python, whatever) and obviate the template meta-programming agony.
You could as well put wings on a bus and fly it about, given enough velocity.

First on Stroustrups point - there are plenty of libraries available, and it just isn't that important whether they are language standards or not.

The problem is that language issues make life unnecessarily hard whatever libraries you use, and these issues can only be fixed well by updating the language standard. For instance, sure you can write libraries to work around the lack of anonymous functions (see Boost) but you can't magic away the serious limitations in those libraries. The language support isn't there to do a better job.

On to the scripted compiler thing, though, and I basically agree with both Achilleas and Chris - it's just that IMO the scripting language that should be embedded in the C++ compiler should be C++, just as the scripting language used to manipulate LISP code at compile time is LISP itself.

Think of YACC and similar tools. One problem with them is that they don't understand the embedded C/C++ code - they just treat it as a text template. Take a different approach, and YACC could be a library that knows when the embedded code is wrong because it interacts with the compiler during the generation process, in which it creates a ready-compiled module.

Using the Turing-complete template system as a code generator is flawed, partly because it overworks the compiler in terms of creating pointless classes, but also because it is more like Prolog than C++.

If my run-time code is imperitive OOP code, why shouldn't my compile-time code be imperitive OOP code? In fact, why shouldn't I be able to use the exact same code both at run-time and at compile-time? Once I have written some code, I want to be able to re-use that code as much as possible after all.

All that would really be needed is a means of delimiting nestable blocks, a data type representing already compiled blocks, reflection support, and the ability to use "compiler instances" as generated-code absorbing, module creating factory objects. Some scripting languages can already handle most (if not all) of this.

Follow this approach to it's logical conclusion and a lot of C++ tools get a lot easier...

• Want a refactoring tool? Write it in C++ and use reflection to analyse the code semantically. If the 'block-of-code' type supports roundtripping back to source code, you're pretty much done.
• Want to check that your unit tests achieve full decision coverage? Write a library that asks the compiler where the decision points are and adds in the appropriate checks.