[zeeed]

that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists". of course patterns aren't the end-all-be-all of software development. but it's the trait of a good craftsman and engineer to know what patterns exist and how to use them.

Sadly, and in that I agree with the author, people in interviews only ask for knowledge of patterns, not when and when not to use them.

in that sense, the title better were: "I'm sick of people thinking of patterns in an idiotic fashion", avoiding creativity at all cost". But then, that's just complaining about the single-mindedness of less experienced colleagues.

The patterns themselves and knowing how to use them I still consider a valuable asset and in parts, the author says that.

But beyond that, the value of patterns is that you can easily communicate with other developers about architectural decisions. And communication is 80% of software development in a team.

[dragonwriter]

> that's as good as saying "i'm sick of arcs, square windows, rafter roofs and linked lists".

Well, no -- except for the last, which we'll come back to -- because software isn't the same thing as physical architecture. The nature of software is that components can be and should be reusable, so if you have to rebuild the same thing from a complex "pattern" (more than a simple parameterized constructor or the equivalent) each time you use it, it means that the tool (programming language) you are using has a failure of reusability. With physical architecture, you obviously need to build a new copy every time you need one -- windows are fundamentally not reusable.

Now, for linked lists, yeah, it would be silly to be sick of linked lists as a concept when building software.

OTOH, you can legitimately be sick of having to build a struct with a data member and a next pointer and all the associated manipulation functions every time you need a linked list of <new data type> -- that is, sick of linked lists as a GOF-style Design Pattern -- rather than being able to (if you want to be exceptionally explicit about naming a type for the list) doing something like:

  type newDataTypeList = [NewDataType]

The better your language is, the less you have books of "Design Patterns" with implementation recipes, and the more you have code libraries where the documentation of the "pattern" covers effective use, rather than implementation.

[zeeed]

> software isn't the same thing as physical architecture.

and software isn't the same thing as a design pattern (neither are components). The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works.

Reusability isn't a relevant aspect of design patterns - this is a hallmark of implementation. I can implement 200 singletons and have no need to re-use them. Same goes for windows - just because I have built a bathroom window doesn't mean I need (or even want) to reuse it for my living room.

And language 'quality' is not even a metric, I don't see the relevance of your last paragraph.

[dragonwriter]

> and software isn't the same thing as a design pattern

And GOF-style design patterns -- which are heavily implementation-recipe-centered -- aren't the same thing as design patterns more generally.

> The pattern describes the /concept/ and allows the builders to call an arc "an arc" instead of describing the tedious 100 steps required to actually build one and the explanation of why it works.

GOF-style design patterns actually describe the tedious 100 steps required to actually build them, and are in particular selected not by their general applicability but by the fact that they are specifically things that cannot be abstracted in the languages of the time that the book drew from, e.g., they are largely implementation recipes for things for which implementation recipes rather than reusable libraries are required in the common OO languages of the time the book was assembled.

> I can implement 200 singletons and have no need to re-use them.

Yes, but the reusability I'm talking about isn't the individual implementation but the common infrastructure -- with a language that is more flexible than, you can build the infrastructure for a singleton once, and the next time you don't have to build a whole singleton implementation, just the bits that are unique. With physical architecture, you have to build the whole thing each time, so implementation recipes are, to an extent, an unavoidable accompaniment to design patterns, rather than a sign of a problem with the implementation medium (in the case of programming, the particular language.)