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

----- Original Message ----- 
From: Khun Yee Fung 

> This observation about popularity is certainly true. But if you look at what
> has been happening, the picture is actually quite interesting. The one truly
> dominant language since the '60s is COBOL. Every other language can be
> considered as a niche language when the number of programmers of the various
> languages are compared. Only in the last 10 years that other languages had
> made any inroad.

I disagree that programming laguages which are not based on a 
concept of  'assignable variable'  are in  any way widely used in this 
world comparing to the languages which are based on a concept of 
'assignable variable'. And I don't think that 'assignable variable' 
is evil concept, because we are using boxes to store  things 
inside the boxes. 

> If you look past the number of people programming in a certain language and
> look at different domains instead, the picture changes quite a bit. For
> instance, SQL (mostly side-effect free as well) is dominant in the database
> field. 

This is very good point. SQL can afford to be side-effect free, because 
the database itself is a huge 'side-effect'. When all the data 
are always in place and there is no resources wasted to deliver the 
data into the place that needs the data - "no side-effect" is affordable.
The last but not the least. In SQL dependences are kinda simple.
See below.

This is related to your ( very nice ) long letter about the new paradigm.
I *absolutely* agree with things you have been saying in your letter, 
I just make another conclusion from the same facts.  Here we go.

In your long letter you have explained the domination of result-tree over 
templates. I *absolutely* agree with your point of view. The supporter of 
'self-growing tree'  that is what XSLT realy is. That means XSLT is perfect 
for some particular transformation, described in your letter.

Now let us spend some time trying to understand what is the real nature 
of the 'self-growing tree'  transformation. 

The key features are:

a.  transformation is driven by the 'root template' ( or better to say:
the "initial knowlege of what is expected"). The tree 'knows' what 
should happen 'in general' . When it comes to leaves ( leaves of 
resulting tree, I mean) - we are just 'going into a bit more detail'. 

b. There is no way for some leave to request the information 
about what *will happen*  with some *other* leave.

Consider the situation: 

    I'm processing some branch (B). The number of leaves I want to 
    produce on this branch B depends on the number of leaves 
    that *will*be*produced* on some other 'preceding' branch (A). 

    I mean what if I want my branches to grow one after another 
    and to share the information between them so that I can 
    use the 'knowledge' one branche have accumulated till it grows
    to pass that 'knowledge' to the branch that'l grow *next* ?
    
    Because branches and leaves have no 'state', no 'memory' , 
    no 'context' ( no 'side effects', no 'order' ),  I can not just remember
    the number of leaves that will grow on branch A  when 
    growing the branch A and then pass that information to the 
    branch B. ( Very natural thing in the world which is driven 
    by those ugly updatable variables  AKA 'memory' , right ? ). 

    What can I do instead, if I realy need to know the final number of 
    leaves on branch A at the time when I'm processing branch B ? 

    When processing the branch B  I should in some way 'predict' 
    what will happen with branch A.  

   That means that  I should do the same thing ( builiding of branch A)
   twice.  Firstly I should emulate what will happen on branch A 
   ( because to know what will be a resulting number of leaves on 
   branch A, I have no other way than to emulate  the entire process of 
   constructing branch A ). But this emulation has *nothing*   to do with 
   the *actual* growth of branch A ( because the only purpose of the 
   emulation was to get only the resulting number of leaves on A, for 
   processing *B* ). So I also need to repeat this process to 
   get A in place.

   Uh. OK. That means when I have 2 resulting branches with 
   dependences - I *have* to do the same thing twice. Plain 
   overhead. I'm not talking about more complex situations with 
   more than 2 branches ( when A depends on B, but B depends 
   on C  - how many times we'l have to re-calculate C ?).  

   I hardly belive that  those 1024 processors will help too much here.

   But that's not the end of the story.

   So we come to the understanding that my stylesheet should 
   do something twice ( one action is done inside 
   <xsl:template  match="A", but another is done inside 
   <xsl:template  match="B"

   1. I don't  think we have to use cut and paste in 21 century, right?
   2. That means - we need some function here. Right ?
   3. Welcome to the beautiful <xsl:call-template *absolutely*not*readable*
   verbose crap - and that crap should be *complex* by definition.

   That means we are in some real trouble with this transformation? 
   That means XSLT has some serious problems with some kind of 
   transformations ?
      
   Those who are thinking that the transformation described above 
   is not a common thing, may grab some book describing XSL 
   transformations and I bet they'l find some practical example 
   of this particular transformation. It is pretty common. In the absence 
   of XSL FO ( and there is no XSL FO for plain text ) the transformation
   described above could be *very* common.

   But this is still not the end of the story.

c.  The 'result-tree-driven' transformation is a transformation when 
   result tree 'pulls' the data from the outher space. That means 
   you are fine *only* if your data are in place and you have no 
   overhead for providing the data to the result-tree-fragment 
   which decided that 'now I wanna pull some data from the 
   outher space'
   
   The easiest way to saticfy that unpredictable pulling 
   monster ( I mean 'result-tree-fragment' ;-) is to have 
   data always in the memory and *not* only in the memory, 
   but in the form that  is familiar to that monster. ;-)

   And please remember - we still need to pull some data 
   at least *twice* ( for the reason described in (b) ).
   
   This explains why James Clark's XT on top of DOM is 
   much slower than the same engine on top of OM.
  
There are several possible conclusions, but I'l made 
just one ( again ):

    Result-tree-driven transformation is *perfect*  for rendering 
    standalone document with no complex calculations involved.
    Unfortunately, this is not the only transformation we have in this 
    world.

When you are making any step *away* from this problem domain 
( document()  *is* such a step, for the reasons explained above )
you are getting trouble. The far you move - the more trouble you get.

> So far, my experience with the web developers have been a largely positive
> one. They become frustrated once in a while but it is the same with every
> tool they have to use.

> In the internal training session I gave recently, the attitude among the web
> developers has been very positive. They asked many questions but in general
> were very receptive to XSLT and XML. Beside HTML, Flash, Photoshop,
> Director, etc. etc., XML/XSLT is another tool they have to learn.

ABSOLUTELY no surprize. People who are spending countless hours 
inserting 1x1.gif's into their pages and tricking particular build of 
Netscape not to crush on some miracle combination of nested tables 
should tolerate even plain madness, with other attitide they could 
get some serious health problems.
 
> The same thing cannot be said about the software engineers in the session.
> They are clearly more critical. Being a computer science graduate myself I
> consider that attitude as a failure of their universities to teach them the
> right attitude at learning.

That's what makes me happy, because all the innovation in this world 
get's implemented by those lazy developers with bad attitude who are 
tired of typing more keystrokes than they have to.

Ideas are produced by scientists, code is produced by developers, 
beautiful pages are produced by web-developers - to me every 
part of the society deserves the same respect. I understand, 
such a view is rare between scietists, who for some reasons
( unclear to me) think that scientists deserve more respect
for the things they are doing. ( Please, don't get this personal - 
I very much enjoyed your letters and I don't think you are making 
any difference between developers and scientists. ;-) I also 
have nothing against scientinsts - just wanted to point out that 
feedback to XSLT is mostly influenced by some patterns. For 
example,  no doubt that scientist will enjoy XSLT much more 
than developer, because scientists are usualy not payed for 
producing tonns of working code.  I hardly belive any  scientist 
will have to port dataflow of 50+  financial reports to XML / XSL 
in the timeframe of 2 weeks using bunch of 1-year  developers 
as a workforce. 

Rgds.Paul.



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