Language... Games.

[G_Morgan]

Originally Posted by mahogny

one language for each problem, or maybe even a mixture (some languages mix better than other though, this is a sad situation). I use mostly Java, C, C++ and Haskell, together special purpose languages like Erlang and Matlab. I hate all of them there is especially room for an eager imperative language that is guaranteed fast but doesn't give you cobol fingers.

No one has yet made a serious attempt to do this. I hear the opinion a lot but what features would such a language have?

Naturally they would need to support the same basic data types and some ABI compatibility is a must but what about classes? If I make a class in the OOP section and overload all the appropriate operators I assume I could then use that as a data type in the other languages without too much pain. When overloading the operators I will by necessity need to do some imperative programming, do I load in methods from another language or does the OOP language have the necessary functionality itself.

In the end it becomes apparent that such an idea leaves you with such a blurred boundary between the languages that they may as well be a single language. You'd end up with compilers that allow you to mix and match them as if they were part of the same. The end result would either be common lisp or c++ with some functional aspects added.

Personally I think Python is headed in mostly the right direction but I don't like the 'whitespace as programming construct' idea and it needs a decent native compiler. Other than that it gives me enough to be reasonably productive in most cases. I'd still use C++ when I need performance though.

[mahogny]

you're really hitting the spot of the problem:

1. what will be the primitive data types?
and my additions
2. what will the type system look like?
3. what would the execution model be?
4. how do we mix abstraction with speed?

the solution will be a core language, something much higher level than say Java bytecode. this also makes sense from an optimization point of view; one big reason these languages are so slow is that you lack C++ style templating (AKA automatic cut and paste coding, heavy inlining). OTOH, from a developer point of view the template system is awful as it makes compilations awfully slow. a good core language will support both approaches, mixable, with templating something you only turn on in production builds.

#1, rather simple if you stick with the most basic types.

#3 can partially be hidden but lazy vs eager semantics clash. in particular, eager OO-style gives really ugly code in lazy languages. Still, I think this is doable if the core language takes this issue in consideration. state of the art research seems to indicate that both models are needed for practical purposes (#4).

#2 is the biggest problem. there is still research going on here but I consider this unsolved at this point. a solution that is viable for production (but awful to theoreticians) is to just specify the number of arguments and then add metadata with additional description (which could even be ignored). this would push the issue towards the future and leave it open for new solutions. at the same time, types are needed for speed and to write safe code, so some standardization would be needed. it just doesn't have to be that rigid. this goes with #4.

then I can add some ideas; I've been playing around with language design for a while and the biggest problem I see is information polution. there is simply too much clutter around the actual ideas in code. for example, even lazy functional languages impose an order on the instructions which is *the* problem to get automatic parallelization. likewise, we specify data structures which by now should be a trivial matter for a compiler. automatic benchmarking can be done to find the optimal choice. there are instances when this turns out to beat hand-optimization since the programmer might not know in advance exactly what the conditions are. if the compiler does the job, the end-user can just invoke a recompilation based on acquired logs of use and get a personally tuned application (probably something for the gentoo hippies).

I find the problem as such rather simple. it's about choosing the right abstractions that fit the machine/compiler but right now people either 1. don't abstract (GC is for weenies) or 2. use the wrong one (theoretics who had too much lambda). few consider the mid-way.