CLIM mail archive
[Prev][Next][Index][Thread]
reducing time overhead of text display (in 1.1)
Ken quotes Gregor:
Of course, we're not going to redesign CLIM, now, except incrementally.
But, we need to work together on these issues. I think Gregor said, "the
one thing you can't hide behind a layer of abstraction, is a performance
problem".
Well, this is my quote of the day!
Seriously, I do not think that this quote is totally true. I am a bit
surprised that nobody is making use of lisp's abstraction power to
*leverage* efficiency. Yes, one would like a environment like Clim
where the programmer cost of doing some fairly hairy GUI stuff is
easy, but the code has little *explicit* representation of the notions
of development cycle vs use cycle. Now, if one had to choose a
language for doing such an explicit representation, would Lisp not be
high on one's list of choices? What I am saying is that one can hide
performance issues of development cycle with abstraction. But the
there is an onus for good user cycle performance on the GUI
infracstructure at the end. This infracstructure support for
performance may need something as radical as Dylan, but I think we can
do things to help our *current* Lisp situation.
In a lot of ways, this train of thought has lead me to be interested
in building Lisp-base re-engineering tools for languages -- including
dusty-deck Fortran code. This is an area where some of the performance
issues discussed can be well separated without a lot of major
infracstructure development for Lisp itself, but still utilizing
Lisp's power of abstraction.
Once I know how to spit out high-performance re-engineered Fortran or
C code, I can begin to take the lessons learned and apply them to Lisp
itself ;-).
Regards,
Albert Boulanger
aboulanger@bbn.com
Main Index |
Thread Index