[REBOL] Re: Style R flavour checker ;-)
From: joel:neely:fedex at: 9-Jan-2002 16:09
Hi, Pat, and all,
> Hi, all
> I'am afraid that this is becoming a sensitive matter. I would
> not like to see a war starting between the rebol-listers.
I agree (with both statements).
> I cannot recall who started this...
Blame me, but first reread my original post:
This is a controversial and sensitive subject with some
folks. I'm not trying to start a flame war, and I have
no interest in debating aesthetic opinions. I *am* very
interested in objective criteria which identify strengths
and weaknesses of the alternatives.
I was planning on waiting a while before trying to summarize my
observations of the discussion, but I agree with Pat's perception
that the temperature is rising a bit fast.
Dijkstra has often used the phrase "separation of concerns" in
discussions on software development. He distinguishes what he
calls the "mathematical" concerns -- whether a program behaves
correctly/accurately -- from "engineering" concerns -- whether
the program exhibits appropriate economies in its behavior.
While a good programmer is concerned with both, it is appropriate
to know at any moment *which* of these issues one may be most
directly engaging, and to be able to discuss them separately.
(I believe it was Don Knuth who observed that, in programming,
premature optimization is the root of all evil
Since programming languages induce subcultures, it seems to me
that any discussion of stylistic issues involving a specific
language engages three separate areas of concern:
1) Objective -- things that can be measured (even if statistically,
in a human factors sense) in a non-ambiguous manner; e.g.
how many lines are required for a given piece of source code,
depending on formatting style.
2) Personal -- things that are a matter of individual preference,
aesthetics, taste, etc.; e.g. my previously-mentioned personal
dislike for all-upper-case text.
3) Cultural -- things that are a matter of tradition, convention,
custom, etc., within a specific society; e.g. the practice
within the REBOL community of indenting by 4 spaces per level
I began experimenting with layout to see whether there was a way
to increase the amount of content within a given area of real
estate, whether editor screen, browser window, or printed page.
I was focused on #1 above.
I'm very aware that factors #2 and #3 are entangled in anything
with as much personal choice and feeling as how one writes code,
but I see some value in applying separation of concerns to the
discussion of this issue (as well as many other programming
I'll leave it to each individual to read this thread and think
about how much of #1, #2, and #3 are present in the various parts
of the discussion.
I think it is ironic that the "layout style" thread occurred
concurrently with another instance of a topic that re-appears
every few months on this mailing list: the issue of promoting
REBOL in our various environments. I suggest that there are
some instructive parallels.
A suggestion that we look at an alternative layout style was met
with a variety of reactions:
- "I like it!"
- "I don't like it!"
- "I don't see the point."
- "What we've always done is good enough."
- "Here's an apparent limitation.", followed by
"Here's a way to deal with that."
- "Why are you rocking the boat?"
A suggestion that a development team already using Java, Python,
Perl, c++, (or whatever...) consider another programming language
(REBOL) is often met with responses that boil down to the same
reactions as those above.
Perhaps a look within ourselves, and at our reactions to the idea
of change will give us some insight into how others respond when
ask them to take a look at REBOL (another kind of change).
My thanks to everyone who has contributed to the discussion. Again,
let me say that my motivation wasn't to "own" a new style, nor to
rock the boat unnecessarily, but to discuss whether a style that
evolved within the Algol heritage was the best approach for a very
P.S.: I'll gladly comply with the judgement of the editor-in-chief
as to whether the refactoring article should be resubmitted with the
examples in a more conventional style.