This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



> > 2. 'Ordinary developers' are not very happy  when I explain to them 
> > that they have no variables, so  they need to re-iterate over the tree 
> > with 'count()'  function instead of just incrementing the counter.
> 
> Perhaps it's the way you describe it:-) If you don't like the language
> it's likely that you put a `spin' on it that makes students suspicious.

I think this has nothing to do with me. My point is that 
for a *very* long time people *are* happy using variables.
I don't understand why people should *now* fall in love with 
functional programming when it has been constantly  rejected 
by 'most of developers'  for very long time.

Also, I'm not saying I don't like XSLT. I already said that I like it.
It is a good thing and tricks with result tree fragments are 
obviosly interesting. 

But I think somebody should be a mazoshist to be happy 
with writing 10 lines of <xsl:call-template instead of 2 lines, place 
the variable outside the stylesheet to use document() hack and 
do things like that.
 
> > Are you saying 'ordinary persons are not happy with variables',
> I consider myself ordinary, and I'm quite happy without them.
> I can't speak for other people.

I also can not. I just had a chance to make 'clear' experiement 
some time ago. In the school. One class got MIT-Logo as 
their first programming language. 'Parallel' class got Pascal 
as their first programming language. That had absolutely 
no impact on the perecent of kids in both classes who then 
decided to use LISP in their life. 

The other thing is that masses are not bying not-obvious 
concepts. I think that very limited number of people will use the 
document() - with - 2 - parameters hack.  If it takes 
a long time for *superb* XSL developer to *understand* 
what is the semantics of some construction ( that has 
been illustrated by this list ) - that simply means that 
'ordinary people' will never use such a ( crazy ) construct.

> > That means people *will* use extension functions and 
> > extensions functions *will* have 'side-effects'.
> 
> This is unfortunately probably true. 

It already happens. I would say 'fortunately',  because 
it gives some solutions to some real problems.

> I think XSL is an experiment in
> designing a declarative side effect free language for document
> translation. You may be right that current machines or current people
> are not ready for that and want or need a more procedural language to do
> these translations. 

Great. I'm glad we got here, because it was exactly my  point.

> That is not an unreasonable point of view, but I
> would say that it is unreasonable to produce such a language by taking
> the current XSL design and bolting on constructs from a different
> paradigm. If a procedural language had been the aim the whole language
> would have looked different. 

Sure. I'm just trying to clean some space for perl or maybe future 
version of XSLT ( which may  have a different name). Current XSLT  
is perfectly well-balanced for  HTML-templatish  form and of course 
I'l be glad if many people in the world implement this beast 
( I mean XSLT ).

> Of course you may also be right that political
> pressure to call the transformation language `XSL' will mean that
> designing a different language is not an option and so the pressure to
> pollute XSL will not go away. I'm just glad I'm not a politician.

The wise descision could be to understand that XSL 
is *not*  doing well with some problem domains and 
then try to do something about it. If we'l keep silence not 
touching holy cows, I think the chances are small 
that something positive will happen. 

> As for current unextended XSL only being suitable for small documents
> I don't know what you mean by small (or by a document). The MathML spec
> runs to about 400 pages printed and is produced in a single run with xt.
> (one for the html version and one for tex) This is reasonably large as a
> traditional document goes. 

By the way - how much RAM  do you have and what  time 
it took to render 400 pages printed ? 

> If you mean sucking gigabytes of database
> into a single XML tree to be held in memory by the JVM then true
> the current `all in memory' approach of xsl implementations breaks down
> rather fast. 

Not realy. As I said before, if you think about rendering financial 
report into plain text, you may find that there are documents and 
documents. The number of pages in a document is not the only 
problem.

Please don't get me wrong. 

I think XSLT is more or less fine, but it should not pretend to be 
the end of the story. 

It is LISP of XML processing, but  XML processing still needs it's 
Visual Basic.

Not that XSLT should change the syntax / some concepts. 
It is simply too late to change the syntax of XSLT is it bad 
or not.

Rgds.Paul.

PS. Disclaimer.

I dont like Visual Basic. I don't like Windows ( but of course 
I use it at my home comp. It is written in C++, has a good UI  
and don't asks me to dig into documentation to understand 
how to do simple things, because simple things *are* simple 
in Windows ).  On another hand uptime of my Linux box is 
80 days. 

PPS. Language design.
 
If after 6 months of using some relatively small language
the developer still has to learn some  'hidden'  *core* 
concepts of the language - the language is just ...
not ideal ... language... I think.

Any exceptions ?



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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]