[REBOL] Re: REBOL] Re: source code layout question
From: joel:neely:fedex at: 5-Jan-2002 9:23
HI, Carl and Sunanda,
Carl Read wrote:
> On 05-Jan-02, [SunandaDH--aol--com] wrote:
>
> > I also guess a preferred formating style depends largely on
> > what the expected lifecycle of the code is.
> >
I think that's a very important point; the cost of modifying the
code (at least for the most likely modifications) is certainly
a factor in choice of coding style.
> > ... I assume code is
> > a high maintenance item, and leave it spaced out to make
> > modifications (in my option) easier. As an example, I was never
> > convinced by Carl S's "mental reduction" example in Zine/2.
> > He reduces a Style B snippet:
>
> > either (mode) [
> > data: find data "Active"
> > ][
> > data: find data "Passive"
> > ]
>
> > to the one-liner:
>
> > data: find data either mode ["Active"]["Passive"]
>
> > Now that may be absolutely necessary in some circumstances where
> > memory is tight. But my instinctive reaction was: "Arrghh no! What
> > if I then need to perform an additional according to the value of
> > 'mode?" The original is much clearer as to where that additional
> > code should go.
>
> Well, I was convinced, and I now find the one-line version easy and
> natural to read.
>
I think now we're talking about idioms (idiomata? ;-) Every language
(at least the non-trivial ones) in my experience has ways to express
things that are not immediately obvious to the cultural outsider,
and let's be honest about the fact that programming languages induce
cultural groupings just as much as the so-called "natural languages".
There's always a trade-off between expressing something in a manner
that almost anyone from any culture could understand vs. in a manner
that is recognizable to a native. To my view, this is another kind
of optimization -- maximizing the bandwidth (and recognition) between
writer and reader, rather than maximizing speed or memory economy.
And, of course, optimizations often have the effect of making code
more brittle or non-obvious.
> Also, adding any additional code /is/ simple...
>
> data: find data either mode [a: 1 "Active"][b: 2 "Passive"]
>
A nice example of a REBOL-specific use of multiple-expression blocks!
> What that example shows is the added value a functional language gives
> you, another being the ease with which you can capture interim
> results of an evaluation. For instance...
>
> data: find data d: either m: mode ["Active"]["Passive"]
>
...
> which cuts out most of the repetition, but even so, I'd still prefer
> this...
>
> m: mode
> d: either m ["Active"]["Passive"]
> data: find data d
>
But, to be fair, I think that layout can visually chunk the phrases
in the one-liner to make the internal structure more clear:
data: find data
d: either m: mode ["Active"] ["Passive"]
One could also expose the structure (though at a cost!) by using
parens:
data: find data (d: either (m: mode) ["Active"] ["Passive"])
I know I keep coming back to the issue of programming languages as
as media of communication between humans (with the convenient
side-effect that they is executable by a computer ;-), but my
experience in software development includes a huge portion of time
spent reading code that someone else (including an earlier copy of
myself ;-) wrote. When attention is given to making the goals and
meaning of the code self-evident (and I'm *NOT* talking about the
use of comments), the subsequent work is much more efficiently
performed.
Also, I believe it was K.F. Gauss who said,
"The purpose of computation is not numbers, but insight!"
which I thoroughly believe.
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
