It's fun growing older with computers. In the days of 8085's, we were almost happy to call a subroutine or switch contexts for an interrupt in 20 microseconds; my gosh, addresses and data must be pushed and popped and all of that stuff takes time. The response earlier in this thread showed that an evaluation of a new expression, a much more considerable task, to be the same 20 microseconds... but these days we consider this to be intolerably slow. :O)
rac On Jul 19, 2012, at 5:53 AM, Matthias Felleisen wrote: > > Here is a conjecture at a history-based interpretation. > > Lisp was eval and apply, and that was all there was to it, and calling eval > was dirt cheap -- compared to running code. > > Over the next few decades Lispers learned to "pre-process" Lisp, meaning a > lot of dynamic computation was moved to pre-eval time. At the same time, > Lispers learned that eval is evil in most cases and that it is often > replacable by something simple (like a case dispatch on the op position plus > apply). > > Other languages started being a "Lisp": perl, python, javascript. Instead of > learning from Lisp's history, they re-invented it -- starting from a cheap > eval cycle. Now eval is popular again. Perhaps this is even justified for > initial uses of something like JavaScript. You send some code, it is eval'ed > and the evaluation renders some "image" inside of a browser frame. Done. But > now we do so much more with this interactive script -- manage mail, play > games -- JavaScript needs to have a real compiler too. And as we get into > compilation, its eval will get slower and perhaps JS programmers will > re-learn what Lispers learned. > > But this won't be the end. I predict that in 20 years some other language > will re-invent eval and it will resume from there. > > CS, the science of reinvention. > > > > > > On Jul 19, 2012, at 3:46 AM, Eli Barzilay wrote: > >> Just now, John Clements wrote: >>> >>> I don't think you should be shocked; I believe that calls to eval >>> are essentially triggering full passes of the parser and compiler, >>> dynamically. It's true that you could optimize for certain special >>> cases (such as yours), but generally speaking these use cases are >>> rare, particularly since I'm guessing that the places where this >>> optimization would be possible are also the places where eval isn't >>> needed. >> >> As a sidenote, this is not something that is unique to racket or that >> is new in any way... I first "encountered" this in 1995 in a project >> written in Allegro Lisp -- I was surprised about how slow `eval' was, >> and when I asked about it, the advice I was given is that in extreme >> cases where you really need a fast evaluation of dynamically generated >> code, you're better off writing a mini-evaluator instead. >> >> (Another sidenote: there are some languages with a "very fast" eval, >> like elisp and newlisp. In these languages it can be as fast as >> running normal code, but this is because there is little to no >> compilation done.) >> >> -- >> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >> http://barzilay.org/ Maze is Life! >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
