I think that this is still a reminant of the mentality that "interpreted languages are slow" when this is just a lazy way at looking at the problem. This hasn't been the case ever since I was in diapers. I've been going back and looking at old LISP machines and what kind of optimizations they've done to get those running fast. Some of the eairly voyagers were even powered by LISP (these being real-time space probe micro-controller-like systems that are far slower the the slowest ATMega on the market right now).
Everything can be optimized at a compiler or a runtime level. Even if you just scale it back to specific idom-optimizations (as you talk about in one of your talks you've done on your JVM work) you can tremendiously boost speeds by 200 to 300% just by writing operation-specific optimizations.
It's a sad state that because of this preceived "it's going to be slow" that no one seems to be attempting to implement things that Guy Steel and McCarthy implemented way back when. This sort of lazy thinking results in the "Just right it in C" mentality that much of the python community holds.
I'm glad at least you and the JVM people are working on this as this is quite important for all CS-focust disciplines.
Everything can be optimized at a compiler or a runtime level. Even if you just scale it back to specific idom-optimizations (as you talk about in one of your talks you've done on your JVM work) you can tremendiously boost speeds by 200 to 300% just by writing operation-specific optimizations.
It's a sad state that because of this preceived "it's going to be slow" that no one seems to be attempting to implement things that Guy Steel and McCarthy implemented way back when. This sort of lazy thinking results in the "Just right it in C" mentality that much of the python community holds.
I'm glad at least you and the JVM people are working on this as this is quite important for all CS-focust disciplines.