Re: Side effects and large-scale conversion

[Derek Denny-Brown <ddb@xxxxxxxxxx>]

At 10:27 AM 9/23/97 -0400, Sam Hunting wrote:
>Has anyone ever used DSSSL for large-scale conversion (1000s of pages) --
>doubtful -- and if so, did the prohibition of side effects get in the way? 
>Why or why not?

I have not, Butam involved with people who have looked at it (a little)

>Why was the "no side effects" design decision made? Do I misunderstand
>that such a decision was made? If it has been made, is it a significant
>bar to doing "real programming" with DSSSL? 

Because DSSSL has the "no side-effects" requirement, there are a large number
of potential optimizations a 'high-end' processor (designed for processing
very large documents) could do which would emulate side effects, but also
allow for parallel processing of (separate) portions of the document (thus
the render process could be distributed across multiple machines which is
_much_ harder to do if you remove the 'no side-effects' rule.  One easy
task is to define utility functions which query for the value you would
normally use side-effects for.  for static queries which you might use side
effects to memorize, the impl can use traditional lispish 'memorization'
(i.e. once the function is called for a given parameter value, the engine
remembers the return value and just returns that, not bothering to
re-evalute the query), but all this requires you spend some time/money on
building a good optimizer for DSSSL.  

As I see it, one of the most significant gains for DSSSL is that it becomes
_really_ easy to build a distributed implimentation (beyond the work of
build a non-distributed impl), rendering the need for many optimizations
un-necessary (since CPU time for a distributed app is often cheap than
programmer  time to build a good optimizer).  I do not know if any vendors
are building high-end DSSSL engines, but once people start to use DSSSL, I
expect the demand will grow.  (Esp. with XSL and it's relationship with DSSSL)

An alternative issue is that programming without side-effects tends to be
harder for people to understand. (It doesn't relate well to our own
conceptual models for how we would approach a task.)  This may increase the
cost to build the DSSSL style sheets themselves.  XSL will solve some of
that, but it is still _supposed_ to be side effect free. (Note: I expect
there are going to be problem enforcing that...).  This will make DSSSL
'programmers' both rarer and more expensive.  They will be rarer since the
programming model is far enough from how most people conecptualize how it
might work that many of those people will give up rather quickly when they
look into DSSSL, or willl build such ugly style-sheets that management will
decide to ditch DSSSL since this autheor says they can do it better use
tool X.  I expect that will be a significant barrier against DSSSL use in
small companies, especially when there is a lack of traditional computer
science trained engineers about.  (Even then, I have discovered that most
C.S. engineers have little or no experience with Scheme, esp. if they did
not go to an Technical school or an Ivy League....)

Modern research into computer programming languages has focused a large
amount of resources on the issue of making side-effect free languages
compilers efficient.  As implied above, side-effect free lnaguages can do a
great deal to parallelize a program, even where the programmer might not
have expected it, without the programmer having to worry about it.  This
works really well for vector transforms, etc. but has yet to make it into
the more general world.  The point of this ramble being that there are a
large number of current (and previous) graduate students who are spending
large amounts of time working on solving many of the same problem which any
large-scale DSSSL project would want to solve for building efficient
implementations.

Unfortunately building a _good_ high end DSSSL implementation would tend to
be expensive, in time and resources, which severely limits who might
actually invest in building one currently, since the market is also
extremely vague.  (My employer has one customer who wants to use DSSSL, but
has some very odd expectations, and the reality of DSSSL fitting their
plans is rather small, at least within the next 3 years...)  It would be
hard to explain why a DSSSL implementation cost 2x what another solution
would cost, and is slower (for version 1.0).  Then again, I have not
examined the alternatives enough to know for sure how much of a niche there
might be (Eliot, you would be one of the best to answer that?)

-derek
(wishing that DSSSL and XSL where already here... well more so... because
it really would make my life easier...)


     Derek E. Denny-Brown II      ||   ddb@xxxxxxxxxx
     "Reality is that which,      ||   Seattle, WA USA
  when you stop believing in it,  ||  WWW/SGML/HyTime/XML
 doesn't go away."  -- P. K. Dick || Java/Perl/Scheme/C/C++

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist