That's really cool that this guy thinks dynamic languages have the potential to be faster than C++. Maybe he can write a second article when they are actually faster, with some properly done benchmarks or some valid technical examples.
I do not know why this fact remains so little-known.
[1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...
I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same.
Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc.
The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass.
In these days of 16G developer desktops, is this an unreasonable demand? :)
A lot of functional programming languages have also become quite fast in the last decade. While there are in a sense more fluid than C++, they are normally considered static (and not dynamic) languages.
If you want to compare asymptotic speeds where programmer-hours invested goes to infinity, the lower level languages will probably always win. Like assembler, C or C++.
For benchmarks see: http://shootout.alioth.debian.org/
The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.
On a side note, a lot of the benchmarks had to be reformulated after lazy languages got fast. As far as I know, a benchmark at this side prescribes which algorithm you should use. Haskell (and e.g. Clean) just ignored a lot of the baggage because it was not used any further.
As you don't say how far "in the past" maybe that's nonsense or maybe that's true.
> a lot of the benchmarks had to be reformulated after lazy languages got fast
That's nonsense.
Programs for one benchmark - binary-trees - had to be rewritten because "this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd" and with lazy evaluation GC gobbles up nodes before the whole tree's allocated -
http://shootout.alioth.debian.org/u32q/benchmark.php?test=bi...
Every week there are new programs, often from people who haven't contributed a program before.
One of these days someone will find a way to make effective use of all the cores for n-body, maybe.