On Wed, 3 Mar 1999, Asger Alstrup Nielsen wrote:
> > > By extending LyX with a functional language, we can gain a quantum leap in
> > > expressive power. Suddenly we can handle an entire document (or chapter, or
> >
> > Can't we do that in c++ then?
>
> Yes, if we had a *useful* C++ interpreter. We don't, because the exisiting
> ones are bigger than LyX itself.
...interpreter? I have a compiler!
It sounded a bit like: "we extend it with something that is already there,
and lo, suddenly magic occurs!" ? ;)
> The API will be small, simply because nobody has the time to build a huge one.
> Yes, a scripting language will seem intimidating to some. This is why I argue
> that we should have two different kinds: A powerful one (scheme), and an easy
> one that is not as powerful, but sufficient for every day tasks.
Two languages now? =8-@ Two built-in interpretators, two libraries...
I don't have time for scheme, however mind-boggingly powerful it may be. I
wouldn't have any use for it outside of lyx.
> development in the scripting language is faster.
Development time is not compilation time. Thinking, looking up things in
manuals and books, editing, testing & debugging takes far more of the time
for me anyway. If I have to work in multiple languages using incompatible
paradigms, I'll have to do more reading and thinking than if I stick to one
language.
>
> > When it comes to compiling, linking, and start-up, dynamic objects vs
> > scripting language comes out equal; a huge inset could take few minutes to
> > build if it's a dynamic object, and probably some time to load and run if
> > it is a script. For smaller insets the compile-time etc is neglectibale in
> > either case.
>
> The "few minutes" matter! With scripting language, this waiting is a few
> seconds. An order or two of difference!
You said: "The API will be small", thus it will be too weak for a "huge"
inset. And no, I don't see a few minutes of compilation as a problem.
I can do with a coffee break.
Besides, I was just guesstimating. (a full recompile takes an hour or more
on my dx2, mathmode is roughly 10% of the code for comparison. 10% of one
hour is 6 minutes.)
>
> > A dynamic object could be debugged without loading the lyx core into the
> > debugger at all, or using a stubs-version of the core, or loading it with
> > the real thing, depending on how much the object interacts with the core.
> >
> > How would I debug a large script? gdb would be pretty useless.
>
> You would only write a huge script if you are maschocistic (sp?). You would
> rather use the script to hook into a C++ dll, and debug that with gdb. Or
> alternatively, write it directly as a module in LyX.
Ok, we drop the `powerful' Scheme then. That's a relief.
> > As I said before, my favourite is a combination of scripted objects and
> > dynamic dittos.
>
> This set-up is fine with me. I'll focus on the scripting, and leave the
> dynamic stuff to you. But I still can't see why we can't just live with
> statically linked objects inside LyX. It's not like LyX is close to being
> overbloated with all sorts of strange features.
Isn't it? I hear rumors of python and scheme and all sorts of strange things
now. =) Look at the last weeks of 1.0. Things are being added
(statically linked) already. The packages at CTAN are legion, and we get
requests for adding support for this or that package all the time. Prepare
for a design that can handle the lot.
>
> > In both cases it boils down to have a well-designed core early on, so it
> > /won't/ have to be the subject of significant redesigns from time to time.
>
> Come on, we can never avoid redesigns. No large project has not had a redesign
> every second year or so.
I said "significant redesigns" "from time to time" (i.e. often). We /will/
have that if we have a too closed or inapropriate design to begin with.
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
