On Sat, 21 Oct 2000, Andre Poenitz wrote:
(comparision of stream_cast and XTL)
> I did that indeed, but with an eye on the specific environment "LyX".
> The places where (XTL|stream_cast) has to be used are not the performance
> critical parts of LyX nor have I seen the need for nesting so far. So my
> conclusion was (and is) that the pros of using XTL do not weigh more than
> the cons (read: extra library, binary data).
So you're objection is that the pay-load of XTL combined with binary
formats makes it less useful for LyX.
1) XTL with binary format only is one header file in total.
2) XTL with ascii format is two header files in total.
So I don't see this as a valid objection against using XTL.
At the same time, you list the main advantage of XTL as performance, and
the ability to nest.
My feeling is that the main advantage is NOT speed, or the low memory
overhead, or the nesting part, but rather simplicity and maintainability
in the code, and the performance and expressiveness issues are just
something extra you get for free.
However, a very valid objection is the fact that XTL requires
a lot from the compiler. Too much to be useful in LyX at the moment.
My experience with XTL from other project where the compiler requirements
are not a problem, is that it is very useful in many contexts. It that
way it serves very much as an enabling technology. Once you have it,
you find a lot of places where it is useful.
But, it is clear that XTL has a Public Relations problem. It seems
that for some reason some people feel that XTL is in some way
too complicated or too strange or too something else to be adopted. I
don't know why this is the case, since I don't feel XTL is hard to use or
mysterious in any way, but I can only conclude that there is tension
towards it.
I've tried to educate people about XTL in order to address some of the
anxiety towards it, but obviously I've failed.
So be it. Since we are not ready to use it for compiler reasons, I'm
ready to put the education on hold for a few years.
Greets,
Asger
