Lisp, Python and Haskell should never ever be separated by a mere slash; they're totally different beasts.

Sorry, of course they are. I miss-phrased my sentence. I should have said "Lisp optimized, or Python optimized or Haskell optimized", or even "lovely language(s) optimized".

But I didn't start this: "Lovely languages like lisp, python, haskell" (sic).

"we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized."

http://en.wikipedia.org/wiki/Lisp_machine

In general, hardware optimized for high-level languages have been a failure, usually the extra baggage for handling things as machine-level interpreter slow things down nearly as much as a software interpreter. Nothing has been a real commercial success and it isnt for want of trying. Off the top of my head I can think of the Burroughs B5500 which had hardware support for typed data, the Lisp Machine, and the Intel 432. Sun had a Java machine specification, but I dont think anyone ever bit.

There's Jazelle for ARM, it's essentially a instruction overlay that makes the cpu execute all simple and common java bytecodes directly, and call a kernel function for all the hard ones.

However, even that is dying -- it is being replaced by the thumbEE, which is a more generic instruction set designed for efficient code generation from intermediate dynamic code.

There is Azul Systems, that produces massive servers for Java applications.

http://en.wikipedia.org/wiki/Azul_Systems

I don't know how successful they are economically though.

There is forth on hardware, and a long tradition of that. It's still alive and kicking.

IBM has plug-in hardware JVMs for its mainframe big iron. They are ungodly expensive.

I can't find anything about that, it's quite interesting do you have a link ?

edit: found it:

http://news.zdnet.com/2100-9584_22-135319.html

According to Wikipedia, "zAAPs are not specifically optimized to run Java faster or better". Apparently they're just normal IBM mainframe processors crippled to only run Java and XML.

No, C is a portable assembler. C++ was created to add "high level" OO features to C. But the success of the effort is highly controversial, because there are differences between C and the OO model that are too difficult to overcome.

I think the strategy of objective-C is much cleaner, since they better separate the concerns of "writing fast code" and "writing high level OO abstractions".

How, on a site like HN that champions pragmatic entrepreneurialism, can you possibly claim that the success of C++, a language that has been deployed probably more than any other except C, is controversial? It's a matter of fact. C++ won the early OO race. Maybe Java and C# and whatever have since eclipsed it, but it was still a smashing success by all objective measures, and still is by some of those measures. Yeah it's ugly, but end users don't care.

He wasn't talking about the success (popularity) of C++ at all. He was talking about the success of the effort of adding "high level" OO features to C.

I think C++ totally failed at being high level. So, this "success" being highly controversial doesn't surprise me.

Two quotes from http://www.jwz.org/doc/java.html

C (the PDP-11 assembler that thinks it's a language)

C++ (the PDP-11 assembler that thinks it's an object system)

C isn't really a portable assembler. It was designed to be sufficiently efficient on a specific processor (the PDP11, a register based CPU), while providing basic abstractions (function, structures…).

C was an overwhelming success. And so were CPUs fast at running compiled C programs. As far as hardware optimization is concerned, the main characteristics of C are pointer arithmetic, manual memory management, and a relatively low ratio of function calls (in C programs). These are pretty big constraints. So, we ended up with C optimized CPUs. Now what if Unix has been implemented in Forth? All mainstream processors would have been stack based, and optimized for a very high ration of function calls.

C++, by extending C, also have this "portable assembler" nature. It also have a number of incredibly low-level mechanisms which can be used to build pretty high-level abstractions, but it's still an extension of C.