Subject: Re: [xsl] logical operators in *test* From: David Tolpin <dvd@xxxxxxxxxxxxxx> Date: Wed, 29 Oct 2003 22:26:24 +0400 (AMT) |
> I would say that in fact most programmers learn new languages in exactly > that way: work from existing samples and guess at the syntax based on > their existing knowledge about other languages. This is especially true > for task-specific languages like editor macro languages and "easy" > languages like Python and XPath. > > The problem with this approach is that it works just well enough to lead > you into deep trouble when you trip over some non-obvious or > counter-intuitive language feature, such as "|" being the union operator > in XPath expressions. > > Of course, when one finds oneself in that situation, one should actually > consult the spec or a good tutorial on the language. RTFM always applies. I would say that in fact this is a sign of a problem with design of the language that makes such errors possible. There is a mainstream tradition; there are three ways to do with this fact. 1) one can design a completely different (by its concepts) language which follows traditions in designation of constructs; authors of Java went this way and it has proved to be successful: everything that resembles a C construct works exactly as in C; 2) one can choose a completely different syntax; a difficult way, but a good is example is Haskell -- which forces the reader think differently about things which are different 3) re-use syntatcic constructs of a well-known meaning for similar but different purposes. This leads to problems. A nice example of making this happen is C++ (which reaches its extreme by allowing (and encouraging) to overload built-in operators. Another example is XPath. I realize that it is not due to lack of thought behind the design; authors of XPath are respectable experts and are familiar with many different programming languages. It helps them to think broadly and not to stay bounds to syntax traditions of any familiar language. But the majority of users is not. Too many XPath constructs are misleading due to their names; of those which are different many are designed with purity of design in thought, not with clarity of expression. Using 'or' where a C programmer expects ||, '|' where a C or pascal programmer would expect 'or', and completely unexpected (for me) use of '*' and '.' (instead of any and self, similar to preceding::, following:: etc) probably because it somehow reminded the way file globs are organized, leads to the need to explain the way .//*[1] is different from a similar but not identical construct. If XPath (as a part of XSLT) is the first language to learn, then it is strange, with <= for less-or-equal (in row with 'and' and 'or', would it be more natural to have lt, le, gt, ge, eq, ne?), but usable, even elegant. If it is not the first language, then it is a trap. It is not because people do not read the spec carefully. It is because a normal brain should not be tried by switching between concepts at the same time when its owner is switching between editor's windows. Another example of uneasy name is generate-id() . What kind of id does that thing generate? What it returns is not 'id', because it is not unique in the document. And it does not return, it names, because each time it is called for the same node, it returns the same value. Why current() returns a node set, while last() returns an integer? David Tolpin http://davidashen.net/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] logical operators in *tes, W. Eliot Kimber | Thread | Re: [xsl] logical operators in *tes, Wendell Piez |
[xsl] Creating then using elements , Kathy Burke | Date | Re: RE: [xsl] logical operators in , Wendell Piez |
Month |