I found these blog posts while waiting for some print jobs to finish. It’s Python vs. Eiffel. (Parts 1, 2 and 3) The bit about making explicit input and output is a great idea for a language. But then I use Python more for a scripting language – for which that is a big negative. But I think having languages make explicit tests, boundary conditions and elements of documentation is a huge feature in some situations. 90% of my bugs in C++ are due to obscure boundary conditions. (Although since they deal with quasi database or set conditions I’m not sure Eiffel would help there.)
One thing I have noticed is how little research into languages has affected the major languages — yeah a little has entered C# and Java. But not as much as you’d expect. In a sense we’re still very much in the 80′s.
I do think that the next generation of languages will be oriented around either very smart compilers or very smart JIT compilers. Right now a problem with C++ is that compilers are limited in how they can rewrite your code for special conditions. You can add stuff to it (such as Apple’s Grand Central Station does with Obj-C once you add blocks). But by and large the legacy stuff of C++ that was great in the 90′s is now becoming an albatross as we move to multiprocessor systems. It still has its place (and I still primarily program in C/C++). But I think we’re seeing its limits.
An other language I’ve heard quite good things about is D. It’s sorts of an unholy hybrid of the best features of C++ and Python/Ruby. From folks I’ve talked to it might have been a better horse to back than Google’s Go (which also seems to feature a lot of Python/C++ hybrid ideas).
Still, a lot of these language wars seems the eternal battle between the good and the best. And the best is often the enemy of the good. That said, I do wish the academics and the “pragmatic” people actually coding real world projects would converse more and design useful languages that can solve real world problems.