Subject: RE: indentation (was Re: About the article) From: MARK.WROTH@xxxxxxxxxxx (Wroth, Mark) Date: Fri, 7 May 1999 10:56:04 -0700 |
I'm only going to touch on a couple of points in Frank's reply, because I find that I agree with most of what he said. FC>Date: Fri, 7 May 1999 10:28:19 +0900 FC>From: "Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx> FC>Subject: RE: indentation (was Re: About the article) [...] FC>> >1) In making the transition from an imperative, object-oriented, Algol-style FC>> >language like C++ or Java to a declarative, functional, LISP-style language FC>> >like Scheme, syntax is the least important issue. In fact, it is practically FC>> >a truism that if the word "syntax" appears in any list ranked by importance, FC>> >it always appears at the bottom. MW>>possibly true. But what's the point? Indentation/formatting of the source MW>> is not relevant to the syntax (at least in languages which don't rely on MW>> BOL/EOL as syntactic markers). FC>First, let me say that it's true that I unconsciously blurred the FC>distinction between syntax and presentation. But presenting Scheme syntax as FC>if it were C syntax is, IMO, counterproductive, and more likely to mislead FC>people than anything else. In every introductory Scheme class you have to FC>say something to the effect of, "Syntax: This is prefix notation. This is an FC>s-expression. This is how an s-expression differs from a block." If you then FC>turn around and start formatting the Scheme code as if it were C, you are FC>going to confuse people who start drawing false analogies between the two FC>based on your presentation. FC> FC>Let me be more explicit. In C, the order of statement execution is the FC>direction of the data flow. C programmers associate the statement order in a FC>block with the "direction of data flow". In DSSSL, the order of FC>subexpressions in an expression is also the order of execution (or rather, FC>evaluation), but it is largely irrelevant to the direction of the data flow. FC>(The direction of data flow is "perpendicular" to this; it follows the FC>nesting.) Encouraging the similarities between the two will lead C FC>programmers to rely on the evaluation order rather than the data flow, which FC>would simply be bad style in Scheme, but is just plain unworkable in DSSSL FC>(in the absence of recursion, at least). Is the extra sense of security FC>really worth the very minor additional cognitive load that a new indentation FC>style places on them? Hmmm. I'm not sure I understand this, probably because of my limitations as a DSSSL programmer. I will agree that if "block indentation" implies (or encourages) an incorrect view of what the language is doing, that's a powerful argument against it. MW>> Now if you're trying to argue that the MW>> formatting of the source is at the bottom of the list in importance (a MW>> strawman, I think), then I would disagree -- take a look at some of the MW>> Pascal output by the original WEB processor if you want an easy example FC>Well, formatting is an issue closely related to concrete syntax, which puts FC>it near the bottom of the list (although I admit syntax is more important in FC>LISP/Scheme than, say, C, because of the code-is-data concept). The FC>importance of source formatting is inversely proportional to the FC>expressiveness of the source language. Scheme is fairly expressive, as FC>programming languages go. I was making a different point. The original WEB (in which TeX itself was written) wrote its output Pascal file much differently than, say, CWEB does. WEB output Pascal (the source file submitted to the compiler, not the printed documentation version) was (intentionally) made as illegible (to humans) as possible and still have it be compilable. I intended the example to point out that, although we're talking about minor changes around the edge, the formatting of the source code can be a non-trivial factor in reading/maintaining the code. It may also be that I'm unusual in the importance I attach to this. [...] FC>...Then again, have you every taken a look at the TeX source? It's FC>beautifully formatted, and very well-documented, but it's still hard to FC>(correctly) modify and maintain the program itself (uh, I guess---at least, FC>I sure have trouble following the code, even with those cool mini-cross FC>references on every other page, etc.). AS seems to come through in several places in this discussion, formatting (and pretty-print, cross-references, indices, etc.) don't by themselves make the presentation of complex ideas easy. I might argue that Knuth did about as well as is possible in explaining the TeX source -- but it's a complex program, and it's not clear to me that Pascal would be the language of choice if one were to attack the problem today. [...] > Secondarily (and the only point I was addressing) in > presenting such examples, a more familiar coding style assists the reader > in understanding the exposition. FC>I already addressed this at length, but I also want to point out that FC>differences in formatting style (as opposed to "coding style", which is a FC>different issue, and probably not what you meant to write) are only really FC>significant aids to understanding when the reader is looking at a large FC>quantity of code. In a teaching environment, one typically uses small FC>examples and students have ample time and energy to study it. And if you are FC>presenting a large body of code in such an environment, it should probably FC>be presented in the de facto style for that language anyway. A valid argument. > Presentation style (a bigger topic than > indentation) cannot make a discussion which is substantively unclear > suddenly lucid. But it can reinforce and make easier the > exposition of new -- and hence difficult -- ideas. FC>Certainly. I'm saying that your presentation of DSSSL is bad because it FC>reinforces the wrong ideas (and suppresses the right ones). Well, we're in agreement on what "goodness" is, whether we agree on how to compare these two styles or not :-) [...] MW>> Perhaps the bottom line is that the style of formatting of the MW>> source code should be chosen to suit the purpose of the exposition (and I MW>> include production code in this, since it will be, in general, read many MW>> more times than written). FC>If your students (audience, whatever) are C programmers, they will be misled by the formatting. FC>If they are experienced programmers in _any_ language, they are certainly FC>capable of grasping a new syntax without hand-holding or presentational FC>tricks. If your students _aren't_ experienced programmers, they will have FC>the same hurdles to cross, whichever way you present the language, and if FC>that's the case it's evidently better to present the de facto style from the FC>start. A cogent argument. However, I notice the abstract Didier PH Martin noted: DM>From PSL style language U of Wisconsin Style language Track WWW8 DM><Quote> DM>DSSSL is a proposed presentation specification language for SGML that is now DM>a Draft International Standard. While a complete implementation of DSSSL is DM>not yet widely available, DSSSL specifications appear to work well for DM>documents that are primary textual. DSSSL is a complex language based on DM>Scheme that support many data types. While it is very powerful it appears DM>inaccessible to end users. DM></quote> (and this is really the reason I replied to the list, as I think we've about exhausted the value on this topic itself). Now, I'm not a high powered programmer in any language. I came to DSSSL because it appeared to offer a way to make use of SGML, which, while a powerful idea, was pretty much useless to me in the absence of a usable tool to take SGML data and turn it into useful output documents. However, I did not find the basics of the language "inaccessible". In particular, using DSSSL as a simple stylesheet language was about as inaccessible as falling off of a log. I wouldn't claim to be a wizard (as any of the several people on this list who've helped with some of my problems would attest). But I think I may be more representative of one target audience for DSSSL than a wizard would be; while SGML/DSSSL may become or remain a system of choice for "industrial strength" applications, I think XML/XSL is poised to dominate the "low end" (Web and simple applications). I do not think this is a good thing, and so I'd like to encourage efforts to make it "accessible" to the general user. I'm not sure how to categorize the people I mean, although web designers are a part of the target. My impression is that they are not high-powered programmers, and they're not interested in many of the more esoteric possibilities of the language (at first, anyway). They're people who are trying to use simple but powerful tools to manipulate information (mostly text and graphics). DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Win32 Scheme (was: indentation , Didier PH Martin | Thread | RE: indentation (was Re: About the , Didier PH Martin |
Help: Docbook Stylesheet, Guillaume Rouchy | Date | Re: indentation (was Re: About the , Ron Ross |
Month |