Subject: RE: indentation (was Re: About the article) From: "Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx> Date: Fri, 7 May 1999 10:28:19 +0900 |
Gawd, I should have known better than to open my mouth on this subject...! The truth is I am an unconscionable syntax terrorist. :P OK, I swear on my honor this is the last time I will ever make an issue out of syntax/indentation/what-have-you again. Cross my heart and hope to die. [Clarification: In the text below, I arbitrarily wrote "de facto style" where you would write "LISP standard style."] > >1) In making the transition from an imperative, object-oriented, Algol-style > >language like C++ or Java to a declarative, functional, LISP-style language > >like Scheme, syntax is the least important issue. In fact, it is practically > >a truism that if the word "syntax" appears in any list ranked by importance, > >it always appears at the bottom. > > Possibly true. But what's the point? Indentation/formatting of the source > is not relevant to the syntax (at least in languages which don't rely on > BOL/EOL as syntactic markers). First, let me say that it's true that I unconsciously blurred the distinction between syntax and presentation. But presenting Scheme syntax as if it were C syntax is, IMO, counterproductive, and more likely to mislead people than anything else. In every introductory Scheme class you have to say something to the effect of, "Syntax: This is prefix notation. This is an s-expression. This is how an s-expression differs from a block." If you then turn around and start formatting the Scheme code as if it were C, you are going to confuse people who start drawing false analogies between the two based on your presentation. Let me be more explicit. In C, the order of statement execution is the direction of the data flow. C programmers associate the statement order in a block with the "direction of data flow". In DSSSL, the order of subexpressions in an expression is also the order of execution (or rather, evaluation), but it is largely irrelevant to the direction of the data flow. (The direction of data flow is "perpendicular" to this; it follows the nesting.) Encouraging the similarities between the two will lead C programmers to rely on the evaluation order rather than the data flow, which would simply be bad style in Scheme, but is just plain unworkable in DSSSL (in the absence of recursion, at least). Is the extra sense of security really worth the very minor additional cognitive load that a new indentation style places on them? > Now if you're trying to argue that the > formatting of the source is at the bottom of the list in importance (a > strawman, I think), then I would disagree -- take a look at some of the > Pascal output by the original WEB processor if you want an easy example Well, formatting is an issue closely related to concrete syntax, which puts it near the bottom of the list (although I admit syntax is more important in LISP/Scheme than, say, C, because of the code-is-data concept). The importance of source formatting is inversely proportional to the expressiveness of the source language. Scheme is fairly expressive, as programming languages go. I have used CWEB and other literate programming systems, and such things are certainly nice to have around; I like my code to look fancy, and there are advantages to having it and the relevant documentation side by side, but on the other hand I've found that literate systems and formatters and such are not that significant an aid in high-level languages. On the other hand, Pascal and C are not very high-level or expressive, and being able to use additional tools in conjunction with them is almost a necessity. ...Then again, have you every taken a look at the TeX source? It's beautifully formatted, and very well-documented, but it's still hard to (correctly) modify and maintain the program itself (uh, I guess---at least, I sure have trouble following the code, even with those cool mini-cross references on every other page, etc.). > >2) I feel that when learning a new language it's best to adopt the stylistic > >conventions of its most experienced practitioners. (I believe that this > >applies to natural languages as well.) It's pretty safe to assume that they > >have good reasons for preferring that style, and obviously it has stood them > >in good stead, or otherwise they would not be using that language and/or > >style. Observe that people who have been writing LISP or Scheme for a long > >time all use the abbreviated blocking style (the one not used in C). > > If one were writing a textbook on the subject, I'd be inclined to > agree. If one is writing an introductory article, it's less clear to me. I > would, in general, prefer to introduce one new idea at a time ... and since the > indentation is syntactically meaningless, to choose an indentation style > best suited to communicating with the reader. > > This may not be the style > best suited for production programming (although I would argue that code > readability is equally or more important in production programming, the > target audience is different). Better to encourage good habits early, since they tend to stick. BTW, here are four concrete reasons why I prefer the de facto style. (Yes, my true colors are showing!) 1) Using whitespace to emphasize the tree structure makes the closing parentheses mostly redundant for a human reader anyway. 2) Putting closing parentheses on separate lines uses up too many lines in a language which uses so many parentheses in the first place. It's more worthwhile to be able to see more of your program at once than it is to have the added hints regarding the expression nesting. 3) Emacs does it in the de facto way. (Hm, is this a tautology? :) 4) Since everybody else does it that way, conforming means that I have one less arbitrary decision to contend with in my life. > >3) Anyone who dismisses a programming language purely because its syntax is > >"weird" is probably incapable of making significant contributions to its > >code base anyway. > > Maybe. But what does this have to do with the discussion? Nevermind; I thought you were trying to present the Algolization of DSSSL syntax as a selling point (like the authors of a certain widely used C++ knockoff did for their language, much to its everlasting detriment). > >4) Marketing a programming language on the merits of its syntax is a weak > >and transparent ploy, likely to incur suspicion and distrust among > >knowledgeable programmers, the people you want to attract the most. > >Convincing expositions are based on factual evidence and, in their absence, > >clear-cut, representative motivating examples, not presentation style. > > Then I have failed to communicate the main point I intended. I'm > not (and I > don't think Didier was) arguing that shifting the style of indentation in > general use would make any particular difference to the advancement or > decline of DSSSL. I think the basic thesis was that more general > publication of "convincing expositions ... based on factual > evidence and, in their absence, clear-cut, representative motivating examples" > would advance the language. Fair enough. > Secondarily (and the only point I was addressing) in > presenting such examples, a more familiar coding style assists the reader > in understanding the exposition. I already addressed this at length, but I also want to point out that differences in formatting style (as opposed to "coding style", which is a different issue, and probably not what you meant to write) are only really significant aids to understanding when the reader is looking at a large quantity of code. In a teaching environment, one typically uses small examples and students have ample time and energy to study it. And if you are presenting a large body of code in such an environment, it should probably be presented in the de facto style for that language anyway. > 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. Certainly. I'm saying that your presentation of DSSSL is bad because it reinforces the wrong ideas (and suppresses the right ones). > A more subtle point is that what indentation (or, if you prefer, > presentation) style would best aid the target audience to understand the > discussion. Implicit in my argument is that the target audience consists of > people already accustomed to the "block indent" style of program formatting. > Depending on the actual target audience for a particular article, this may > not be appropriate. For example, if one were writing an introduction to > DSSSL for a LISP programming journal, I'd argue just as strongly for > adopting the "LISP standard" form of blocking and indentation. > > Perhaps the bottom line is that the style of formatting of the > source code should be chosen to suit the purpose of the exposition (and I > include production code in this, since it will be, in general, read many > more times than written). If your students (audience, whatever) are C programmers, they will be misled by the formatting. If they are experienced programmers in _any_ language, they are certainly capable of grasping a new syntax without hand-holding or presentational tricks. If your students _aren't_ experienced programmers, they will have the same hurdles to cross, whichever way you present the language, and if that's the case it's evidently better to present the de facto style from the start. --FC DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: indentation (was Re: About the , Wroth, Mark | Thread | Re: indentation (was Re: About the , Brandon Ibach |
Re: Announce: Modular DocBook Style, David C. Mason | Date | Re: About the source library, Ron Ross |
Month |