(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, December 21, 2007
  Newly Discovered Design Pattern: "Code Well."

When I was in college, one of the jobs I had was a TA for an intro programming class. For one of their projects, I was asked to whip up a kind of web browser “shell” in Java. The basic idea was to make a browser that would be highly extendable by students, while freeing them from worrying about the overall rendering framework.

Now, the first language that I learned was Smalltalk, which has historically been relatively design-pattern-free due to blocks and whatnot, and I had only learned Java as an afterthought while in college, so I coded in a slightly unorthodox way, making use of anonymous inner classes (i.e., shitty lambdas), reflection, and the like. I ended up with an extremely loosely coupled design that was extremely easy to extend; just unorthodox.

When I gave it to the prof, his first reaction, on reading the code, was…utter bafflement. He and another TA actually went over what I wrote in an attempt to find and catalog the GoF patterns that I’d used when coding the application. Their conclusion after a fairly thorough review was that my main pattern was, “Code well.”

That year, the class didn’t actually end up using any of the code I wrote, but a year or two after I quit being a TA for the course, they did. I took a look at what became of what I wrote. Needless to say, it now made extraordinarily heavy use of patterns everywhere—and had a massively larger code footprint as a result—but, after all, it’s important to show the young peons how to use patterns. (Euf…)

So, yes, I have to agree that dogmatic use of design patterns hurts, and that a new language won’t automatically eliminate that.

But I’d like to believe that a language that doesn’t take ten lines of code to invoke a method by reflection, or five lines to write what in any decent language would be a one-line lambda, would at least help.
Gecko on programming.reddit.com

The follow-up: Pouring water back into the flask.

Comments on “Newly Discovered Design Pattern: "Code Well.":
Smalltalk is design patterns free? Isn't this the language where the whole movement originated? What about http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X ?
You've got to wonder whether making liberal use of reflection, anonymous inner classes as poor-man's lambdas and the like is really the most pedagogically sound approach for an introductory programming class. Java is not (yet) a language that easily lends itself to this style of programming. If the initial reaction of the prof was "utter bafflement", what would have been the reaction of the students?
My suspicion is that some of the ideas embodied in various uses of lambdas and reflection could in fact be extracted as "design patterns", just not classic Gang of Four OO patterns.

Really, there isn't much difference between a design pattern and a coding idiom except that design patterns are usually more complicated because they typically involve building several classes.

Perhaps someone will write a book sometime in the next few years extracting idiomatic best practices for object-functional programming from several different languages (Ruby, OCaml, Scala, add your favorites), and identifying common coding problems as well as effective ways to solve them for people trying to learn how to move past classic OO patterns.
@sztywny: Pattern != Design Pattern

The GoF book talks about design patterns in Smalltalk too, but in general dynamic languages lend themselves more to experimenting and designing "on the fly" than static languages
The GOF is full of shit, as has been demonstated recently. Natural selection is what you should be aiming for. Obviously you don't read much.
I don't think I'd go quite that far, Matt. There's at least one universally useful pattern in it.
Almost all 'design patterns' are just instances of yet another pattern: The Human Compiler.

Make your language do something it can't naturally do, by having to transform abstractions into hand crafted code. Especially when using a higher level language would make that 'design pattern' automatic or innecesary.

That said, I'm not against patterns per se, I just don't see them as the 'Holy grail' that fixes all the developer problems if only you used them well, because they are nothing of that sort.

'Design patterns' are simply like an Assembler programmer doing ADTs, just because he knows about OOP, and he is methodic about his work, but it doesn't mean that what he's doing is the only way to use classes when programming.
Of course they aren't the "Holy Grail", I don't believe anyone claims that. They're just methodologies for designing and implementing complex systems. In the real world you usually can't just scrap C++ or Java for Ruby or Smalltalk or Haskel, so it makes sense to use available knowledge to make your code more readable and maintainable. I don't understand why anyone would be against that.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /