Re: No side effects holy cow. ( Re: process order (still...) )

[David Tolpin <dvd at renderx dot com>]

> 1. Is it reasonable to utilize 1024 processors to process a small 
> document?
> 

God knows.  Is it reasonable to allocate 100 bytes for each byte of the source
document? Ten years ago it was definitely not reasonable for most
word-processing systems. Even when Unicode was not yet widely accepted,
doubling string lengths used to be the main argument against its use.
In the present days of XML a word processing software it's some 16 Mb
of RAM to process ten pages (i.e. 8 Kb of text) document, that is not 100,
but 2000 bytes of RAM per character. And nobody cares.

 > 2. If document is large - it'l eat the entire memory ( XSLT lacks
streaming),  > so the problem will be not to find extra processors, but to find
some more  > memory.

Once upon a time I used to be extremely proud because of designing an algorithm
of clever streaming for a formatting system.  It was before paged virtual memory
became available on everything downto PDAs. Currently,  efficient VM management
works better than streaming.

> 
> Are benefits ( mythical ) worth limitations ( real ) ?
> 

Benefits are always mythical. Limitations are always real.  And it is the main
moving force of technological progress. A solution that fits all limitations
and pays the price by neglecting benefits is a one-day bird.  Almost anything
that is technologically great today because of fitting limited computer
capabilities, not due to ease of use and understanding by human, is a looser in
ten years and probably earlier.

Examples include, "but are not limited to"

while(*a++=*b++);
Symmetric MultiProcessing for Two Processors and No More
Single Lens Reflex Photographic Cameras
Internet Telephony
Immigration regulation rules
and, I dare say it, other countless examples.

> Well... "No side effects" sounds very cool ( it is a good thing to 
> use wording like this when talking to management. The word 
> "shorthand" is also helpful, because it sounds much better  
> than "hack" ).  
> 

Working with a manager who understands benefits of a language
without side-effects is a dream of mine for the last decade. And, if
you are able to keep something next to your fingers while leaving
other tools in the box, it is great. And those tools are "shorthands".

While trying to fix a watch with a hammer is a hack.

> On another hand, when I'm explaining core principles of 
> XSLT to some novice *developer* , I'm using another wording. 
> I'm usualy saying : "because people who created XSLT are LISP 
> developers, they decided you can live without assignable variables, 
> that means to accumulate a string of N spaces, you should write 
> some code like this ... but you can not do it with something like 
> for ( i = "....).

Fortunately,  or, better said, I hope that ,people who developed XSLT are not
LISP developers, be it a good or a bad thing.  Being a good professional does
mean not being bound to any particular point of view.

Besides that, no-side-effect holy cow has nothing to do with LISP. LISP is about
S-expressions and lambda-calculus (sometimes). Most lisp developers like
set-car!, set-cdr! (speaking in Scheme tongue) much more than one can imagine.
No-side-effect idea is much better represented by other languages,  designed
in a more consistent functional manner than the purest dialect of LISP.

Isn't XSLT more like Prolog?

On the other hand, in Lisp, one can easily do almost anything with for(;;), and
the lexical construct is almost identical - just to let you know. Just grab the
CLtLII and take a look at the language basics.


> By the way -  another XSLT holy cow is xmlish notation. 
> "To save parser footprint".  Anyway XSLT implementation has 
> to implement XPath parser, so savings are mythincal, but 
> extra-verbosity problems are real.  
> 

Verbosity is good. Terseness is bad.

David Tolpin


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list