Scott Rosenberg

I think a reference to Guy Steele's essay 'Building a Language' is appropriate here: http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf In a commentary on the essay, Scott Rosenberg says: Plainly, Steele started out intending to show just how painful the words-of-one-syllable limit is — and, by extension, how desperately programmers need the ability to expand the vocabularies of languages that feel impoverished (“a thought that seems like a primitive in our minds turns out not to be a primitive in a programming language, and in each new program we must define it once more”). Yet what’s fascinating about “Growing a Language” is that the limits Steele imposed on his expression make the paper far more accessible, precise and clear than most computer-science writing. http://www.wordyard.com/2007/06/12/steele-growing/

Marc Canter [1] [2] once pointed out to me in an accidental moment of candor that a Director timeline was just a BASIC program turned 90 degrees counter clockwise, so the line numbers increase from left to right. [1] http://www.wordyard.com/dmz/canter.html [2] https://en.wikipedia.org/wiki/Marc_Canter

Long live Hypercard. My first exposure (Macintosh SE) Check out this unique yet subversive 1994 press release from Rand and Robyn Miller: http://www.wordyard.com/dmz/mail.html

This is a good, readable paper, with clever pictures to illustrate the points. Many of the ideas in it are well known (especially if you are already familiar with XP). I like the fact that the authors recognize that the BIG BALL OF MUD architecture is successful (in the sense that many working systems have this architecture – or rather lack of architecture). In the paper, they describe the BIG BALL OF MUD architecture, and several related patterns on how you end up there, but also ways to deal with it and how to work towards a better architecture. Some of the main reasons for ending up with a BIG BALL OF MUD are simply time and money constraints. But the authors also do a good job of discussing other reasons, for example that in the beginning you simply don’t know enough about the problem domain to be able to come up with a good architecture. This ties in with the notion of programming as learning and discovering, more than simply constructing. Of the seven patterns discussed in the paper, the only one I hadn’t heard about before was the SHEARING LAYERS (I also had not seen the term BIG BALL OF MUD before, but the concept of “lack of architecture” is of course familiar to everybody). I think it’s a good concept, and something I’ll look more consciously for in the future. It is also interesting to note that PIECEMEAL GROWTH can be both a cause of a BIG BALL OF MUD and a solution to it (when coupled with refactoring). KEEP IT WORKING also an important strategy, in my…