A design pattern is an artifact of a missing feature in your chosen language

http://www.snell-pym.org.uk/archives/2008/12/29/design-patterns/

by bensummers • 17 years ago

85 55 17 years ago

snell-pym.org.uk

really only skims the surface of the idea which is too bad. there are a number of similar pieces out there that tackle the subject in depth. i'd link to them, but i'm feeling lazy and don't want to go tracking them down.

alaricsp2• 17 years ago

Nowt wrong with skimming a surface, sometimes you can get more impact with a one-page summary than a long essay :-)

arakyd• 17 years ago

In this case your better off just reading Norvig's original presentation.

dnaquin2• 17 years ago

One of the things I'm really liking about ruby during my python to ruby conversion is that it handles the visitor pattern for me.

Half the Java code I ever wrote was probably visitor pattern cruft. Ruby largely just handles it all for me.

blasdel• 17 years ago

What are you doing in ruby that you weren't in python?

dnaquin2• 17 years ago

I can write methods that take blocks.

Sure I can do the same thing in python, but I either have to write a lambda that limits me to a single line or write a one-off named method. The latter being much less clear than do ... end.

gruseom6• 17 years ago

One of the things that originally caught my attention in a PG essay is a point he made about design patterns: if you're writing the same code over and over again, you're being a human compiler. I remember the shock of reading that: like someone poured a bucket of ice water over my head. It wasn't just that I recognized it as true; it indicated the existence of an alternate programming universe that I knew nothing about.

alex_stoddard• 17 years ago

It's the concluding paragraph of "Revenge of the Nerds" http://www.paulgraham.com/icad.html

I completely failed to recognize its significance when I first read that essay. Thanks for bring it to my attention.

"This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble."

wglb2• 17 years ago

This is one of his that I often reread, as there is a lot in it. Thus, easy to miss that particular aspect of the last paragraph.

wwalker33• 17 years ago

The "human compiler" bit never made sense to me. When I start to write something for the second time, I stop and make it a function (or a class, interface, library, or whatever's appropriate). "Don't repeat yourself" is good advice in any programming universe.

gruseom6• 17 years ago

Yes, but if your language doesn't provide a way to abstract over the repeated code, you have no choice but to write it over and over again. (Not all repetitions can be eliminated by defining a function or a class.) This is the problem that design patterns "solve".

randomwalker• 17 years ago

That was the point of the article. A design pattern is a sign that your programming language lacks an abstraction that makes it impossible not to repeat yourself.

masklinn• 17 years ago

Yes, but in most languages there's a point at which you cannot "make it a function". So you have to write it again and again and again.

Take for instance context management (Common Lisp's `unwind-protect`/python's `with`/C#'s `using`, it's also possible to express it using first-class functions which is the approach used by Smalltalk or Scheme or using your objects's lifecycles which is what C++'s RAII does). It's essential to ensure that resources you're using for a limited time (a lock, a file, a transaction, …) is cleanly released when you don't need it anymore, even if an error occurs during usage.

In java, most of the time this is done with stacks of try/except/finally blocks which you're going to write again and again and again.

How do you abstract it? You can't. Well you could use anonymous classes to emulate first-class functions in theory, but it has limitations of its own and it's not really supported by the wider Java community. And note that before Python introduced `with` or C# introduced `using`, they were pretty much in the same situation (theoretically, C# 3.0 could deprecate `using` since it has anonymous functions, Python on the other hand can't given its still crippled lambdas)

joe_the_user• 17 years ago

Using a pattern is writing more or less the same thing over-and-over, with variations. That isn't necessarily bad or good in and of itself.

Code that has repetition will not be as compact as code in which every symbol is new, original. The later will require much more thought to both write and understand and so is not necessarily desirable.

If we use the term pattern loosely, any programming involves a series of nested patterns with variations. That is how it should be. That is essentially how good writing works as well.

So, actually, patterns and repetition are good if they make the original parts clear. So, as far as language goes, it seems like a language which allows you to include what you need to include and exclude what is irrelevant would be desirable.

Any program that expresses your ideas in the most compact fashion possible will incomprehensible to anyone else and incomprehensible to you next week.

gruseom6• 17 years ago

I never thought I'd see someone argue that writing the same thing over and over "isn't necessarily bad". Of course you did hedge by saying "with variations". But that's the whole point about design patterns vs. higher-level languages. If a language allows you to factor out the sameness and deal only with the variations, it's a bit perverse to want to keep doing it the lower-level way.

The problem with your argument about clarity is that clarity is in the eye of the beholder. To someone who doesn't know about first-class functions, code that defines a class to hold a function and passes instances of a "strategy pattern" object around is going to be clearer. To someone who does know about first-class functions, such code isn't "clear", it's silly, and the "strategy pattern" is ridiculous.

10ren4• 17 years ago

Just a counter-point: in human communication, redundancy is good. There's the saying "Tell 'em what you're gonna tell 'em; tell 'em; tell 'em what you told 'em" and the concepts of "topic sentences" and "signposting" in essays (such as pg's).

For write-only code, communication to humans doesn't matter. But if someone else is going to read it; or if you are going to read it (for example, debug it), then it matters.

Boilerplate - repeated pattern - helps orient a reader. The more familiar it is, the easier it is to understand. Every layer of abstraction increases the difficulty in understanding. The writing becomes like a dense mathematical article, instead of a newspaper article.

I believe without proof that this attitude is one of the reasons that fp has not become popular, despite being older than Java, older than C and older than COBOL: it encourages a programming style that is hard to read, because it strives to eliminate redundancy.

That said, my comp sci masters was about non-redundancy. Absolute non-redundancy is beautiful; beautiful in the sense that it is truth. That's all you need to know.

gruseom6• 17 years ago

I think you make a good psychological point. Many people prefer to read and write redundant code. This may well explain why FP is not more popular. But this attitude to writing complex systems leads to disaster, which is why most complex systems are so bad.

At the snippet level, 40 lines of redundant code may be easier to read than 2 lines of, say, function composition. And 100 lines of familiar redundancy will feel easier to work with than a small amount of strange-looking compactness. But anyone who believes that a million lines of redundant code are easier to work with than, say, ten thousand lines of compact code (I'm making these numbers up) is deluded. This is how software projects end up with hundreds of programmers frozen in concrete. (People think of code as a commodity, as if it comes in sheet rolls that you cut enough of until your project is complete. This is a mistake.)

The root issue is that the number of programmers content to crank out redunant code is at least an order of magnitude (maybe two) greater than the number who are capable of working effectively with abstraction.

If that's correct, then there's a market opportunity. A small startup with programmers who do know how to program in more powerful languages (FP or otherwise) ought to be able to achieve ambitious things compared to large teams working with weaker tools. At some point, the quantitative advantage becomes a qualitative one. Small teams are able to do things that large teams can't, and small codebases can be worked with in ways that large codebases can't.

kscaldef• 17 years ago

> Boilerplate - repeated pattern - helps orient a reader. The more familiar it is, the easier it is to understand. Every layer of abstraction increases the difficulty in understanding.

I really, really think that there's something about learning imperative languages that breaks our brains in some way. Because, I've heard people argue that

    theSum = 0
    theArray.each do |n|
      theSum += n
    end

is easier to read than

    theSum = theArray.sum

which seems utterly crazy.

Even worse, I've had people take correct functional-style code and make it "more readable" by expanding it out into a bunch of boilerplate, and fail to notice the typos and logic errors they introduced in the process. People don't actually read boilerplate code; they do a visual pattern match on it. If the pattern is close enough, they accept the code as correct even if there's a small error that they didn't notice.

mikeryan• 17 years ago

Where did this title come from? I read that and got all up in arms but then read the article and that wasn't really what it was saying.

mbenjaminsmith• 17 years ago

Exactly, I was recently considering writing a @tryandfailsilent. Would save a bit of time and space.

wglb2• 17 years ago

So I am wondering how we got to the opinion of "because one of their fundamental tenets is that patterns cannot be represented in code". Seems quite odd.

iron_ball• 17 years ago

I despise the constant knee-jerk reaction to "design patterns" as "scripture." There is a sizeable contingent who cannot accept design patterns at all, in the belief that design patterns are used only by -- in some nearly literal sense of the term -- religious zealots.

These people will eventually code an Adapter, but presumably they will not call it that.

alaricsp2• 17 years ago

I think it's a knee-jerk reaction to how the more zealotous members of the design patterns community have had knee-jerk reactions to people questioning the scripture status of the Design Patterns book.

Once a bunch of people get religious, another bunch of people will crop up to get religious against them in turn.

I think design patterns are useful and valid; but I think they should be evaluated individually within the context of a given programming language, not necessarily considered global.

lsd5you• 17 years ago

He could make a stronger case, by posting an example. Even then he would be trying to prove a negative - i.e. that there is no design pattern that isn't overcoming a language flaw.

What about the much maligned factory pattern. It boils down to a method that provides an implementation, and can be considered (when not misused) a single point of configuration in an application. (e.g. switch the factory to use html instead of pdf).

My view was always that people could learn patterns much the same way that they can learn a 2nd language. That is end up with a high level of knowledge about the grammar/patterns but not be able to use them fluently.

andreyf2• 17 years ago

What about the much maligned factory pattern

If classes are first-class variables (as in Python, and now even Java (I think)), this is replaced with a constructor which takes a class as an argument.

mhansen• 17 years ago

Then you aren't gaining anything over simply calling 'new' on that class, negating the point of the factory pattern, right?

lucifer2• 17 years ago

Java has always had the ability to reference Class types, and, to instantiate instances of that type using a standard method:

Object makeOne (Class fooClass) { return fooClass.newInstance(); }

You are missing the point of a factory pattern, which is informed by the non-accidental pattern name: 'Factory'.

[edit: using generics it is even type safe]: <T> T makeOne (Class<T> clazz) { return clazz.newInstance(); }

10ren4• 17 years ago

He makes a thought-provoking point about a GOSUB or CALL being a design pattern, that explicitly saves the calling location somewhere and then jumps, and a RETURN, but I disagree with this specific example.

In Z-80 assembly, the return address is implicitly saved on the stack. Sure, it's not structured, meaning that you can call into code at any point (not just at the start of a procedure). One big difference is that the language construct doesn't pass arguments (and I don't think it saves save registers on the stack either - but my memory is fuzzy on this point).

spc476• 17 years ago

In assembly, a design code would be (and here I'm using the Intel 8086 as an example) pass pointers to structures in BX, pointers to strings (or arrays) in SI, CX will contain sizes or limits, DI will point to destinations (say, copying something, or accepting input) with AX and DX used for anything else. Returning data---carry flag clear means success, if set, AX will contain an error code. Other registers may be updated depending upon the function.

That's a design code in Assembly. Move to a Motorola 68000, and well, it changes somewhat---pointers are passed in A0-A5, other data in D0-D7. You can still use the carry flag and say, D0 for error codes.

Move up to C, and the details about passing parameters to a function go away (unless you are mixing Assembly with C, and even then it can be isolated). I just give the parameters to the function and it's up to the compiler to stuff them into proper registers or on the stack or how ever it's done on a particular architecture.

Now, object oriented programming in C---another design pattern. Declare a structure with pointers to functions, and always pass the pointer to the structure to functions called via the function pointers. Again, the programmer is aware of the details. IN C++, the compiler handles those details.

andreyf2• 17 years ago

because one of their fundamental tenets is that patterns cannot be represented in [the] code [of a particular language]

There. Fixes everything. Patterns are great, because they tell a language which way to evolve. They're even better, because they give those stuck in the "programmers program"/"language designers design languages" state of mind a chance to jump into the "I make computers do things" state.

lucifer2• 17 years ago

My take on this:

1 - Patterns address (and are formulated using) the semantics of intent. They can not address domain semantics; that is addressed in the specific realization of a given pattern (which some would consider "redundant code" but that is not strictly speaking, correct).

2 - In a meta-reflective language (type i) (such as LISP) patterns are expressed as (reusable) macros. In languages that lack the ability to extend the compiler (type ii), patterns are expressed as specifications. So regardless of the expressive power of a type-ii language, there will always remain the possibility that a pattern can be identified that would require an extension to that language's expressive power.

reeses• 17 years ago

In re (2), not always. For example, the Visitor pattern is one that is specifically eliminated by basic functionality in languages that support multiple-dispatch. No developer extension of compiler or language needed.

tnovelli• 17 years ago

I tend to agree with Alaric here, but reading this inspired me to take a look at design patterns, ironically.

I've never studied design patterns per se in my two decades of programming (mostly lone hacking) and I think it's about time I took a brief tour of 25+ patterns I'm likely to stumble upon or reinvent anyway, and learn names for them. Then I'll question everything and use my own judgement, as usual. (Is there a good non-dogmatic book on the subject, or does http://en.wikipedia.org/wiki/Design_pattern_(computer_scienc... do it justice?)

A design pattern is an artifact of a missing feature in your chosen language

Related Stories