Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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" ;