Comments on Nirav's Contemplations: Your Language is not SLOW!

Okay, I know this is likely to have a negative res...

2009-08-31T18:14:34.969-04:00

Okay, I know this is likely to have a negative response, but I still cannot necessarily agree with the runtime being the culprit of slow.

Let's compare Ruby to Java, purely for argument sake. In Ruby, absolutely everything is an object, even null values (nil). This means any runtime conceivable for this language would inherently have the overhead that objects require.
<

You may ant to look a rebol3 at www.rebol.net when...

2009-06-17T11:49:26.316-04:00

You may ant to look a rebol3 at www.rebol.net when considering if some features of python doom a language to beng slow ...

the classic victim was SNOBOL. That Andrew Koenig...

2009-06-17T11:46:46.911-04:00

the classic victim was SNOBOL. That Andrew Koenig eventually implemented SPITBOL could not saave it - and the objections to GOTO (which we now just call exception handling)
SNOBOL4 became ICON - from which python takes generatord. ICON continues to evolve.
We saw Smalltalk rejected time and again for usng a VM and compiling to bytecode. Then JAVA became a buzzword...

Your point is based on the assumption that somehow...

2009-04-18T13:20:00.000-04:00

Your point is based on the assumption that somehow this particular language feature may get optimized, as different language features were optimized. I don't think though there is any evidence that *any* language feature can be optimized down to irrelevancy.

In my example, python's semantics allow a function name binding to change from anywhere, anytime. I'm not well versed in that

Dimitris, This is still a runtime issue which is ...

2009-04-18T12:47:00.000-04:00

Dimitris,

This is still a runtime issue which is not optimized yet. For example, when C++ introduced polymorphic invocation it was very slow because of VTable design. Over the years the runtime became smart enough to build and invalidate monomorphic and polymorphic caches on call sites (similar to JIT resolve you are referring to) to improve polymorphism. I would similarly argue that

I disagree. There are slow languages by design. ...

2009-04-18T06:43:00.000-04:00

I disagree. There are slow languages *by design*. Look at some performance essays of Guido for example, and you'll notice the language features he has to work around just to try to fix the performance. Like storing in a local var the name of a global function before calling it multiple times (ugly as hell), because these *need* to be resolved every single time since they can indeed change any