> Doesn't seem like there is any fundamental reason for Ruby to run slower.
I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.
I think that all the metaprogramming magic that Ruby allows is at odds with speed. That is not to say that it's impossible to make it fast, but it's probably tricky.
I don't think so, Java and C# also have metaprogramming (reflection, class loading, bytecode manipulation) and they are still plenty fast.
Ruby's liability is that it's dynamically typed, and this puts a hard limit on how fast it can be (and also on how toolable it can be, but that's a separate discussion).
If you do a lot of reflection in Java then you'll end up with some pretty crummy performance, but the average Java program doesn't have much.
That said, JavaScript is not far off of Ruby's monkeying capabilities and yet pretty darned fast.
Lisp + Scheme: I mean if nothing else, people have been trying to make them fast for the last more than half of century. Plus AFAIK most Lisp meta-programming code is generated during compile time through macros not during run-time.
Dylan: I don't really know anything about Dylan but it seems to have come out of Apple and CMU, so there's that. Plus it seems to be just a Lisp dialect.
Smalltalk: You consider Smalltalk fast? Lol.
Well, any Smalltalk JIT beat the standard Ruby implementation hands down, what can I say?!
Well, Javascript allows almost as much metaprogramming (and with ES6 proxies and such, exactly as much).
b.) It also has Google pumping a LOT of resources into making it fast.
OTOH, grep for instance_eval and class_eval in rails source.
> OTOH, grep for instance_eval and class_eval in rails source.
I mean what's your point. Yes, I realize that both are used profusely, which is one of the things that this discussion is about.
I didn't describe metaprogramming, just how I usually see common metaprogramming "magic" implemented in javascript. The only reason you'd really need eval in js metaprogramming is if for some semantic reason it was nicer to accept a String of javascript somewhere. Afaik eval doesn't "get" you anything in javascript (it doesn't "unlock" private closures scope or anything, and context-injection is available using #call or #apply) and I almost never see it used, unless I am forgetting something (totally possible, I've been up all night)
> I mean what's your point. Yes, I realize that both are used profusely
My point is I don't see eval used profusely in javascript, which contradicts your assertion in a).
Edit: nvm, I stand corrected: (function(){var x = 1; eval('console.log(x)'); })() prints 1. Neat. But still, I do not see this often used, the callback + context passing approach is much more common.