XP with rebol?

Thanks!

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...

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.

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

Useful indeed and informative. It is always a pleasure to read you. Patrick

Useful indeed and informative. It is always a pleasure to read you. Patrick

My comments weren't intended to be negative about REBOL, just my impression that while it is a good notation for trying out and expressing some interesting programming ideas, the present state of the language/implementation doesn't inherently do anything special to solve the kinds of issues that arise during multiple-programmers-over-long-time-frames projects. I'm certainly not suggesting that REBOL renders such projects infeasible (nor, for that matter, does assembler ;-) It's just that success at such projects may tell more about the skills, coordination, and dedication of the team members than about the language(s) they used. Given the high regard that this community (including myself) has for Maarten and the portions of his work that we've seen, it's not terribly surprising that he and his collegues could do some impressive work! -jn-

Yeah. It seems easy to scale up a problem, and hard to scale up a solution ;-) People and discipline are the only saviours.

I agree. In a way REBOL makes it sometimes worse, because ultimate power in the wrong hands.... In the right hands it is a tool to be taken seriously though.

Thanks. But it is always easier than it looks. It has to do with banging your head against that wall, again, and again, and.... --Maarten