RE: indentation (was Re: About the article)

[MARK.WROTH@xxxxxxxxxxx (Wroth, Mark)]

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