Work With Stone

Some artists choose to WorkWithClay, some choose to WorkWithStone. When you choose to work in stone, you have to work differently than when you work in clay. You have to plan better, you have to be more careful as you go, you can't afford to keep changing your mind.

--AlistairCockburn

(And in the context of "AllPanaceasBecomePoison" discussion, "clay" is the SmalltalkLanguage and "stone" is CeePlusPlus.)

I freely admit that I would rather code in Smalltalk than C++. But this metaphor feels a bit language-bash-y to me. It's a rather extreme exaggeration. While undoing a decision you've made in stone is virtually impossible, undoing a decision you've made in C++ is merely annoying.

The metaphor also conveniently blends extrinsic factors with intrinsic ones. As with Smalltalk, a very great deal depends on the platform + environment + brand-name. How many of the features of my Smalltalk environment are in no way specified as part of the language definition? Arguably, it's "legal" to blend in these extrinsics, but once we do that for Smalltalk we have to do it for C++, too. To wit: 'No one will pay me to do my sculptures in clay.'

This is the least language bashy form I have seen. Some artists like working in stone, some in clay. That is up to them. The only thing to be aware of is, you can't do things in one that you can do in the other.

If you listen to people talk about the way they work, you hear things like, "Oh, well you can get away with that in Smalltalk" (XP for example, look at the refactoring discussions in general. What they are saying is that Smalltalk supports radical amounts of rework, and they simply can't do that sort of thing in C++ or JavaLanguage.

I once saw a video of Giacometti working his clay to make his sculptures, and refactoring with wild abandon would be one way of describing it. Now, Michelangelo didn't seem to mind working in marble, but I can guarantee he didn't refactor with wild abandon.

In the same way, C++ designers have to work in a way so they don't have to refactor wildly. Smalltalk designers can and do refactor with wild abandon. That is the message of this page. I am being careful to avoid doing any good/bad distinction here, and to point to a difference in working style that comes with the territory. Hope this helps, Alistair

Giacometti frequently sculpted rapidly in clay, then cast the resulting sculpture in bronze. This allowed him to reap many of the benefits of refactoring, followed by production of an artifact with many of the benefits of stone. What does this suggest about software in terms of this metaphor?

Presumably, what Michaelangelo did was somehow "harder" than what Giacometti did, and thus somehow more admirable. What does this suggest about software in terms of this metaphor? --RonJeffries

I was talking to a C++ developer once who was trying to convince me that after he annotated all his classes in a CaseTool and made exacting sequence diagrams and thought everything through, coding was a trivial exercise and his code never had errors. I told him he that he was a stud, but I doubted that any customers would care.

Refactoring in C++ can be easy enough if you've got a utility to add include file dependencies to your makefiles (i.e. makedepend from the X11 distribution). Sure, it takes discipline to make C++ flow like object-oriented Lisp or Smalltalk, discipline that is hard to spread beyond a few programmers (much like XP?). But after acquiring (or borrowing) such discipline I started to prefer C++ for its lack of run-time errors a compiler could've warned about. For example, you never find out a method is missing at run-time. I like the C++ is stone analogy, but its more like a wonderfully bendable and easy enough to sculpt foam that can be fixed to stone again and again. --ScottJohnston

Have you worked sufficiently in Smalltalk to compare the ease of refactoring done your way? If so, and they're comparable, you should teach a course! --RonJeffries

Hmmn - when I use PerlLanguage I very much enjoy the runtime dynamicity that C++ and other static/strongly typed languages squelch. OTOH Perl does allow me to add it when and where I want with a pragma ("use strict") and a compile-option ("perl -c" or "perl -wc") to catch static stuff when it can. I tend to do this whenever I finish a block of code (about every method or dozen lines) and I've even hard-wired it into my editing environment to do this for me sometimes. VisualWorks had something similar when I used it. So it's not like Smalltalk or Perl make you choose between all or nothing. I'm just pleased they let me choose at all, unlike some other languages ;-) --BradAppleton

Many who work in stone create a model in clay first, of course. Just as many C++ and Java programmers would, if given the chance, write their prototypes in Smalltalk or some other language suited for ExploratoryProgramming. - JayOsako