> Hehe, I could rephrase my statement above to use past tense: "mixing
> fundamentally different paradigms was asking for trouble.." LyX isn't
> the best of examples of a /successful/ mix of paradigms, is it? =)
I think LyX is a success. I'm proud of being a part of it. I'm not proud of
the design, but the program is very good. Please don't judge it as an exercise
in computer science ;-)
> There's nothing strange about using imperative programming in class
> methods, or grouping up classes in separate files (i.e. modular
> programming). It's still OO.
> ...trying to represent c++ classes heavily based on multiple inheritance in
> Java; or represent menacing 1980's BASIC-spaghetti with weird goto's all
> over it, in Prolog, is perhaps more obvious examples of less compatible
> paradigms? =)
Not at all. Have a look at Scheme. Scheme is functional language, that
supports OO because functions are first class objects. Scheme also enables
logic programming. Somebody implemented a Prolog engine in Scheme, so you
could write Prolog programs directly in Scheme. Also, Scheme has a form of
goto in it (continuations), and this is much used for spaghetti-like
programming.
So Scheme mixes all these different disciplines, and the result is a very
powerful tool, and a demonstration that it is possible to mix seemingly
incompatible paradigms, in a very elegant and small language.
Standard ML is a different example: In this language, we have a beatiful mix
of pure functional programming and pure imperative programming.
> > 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.
> > Even if the scripting language is not higher level, we still gain the
benefit
> > of much faster development:
>
> First you have to implement the scripting language (done once, not much of
> a problem if a standard language is used along with a ready parser) and its
> API (most of that is also done only once, then a certain amount of
> maintainance and debugging). Constant time, basically.
I embedded Python into LyX in 2 hours from start to finish. Adding the hooks
would take a day. Debugging would take a week of on-and-off work, and
documenting it would take another week of on-and-off work.
> If the scripting language is to be used for implementing portions of the
> /core/ itself, and thus made mandantory, the developers will have yet
> another programming language and API to learn. I don't know about you, but
> I have my hands full with C++, STL, and LaTeX/TeX already. I haven't even
> begun looking into SGML. :P So for me, development time would rather be
> slowed down with a scripting language.
This is true. But in practice, I think the problems are smaller than that.
LyX is a big program, and there are lots of areas where you can work without
understand the other end of the program.
If you take on different glasses, you'll see that a scripting language will
increase the population of developers: Since the set of people that know our
scripting language, and do not know C++, is not empty, we will have more
development time on our hands. Furthermore, the set of people that know our
scripting language and do know C++, will be more productive, because
development in the scripting language is faster.
> For someone who just want to implement some simple inset for his favourite
> odd document class and doesn't know C++ at all, a scripting language with a
> simple API has a lot lower threshold of learning than C++/STL, no doubt.
> If the API grows huge (say, >500 functions), it can appear just as
> intimidating as c++ to him.
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.
> 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!
> 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.
> > Yes, a restricted interface might make some things impossible to solve from
a
> > DLL. I say that's just too bad.
>
> We'd have exactly the same problem with a scripting language; it takes an
> API of some sort that connects to the actual objects -- if the core design
> is changed dramatically, the API will have to change accordingly, and so
> would the scripts using the API. If the API is too weak and restriced, it
> will be equally useless as a restricted DO-to-core interface.
Yes, and that is just too bad.
We have to set modest goals.
> 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.
> 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.
We can ease the ramifications of the redesigns by making the interface small.
Greets,
Asger
