This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: No side effects holy cow. ( Re: process order (still...) )
- To: xsl-list at mulberrytech dot com
- Subject: Re: No side effects holy cow. ( Re: process order (still...) )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Fri, 14 Apr 2000 20:38:05 -0700
- Organization: The Qub Group
- References: <E09B8717558DD211BF0300609793FBB0020160C2@MAILSERVER>
- Reply-To: xsl-list at mulberrytech dot com
----- 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