Subject: Re: No side effects holy cow. ( Re: process order (still...) ) From: David Tolpin <dvd@xxxxxxxxxxx> Date: Fri, 14 Apr 2000 01:17:27 +0500 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: No side effects holy cow. ( Re:, Paul Tchistopolskii | Thread | RE: Getting all the attribute value, Ben Robb |
RE: That didnt work either! RE: How, Selva, Francis | Date | RE: how to select attribute value b, Selva, Francis |
Month |