Re: Preaching DSSSL (Re: using LOUT)

[Paul Prescod]

Sean Russell wrote:
> I agree that Lout is easy to learn, but this is the first time I've
> every heard anyone accuse DSSSL of being simple!  The DSSSL
> specification in its entirety is 300 pages long; I've read it thrice,
> and I'm still not comfortable with it, although I'm not above admitting
> that that could be my own lack of common ability.

I don't think that DSSSL is simple, but it is easy to learn. I suspect
the same goes for Lout. DSSSL is easy to learn because it was designed
to be. It is complex because it must handle complex tasks (just as Lout
must).
 
> :-) Scheme-vs-C?  Or just a dig at Java?  I, personally, would have
> preferred some other programming paradigm than the Lisp derivative that
> DSSSL uses, especially since this makes it all the more difficult for
> anyone writing backends.  If Lisp interpreters have the smallest
> footprint, as I suspect, then I'll concede the point.

It doesn't have much to do with footprint. It has everything to do with
performance. In DSSSL it is easy to recognize dependencies between
sections of code. They are fairly difficult to make and they are very
well defined. That means that one can grab a paragraph from the middle
of a huge encyclopedia and format it without formatting everything that
comes before it. If you use a non-functional language then the code to
format the author's initials (at the start of the document) could set up
a global variable that completely changes the formatting of everything
that goes before it. That means that formatting a fragment in isolation
is nearly impossible which makes WYSIWYG editors nearly impossible.
Another benefit of firewalling construction rules is parallelization.

Of course there are functional languages other than those in the Lisp
family, but why not build on decades of programming language research
and experience?

> It might be possible, if the backend API design allows it, to have
> different people working on different parts of the producer.

If you want to stay away from a lot of C++ work, you design it like the
TeX back-end where most of the work is done in TeX code rather than C++
code. Once the C++ stuff is done, the rest is probably parallelizable.
Someone can do tables, someone else page layouts, someone else inline
formatting, and so forth.

 Paul Prescod