The Omega programming language
langnostic.blogspot.com
langnostic.blogspot.com
In this spirit, consider a lesser-mentioned language from the same era- Forth. Discard any preconceptions you may have about stack-oriented languages and take a few days to sit down and read "Thinking Forth"[1], which delves deeply into the architectural philosophy that goes along with the language. Forth is at once mind-numbingly close to hardware and surprisingly well-suited to readable, high-level expression.
"Omega" was a reference to the Seibel talk I quote from, in which he casually postulates Omega as the most powerful language that might be built for current architectures.
The thing is, you couldn't have a convergence of Lisp and Haskell without destroying what makes them good at the same time. The essence of Lisp is that it is endlessly dynamic, the essence of Haskell is its insanely strong type system. I can't think of any way these could be effectively combined.
These languages aren't converging on a as-yet-unknown Omega point, they started at more or less the same point and then took off in completely different directions, and they aren't looking back.
The conclusion of the article was more or less that you can't get a perfect combination of the two, and that any unification that might emerge will have to make decisions about which features to cherry-pick.
I'm also not clear on what you mean by "they started at more or less the same point".
As for the same starting point, both had their origins in academic programming language research. It's true they don't have a direct common ancestor, but the point I was making was that their creators were aware of the issues, and chose very different directions as solutions to basically the same problem.
Java is a scalable language, for example, and using it correctly makes a good programmer. This goes for every language, whether it's C, Python, Javascript, ect. Good programmers know a wide variety of languages and when it comes to 'Omega' I think it's the combination of the languages used what they are meant for.
It may be true for things like SQL (or PS or the many, many DSLs out there), but general-purpose programming languages are implicitly (perhaps tautologically) supposed to be good for the general case.
It goes without saying that if your list of requirements includes something like "our deployment environment will have 16 kb of memory and an 8 mhz processor and no network interaction", you don't want to use something like Erlang. But except for such extremes (which I probably should have explicitly stated I'm not thinking about), it is possible (and necessary) to distinguish between two languages on the basis of power.
I probably should have just linked to http://www.paulgraham.com/avg.html instead of writing anything, because the "Blub Paradox" section makes the above argument much more eloquently.
There might be room for some unspecified mix of these qualities on an argument over the "bestness" of a language.
But I'll quibble here and mention that power is conventionally defined as ONLY expressiveness/terseness with no consideration of maintainability.
In the J programming language:
quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#)
Now that's raw power... (and may not fit all requirements!)
The traditional snippet associated with that argument is the Game of Life in APL. http://www.youtube.com/watch?v=a9xAKttWgP4
And yes, this is specifically why I opted to redefine "power" in my post; the standard definition leaves out some points that I've found to be essential.
If all the weights are equal, then I'd argue for Python, though I'm sure plenty of Rubyists and Lispers and Haskellians would disagree.
And yes, from what I've seen/heard, plenty of Rubyists, Lispers, Haskelliens, etc. would certainly disagree with you.
It may be the case that the weights are affected by individual tastes and requirements, but the construction of the language (and therefore some inherent property of the language, rather than of the user or of the situation) would almost certainly affect those weights as well.
I don't agree with this statement...I would say that Java is worse than Python for just about any given set of weights.
By putting all of the type system in the parser, but leave the runtime as a fully dynamic late-bound JIT VM. There is already a precedent for this in Java and in the Strongtalk variant of Smalltalk. To complete the picture, we just need a way to map the types before the code-change to the types that exist afterwards. There's already been some work towards this. (Java/Eclipse)