[REBOL] Re: XP with rebol?
From: joel:neely:fedex at: 11-Mar-2002 7:33
Hi, Pat,
pat665 wrote:
> I found your new article about iteration very interesting.
>
Thanks!
> I notice the usage of many eXtreme Programming words such as
> metaphor, refactoring, DRY...
>
In brief, I used those terms because they are now common (and
succincnt) enough that I assumed/hoped that they would get the
key ideas across without my having to further expand the text
to discuss them. (The rest of this answer is background for
anybody who is interested in digital archaeology... ;-)
Many of the terms currently en vogue in XP (and even more of
the concepts) have been around long before "XP" became a hot
buzzword (and even longer before uSoft mis-appropriated it ;-)
Although the ideas has been around for a long time (and is
central IMHO to OOP), the first time I recall seeing the term
metaphor
commonly used in the sense of my last article
was about 1984, in the phrase "desktop metaphor" to describe
the GUI use of a computer monitor invented by Xerox, developed
by Apple, and later copied by uSoft. The phrase "desktop
metaphor" was actually consciously in my mind while writing
the article, but I've emphasized in my teaching since the
early 70's that almost everything we talk about in programming
is in metaphorical terms: "file", "integer", "string", "print",
memory
, and so on.
As for "refactoring", Martin Fowler's book:
Refactoring: Improving the Design of Existing Code
Martin Fowler
Addison-Wesley
ISBN 0-201-48567-2
has a very apt subtitle. The notion of taking code and making
improvements by small, systematic changes in structure has also
been around for a long time. We used to call it "incremental
refinement" or "iterative development", but I guess those terms
sounded too academic to catch on with the great masses of COBOL
programmers back in the day...
The FORTH community has been using the term "factoring" since
at least the early 80's to describe the idea of grouping,
organizing, and structuring to find and express the simple
ideas that underly most large, complex blobs of functionality.
As for "DRY", it's a nice, compact buzzphrase for an idea that
has been around since at least FORTRAN days: when you find
yourself writing the same code over and over, it's time to pull
it out into a re-usable routine. I'll have to say that REBOL
(as well as LISP, Scheme, Smalltalk, Prolog, and a few others)
has *way* better means of doing that abstraction than FORTRAN
or COBOL. Even c is an "improvement" over FORTRAN/COBOL in
that sense, but c has its own set of conceptual barriers...
> Are-you an XP programmer?
>
Hmmm... I've read the literature, and was even in a class
taught by Kent Beck (back when "patterns" were his focus
rather than "XP"). I think that there are many good ideas
in the specific set of practices distilled under the XP
banner, but I don't think that they are universally
applicable, nor the only good way to program (and I believe
that the XP literature says as much). Some projects and
organizations simply aren't compatible with that style, and
some situations (such as a solitary REBOL programmer trying
out ideas, trying to come up with the definitive Killer REBOL
Demo, or doing research) just don't have all of the official
ingredients -- such as a team, a user, or a definite schedule.
As with all good methodologies, I highly recommend that
professional programmers read the literature, try the ideas
out, and then use them when appropriate in their own work.
> Do you think Rebol is suited for XP?
>
Probably about as much as many "mainstream" languages.
In the sense of "XP as institutionalized RAD", I think REBOL
has a number of very nice capabilities that allow one to do
spikes
and to construct/iterate/refactor code to let the
user see how things are coming together throughout the project.
As far as REBOL being well-suited for the kinds of large-scale
projects that *need* a whole team of high-skill, high-bandwidth
developers to build...
In one of the "shoebox" papers that Allen has kindly archived on
the REBOLforces site (thanks, Allen!) Carl Sassenrath explicitly
says that REBOL is designed for programming in the small, rather
than programming in the large. I can certainly imagine putting
together a team to develop some large application in REBOL, but
much of the team-coordination effort (source code control, use
of libraries, make/build/test processes, argument typing, etc.)
would have to be based on convention, as REBOL itself offers no
built-in support for those issues.
Remember that XP as a formalized methodology was based on the
practices of high-skill Smalltalk programmers, using many of
the kinds of mechanisms that are built into the Smalltalk
environment.
In addition, REBOL shares with FORTH, Smalltalk, etc. (what we
used to call "extensible languages") an interesting property:
since you can essentially bootstrap up your own language based
on the words you define, it's easy/common for large projects
to end up with the upper layers of code looking nothing like
the underlying notation.
Consider how little of a typical layout spec in REBOL/View
actually resembles typical code in REBOL/Core. Now consider
what would happen if the "model" part (in the MVC sense) were
written in an application-specific dialect based on objects.
It's easy to get three effects in such a situation (extreme
extensibility, that is):
1) The upper levels of the program end up being written in
a language that bears no resemblance to the underlying
base notation. In essence, the programmers are making up a
new application-specific language for each project. This
requires that they stay *very* well coordinated to be able
to make progress during development, and requires *very* good
communication/documentation practices to be able to return to
the code after being off somewhere else doing something else
and perform maintenance or enhancement on the code.
2) Adding a new developer to the project essentially requires
that the newcomer learn a new language. Unless it is *VERY*
well-conceived and implemented, that learning curve may be a
real issue to short-term productivity. (Remember that XP calls
for a minimum of front-end generalized design, on the assumption
that the team can back up and redesign as soon as the need for
generality emerges.)
3) Absent built-in mechanisms to support run-time detection of
errors and their explication, it's easy for a small change
in some definition (way down inside the "stack" of definitions
leading up to the high-level, application-specific parts) to
break code in a way that can be very hard to track down for the
typical programmer.
I'm not criticizing/condemning REBOL here, but trying to be
clear about the practical limits I see in its use in large,
team-oriented projects. I find REBOL a very nice "object to
think with" (to use Mitchel Resnick's wonderful phrase) and a
nice way to communicate what I believe are important ideas to
other programmers who know the notation.
That probably makes 35 kilograms of answer to what was intended
as a 1000 milligram question ;-) but I hope there's something
useful in there!
-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" ;
