🚀 go-pugleaf

> Consider why you implemented it in Lisp in the first place.  Because
> implementing complex applications like these is more feasible with
> Lisp/CLOS than most other languages.  

Not necessarily.  Perhaps I like Lisp or am used to it.  Maybe someone
else would feel C++ was the natural choice.  (This sort of thing does
happen.  There are lots of things I would write in Lisp that the guy
I share my office with would write in C.)  Maybe I have to justify
my use of Lisp.  Sure, maybe it takes twice as long in C++, but can
I prove this?

So I think it does matter how slow method dispatch is in Lisp.
If it's significantly slower than in C++, and known to be, then
it will be that much harder to justify my use of Lisp.

> Perhaps you might have gotten a
> program that runs twice as fast using C++, but it might have taken twice as
> long to get it working in the first place; could you have afforded to take
> that long?  (Well, you're in academia, so there may be less deadline
> pressure than in industry, so answer as if you were in industry)
> 
> You managed to speed it up significantly by converting your CLOS stuff to
> structures.  Lisp's strength is as a rapid prototyping language, and you've
> demonstrated that beautifully: consider the CLOS version to be the
> prototype.  If it was well designed, it probably wasn't all that hard to
> convert to a structure-based version once it was complete.  Lisp is good
> for incremental redesign like this.

If you have time.  Remember that you may have to justify writing one
version and then re-working it to be faster.  "Why didn't you write it
the fast way to begin with?" you will be asked.  You may also have to
argue, before the prototype is written, that CLOS is suitable, and 
efficiency may be part of the case you have to make.

-- jd