13 ms·

Why Patterns Failed and Why You Should Care

166 points by matt_d 8y ago

cheschire 8y ago
I have found it interesting when I learn of a new trend or convention, which I think is a superset of patterns, only to realize part of the way into learning it that I’ve already used it in places before. Intuitively I managed to figure out the patterns, but didn’t realize it at the time I was doing it. Once I found that it was considered a pattern, or a best practice, it became concrete. I think this speaks to patterns as being a mechanism for validating student code, but I don’t think patterns should be the method for conveying problem solving to students. Instead, much of what I learned from coding patterns early on came in the form of intellisense hints from Resharper. I would write nested loops and it would suggest the alternative LINQ query. Then Visual Studio started doing the same thing and automatically refactored my code. This meant I deconstructed the problem first, and understood the problem, and now I could simply figure out the translation. Perhaps a better way to instill patterns for new programmers is to build more robust code convention and anti-pattern recognition into the IDE, with code rewrite capabilities. For example it should be relatively trivial to recognize when local variables are clustered around certain regions of a method. When the IDE intellisense compiler recognizes this, it starts to suggest breaking out a new private method, or at least an internal function. Perhaps include a more robust hint with details about unit testing and why small methods are easier to unit test. Patterns are a broad concept though so I’m not sure how well this idea would scale.
- blt 8y ago
  Wow, I did not know IDEs were making suggestions like this.
pan69 8y ago
Did patterns really fail? Or did we just out grow them? For me personally patterns have always been valuable as a means of communication. Before patterns one team would talk about "device for when at rest" and another team would talk about "timber and fabric object for relax position". Now we just call it "chair" and it's common. Just like, singleton, command, proxy, whatever. Maybe design patterns simply have done their job.
- tonyedgecombe 8y ago
  Yes, several people I have spoken to said the main thing they got from the GoF book was giving a name to things they were already doing.
  - danielbarla 8y ago
    I always felt that this is a larger value than the implementation details. The software industry was / is still in need of more standardization and common vocabulary.
  - gmueckl 8y ago
    The other way to use GoF and related texts is as an inspiration. It's been a while since the last difficult software design problem that I had to solve. But I reread GoF to get a new perspective on what I was trying to solve. Also, I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. But that's how the application of design patterns leads to failure. These are raw building materials for your design. You always have to shape them to fit your exact needs. Extend them, reduce them, cut them in half and glue the halves back together with their backsides - do what you must to get a clever design that leads to simple code.
    - Terr_ 8y ago
      > I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. I think the key aspect which distinguishes "dogmatism" from "reasonable" is whether the choice they're concerned with would cause a communication-error or leaky-abstraction.
- BerislavLopac 8y ago
  Yes, creating common terminology is important, and the fact that we're still doing it for basic things simply shows that this field is still in its infancy. As we all know, naming things is hard, and in many cases it was less than fortunate. E.g. I'm really excited by the concepts of "event sourcing" and "CQRS", but think that those names are quite unfortunate choices. On the other hand we have "singleton", which might not be to everyone's liking as a concept, but I think we can all agree that the name is quite clear and descriptive (that said, I've always been sorry that we didn't go for the alternative choice, "highlander").
ncmncm 8y ago
Patterns failed because they aren't patterns. But if the GoF had published a Glossary of Software Things We Find We Use, few would have bought it. In one sense DP wasn't a failure, because it made its authors boatloads of money. That's usually considered enough, if your expectations are not unreasonable. It didn't revolutionize software development, but software development already was and still is dead in the middle of a continuous revolution, with no end in sight. That revolution is driven by programming languages getting better at enabling programmers to capture ideas in libraries. Progress mostly happens by existing languages adopting good ideas. Sometimes the ideas have been tried out first in a new language, but as often not. If you have a good language idea, you stand an overwhelmingly better chance of people using it if you get it into a widely used language. As a consequence, C++ has, over the past 20 years, turned into a language that is enormously more fun than its first standardized version. C++11 is more fun than C++98, C++14 is more fun than 11, 17 is more fun than 14, and 20 will be more fun than 17. The bleeding edge is discovering how to express good ways to control the non-von Neumann hardware whose computational capacity completely overwhelms the pile of cores we are handed. It's not clear that libraries will be able help very much with that.
- dualogy 8y ago
  > The bleeding edge is discovering how to express good ways to control the non-von Neumann hardware whose computational capacity completely overwhelms the pile of cores we are handed Namely? What non-von-Neumann hardware are you thinking of here? Certainly not the very-much-von-Neumann innards ubiquitous today in consumer or workstation machines, mobiles, embedded/wearable/IoT gadgets, game consoles, I reckon.. so what are you thinking of here, custom-designed ASICs / FPGAs / SoC or ...?
  - tow21 8y ago
    I think ncmncm means “people”. The cutting edge of computational systems organization is finding ways to effectively work with the complex multiagent systems running on wetware.
    - manicdee 8y ago
regularfry 8y ago
The main thing I learned by actually reading the Alexander book is exactly how far GoF missed the mark in translating "patterns" into the software domain. They're hierarchical, and span a vast range of scales. If one end of the scale is "Iterator", to match Alexander the other end of the scale would need to be set at "Ecosystem" or "International Community". Less than a quarter of the book would have anything to do with data structures or bytes in a file. I think there's room for a proper Software Development Pattern Language book, but GoF is definitely not it.
watwut 8y ago
I still find patterns useful, I am glad I learned them and I am super glad that they are now named consistently thanks to those books. They also make it easier to think about structures. When you need undo and redo, knowing about command pattern made it easy. When I see word decorator or iterator in code I know exactly what it is. It was useful and it is still useful if you work in object oriented language and problems that match it.
- Retra 8y ago
  >When you need undo and redo, knowing about command pattern made it easy Undo and redo are easy even if you don't know about "command pattern"s. Every computing problem can be solved using a virtualization layer, and that's all the command pattern is. It's not even a pattern, really... it's just the way computing works.
  - watwut 8y ago
    Of course it is pattern and of course patterns are largely the way computing works. It is even one of original patterns in that book. If it seems so ordinary to you, then it is more of success ot patterns then any kind of failure. Nowdays, you learn these ideas just by reading code here and there, they are so ubiguous and simple and standard. Back then, people complained they are complicated. Everything in computing is just a way computing works. Functional programming is also just the way computing works and it still makes sense to study it's structures. And eventually someone will come up with names eventually everyone will "just know". If everything is vurtualization layer, the I don't find the term particularly useful. Then it is just the same as saying "a thing".
    - Retra 8y ago
      I didn't say "everything is a virtualization layer". I said every problem could be solved with one, because it is a fundamental capability of computing. It's the same difference between implementing something in hardware vs software.
      - 8y ago
mindcrime 8y ago
Patterns didn't "fail" they just became part of the background like everything else in this industry eventually does. Because we're all so busy chasing the latest shiny new fad, and once some "thing" is no longer "the new hotness" people quit talking about it, writing blog posts about it, writing books about it, etc. But if it was useful to begin with (as patterns were) people just quietly continue using $whatever like it was always there.
js8 8y ago
In my opinion, patterns have failed because they were not formalized enough. You need to understand something exactly before you can successfully approximate it. I personally find type classes (in the sense of e.g. https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia) to be much better replacement. Related to that, being able to describe things to computer is very useful for compilers etc. Patterns are a language intended to aid computer programming, but usable only for human consumption - inevitably it had to be a failure.
irq11 8y ago
GOF is one of the most useful books I’ve read in my software career (now spanning over 20 years), and I’d recommend it to any beginning developer. Design patterns did not “fail”; they’re ubiquitous in software. At worst, you can say that the terminology has changed because our industry has the attention span of a caffeinated ferret.
- Jach 8y ago
  GoF changed the terminology, too. To quote Peter Norvig: "Before the Gang of Four got all academic on us, ``singleton'' (without the formal name) was just a simple idea that deserved a simple line of code, not a whole religion." I recommend any new developers to familiarize themselves with dynamic languages (hopefully beyond JS) and to consider the idea that design patterns are just missing programming language features, and different languages will have (or not have) different patterns based on their feature set. (Norvig, again, for some intro material: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/)
  - watwut 8y ago
    But even then, I would not use dynamic language for large project expected to live long nor the kind of projects that is currently done in "enterprise". So even in cases where pattern is workaround for language not being dynamic, changing langauge just for that might not be what you want.
    - Jach 8y ago
      Of course there are always tradeoffs to make when choosing a language, especially if you expect "enterprise" scale. Others will choose (and have chosen) a dynamic language, even if you don't; many dynamic languages can scale to mega sized systems just fine. (Here's an interesting talk from a while ago from a startup thinking about building for a scale beyond what startups normally deal with, and how Clojure was a nice fit for them: https://www.youtube.com/watch?v=BThkk5zv0DE https://www.youtube.com/watch?v=BThkk5zv0DE) Changing languages also has a bunch of tradeoffs, but in mega sized software you ought to have already solved the modularity problem that lets you get that big in the first place. Being well modularized, you should be able to introduce a new language without too much impact on the rest of the systems. I used to be pretty pessimistic that more interesting languages could never be introduced to BigCo and survive, but seeing the evolution of JavaScript and Java play out, plus what's going on in mobile with Objective C + Swift and Java + Kotlin, and BigCo developers adapting to all this new syntax (both JS's and Java's latest versions are very much completely new languages compared to what the codebases started in) I'm more optimistic that developers can in fact be taught something new. The real difficulties are political, and only one minor component of that is being able to reassure that learning is fairly easy and possible.
olliej 8y ago
Patterns (in the gof sense) failed due to over creation of new “patterns” that were not general solutions to a general class of problems. They failed because many developers decided that the correct way to design software was to choose patterns and then build their software around them. They failed because they were given these excessively complex definitions that meant things were woefully misused (“Singleton” pattern is particularly terrible example) They failed because people tried to use them as something other than a general vocabulary to discuss software.
- deleted 8y ago
  [deleted]
InclinedPlane 8y ago
You can't not use patterns, period. You can only be intentional or accidental in how you apply them, and careful or careless in your intentional application as well. The problem with patterns is, as with most things in tech, relying on them like they are magic and using them to show off rather than simply being pragmatic. The other big problem is viewing the GoF book as the bible and the end of the discussion about patterns rather than just the start of a conversation. The GoF list of patterns includes a bunch of workarounds for limitations in Java which are simply not applicable in other languages. It also missed plenty of patterns that are useful in other kinds of programs. And it can give the impression that in any decent system you need to cram every conceivable pattern when the reality is that most of the time you're going to be heavily leaning on a tiny handful of patterns. Edit: some other issues at play here are not doing the work to identify and document existing patterns, especially bad or less good ones (like big ball of mud) and developing a culture of using pattern language to describe existing codebases. Also, it's a bit rich to talk about patterns "failing" when every modern language leans heavily on iterators, decorators, commands, delegates, facades, and factories. The heavy lifting blue collar patterns are out there doing the work without getting the recognition.
- dragandj 8y ago
  > bunch of workarounds for limitations in Java While i agree with you, I just want to point out that the GOF book was written before the release of Java (and its rise to popularity) and that the book uses C++ and shows bunch of workarounds for limitations in C++, not in Java.
  - jhanschoo 8y ago
    I'll go further: it seems as though that when Java was designed, there was express consideration that design patterns would find clear expression and use in Java. That is, it is not the case that design expressions are suitable for Java because of uninspired design, but because Java was designed to support programs making heavy use of design patterns.
Jach 8y ago
I started reading Richard Gabriel's book Patterns of Software just recently, enjoying it immensely. He has it available at https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf It's very much not a GoF "patterns" book but about more important (though harder to nail down) concepts like "code habitability". It's even got an introduction by Christopher Alexander himself that I appreciated. If "Patterns" have failed, it's at least in part because we've been reading the wrong material.
- MaxBarraclough 8y ago
  Interesting book, thanks for the link. Very philosophical. Interesting read about 'habitability'.
BerislavLopac 8y ago
For me, the epiphany about design patterns happened some fifteen years ago, when I was trying to understand and learn the abstract factory pattern, in PHP back then. After constructing all the concrete factory classes and the whole setup, I suddenly realised that, in PHP, it all boils down to a simple: $className = 'FooBar'; $newInstance = new $className(); And other dynamic languages, like Javascript and Python, have their own mechanisms to dynamically define the class you want to instantiate. This is not about dynamic vs static languages -- it's simply that I then realised that the GoF patterns are not some generic programming constructs; instead they are simply recipes for dealing with certain specific type of constraints arising from a specific set of programming tools. Dynamic languages (or any other tool) have their own constraints, and there are "design patterns" around them.
- mojuba 8y ago
  Agreed, generally class factories make little sense in languages where a class reference lives at run-time in some or other form. Even some static languages have this, e.g. ObjC. I would even go with a broader generalization and say that existence of patterns (i.e. things that require a lot of typing) in a given language means the language is underdesigned and/or is behind the times. Which is certainly true for Java for example.
- watwut 8y ago
  When you know in advance which object to use and object does not require configuration, instantiate that object without factory or dynamic construct. The factory is useful only if you are a.) about to wire object into something complex or b.) create it based on complicated external rules or c.) decided that some group of objects is better to be initialized all at the same place for code readability (rare). Even in java, there is not other use. As in, your php code foes not replaces factory and using factory where you phone code works is unnecessary overkill.
- realharo 8y ago
  You could still do the following in Java: Class<? extends FooInterface> c = FooBar.class; FooInterface newInstance = c.newInstance() But people usually choose not to, because it still leaves the construction details up to the caller (and forces the class to have a no-arg constructor). The point of a factory is to create a fully "configured" object, e.g. maybe the factory has a set of specific constructor arguments it uses for all the objects it creates, that the caller then doesn't have to know about, etc. It's true however that people would simply use higher order functions for this in JavaScript, e.g. function createButtonFactory(color, background) { return function(text) { return { type: 'button', color, background, text } } } const buttonMaker = createButtonFactory('grey', 'blue') and then you can pass `buttonMaker` to somewhere that wants to create buttons by just specifying the text (i.e. some function that will be calling `buttonMaker('hello')`) This has nothing to do with the language being "dynamic" though, it's about having this specific feature. You could do the same thing in C++ now that it has lambdas. The contract of the thing that uses the factory is "I need to be able to create buttons by just specifying their text", i.e. type ButtonMaker = (text: string) => Button function loadGui(buttonMaker: ButtonMaker) so the factory has to take care of all the other details (if any) to make that possible.
klmr 8y ago
Disappointingly, the article misrepresents the most serious criticism of the GoF patterns: > we often heard folks say that software patterns existed only because people used horrible languages like C++ and Java Maybe folks say that. But (at least when they thought about it a bit more) what they actually mean is that the patterns from the GoF, and similar constructs, only exist because people use “horrible” languages. Nobody is seriously disputing the existence and usefulness of functional design patterns. But they are on a higher level, and arguably more useful, than the basic building blocks from the GoF book. Peter Norvig famously found that most GoF patterns are implicit and not worth talking about in dynamic, functional languages [1]. But he isn’t saying that higher-level patterns are useless or only exist in “horrible” languages. Contrary to what the article says, the common criticism of GoF patterns isn’t an “error”, it’s spot-on. It just criticises something different from what the author thinks: few people seriously criticise the usefulness of Alexander’s pattern language. [1] http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/
- fapjacks 8y ago
  It is sort of generally true that I usually find myself only using patterns to "fill in" functionality that isn't as easily achievable (or lacking completely) in a particular language. But being able to do this is incredibly important, and I can think of at least one time in my life when having this capability put myself and my team at a significant tactical advantage. I think you could find a lot of parallels with for example AvE on Youtube, who builds the tools he needs when he doesn't have them available. I never heard any of the hype surrounding patterns, so I can't really say whether or not they lived up to it. But I recommend to young programmers that I mentor to learn about patterns, and it's been my experience that they are universally better programmers for it, even if they aren't using them except in edge cases.
- Shorel 8y ago
  Design patterns without language support are all instances of the human compiler. Some human has to do all the work. In a language with no functions or objects, like assembler, functions and objects are design patterns. You use the subroutine pattern and the abstract data type pattern. Yes, I was taught about abstract data types in C, instead of using a language with objects. This doesn't mean you should forget what functions and objects are if you use a language that supports them. What it means is that the compiler will perform additional checks to ensure the function is well defined, and it will perform additional checks to that objects are well defined. So, a more complex design pattern is something you have to care about and check for yourself in a simpler language, and something you have to care about but also something the language cares about and checks for you, in a more complex language.
moomin 8y ago
Another component of this: _mathematically sound_* patterns do seem to be useful. You can see this in most languages in the shape of list comprehensions, LINQ &c, and in Haskell in Monoids, Functors and so on. I think the big difference is: you can reason about these constructs at a higher and composable level, but patterns are just tricks of the trade that don’t compose into large patterns. Seen from this perspective, patterns are folk remedies, re-usable data structures are medicine. *or at least, close enough that they’re useful.
- marcosdumay 8y ago
  List comprehension functions are just that: functions. Monoids, Functors and etc are type classes, some semantic element of a language. List comprehension syntax is a DSL with some specific capabilities. None of that is a pre-made structure one would impose on code. Those are all functionality that the language makes available for you to use when desired.
  - moomin 8y ago
    I’m not sure how you think a typeclass differs from a pre-made structure you impose on code. The average typeclass has parts that are enforced by the compiler and “laws” which aren’t. The functionality you describe is provided only when you conform to the pattern required by the library/compiler. I don’t think the division is as cut and dried as you set out.
deleted 8y ago
[deleted]
mbrock 8y ago
I believe Christopher Alexander's architectural approach could also be considered a failure in terms of mainstream adoption and impact on urban architecture. The vision of a "timeless way of building" based on participatory design and traditional yet evolving harmonious patterns at every level of scale is beautiful but kind of steamrolled by technical capitalism, division of labor, economies of scale, CAD, etc. It's still something to admire and advocate, I think. I feel the same way about computers. In fact computers could be considered an aspect of the general Alexandrian project of harmonious life. They exist in our pockets and homes just like wallets and kitchen sinks. And computing environments are themselves architectural. Patterns of user interfaces, of social network design, of data representation, generally patterns of how the digital world is constructed—this seems like a more authentically Alexandrian field than patterns of low-level software engineering. Alexander writes about lived environments, worlds for humans to inhabit, social processes of inhabitation, and how to make sure our worlds are humane, human-scaled, and beautiful. He's not a theorist of technical construction. That's why he asks, in the foreword he was asked to write for Richard P. Gabriel's Patterns of Software, about programs written using "design patterns": > Do people actually feel more alive when using them? Is what is accomplished by these programs, and by the people who run these programs and by the people who are affected by them, better, more elevated, more insightful, better by ordinary spiritual standards? Describing the change of perspective that comes from his way of thinking: > Two things emanate from this changed standard. First, the work becomes more fun. It is deeper, it never gets tiresome or boring, because one can never really attain this standard. One’s work becomes a lifelong work, and one keeps trying and trying. So it becomes very fulfilling, to live in the light of a goal like this. > But secondly, it does change what people are trying to do. It takes away from them the everyday, lower-level aspiration that is purely technical in nature, (and which we have come to accept) and replaces it with something deep, which will make a real difference to all of us that inhabit the earth. Yet: > But at once I run into a problem. For a programmer, what is a comparable goal? What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars? Can you write a computer program on the same level as Fermat's last theorem? Can you write a program which has the enabling power of Dr. Johnson’s dictionary? Can you write a program which has the productive power of Watt’s steam engine? Can you write a program which overcomes the gulf between the technical culture of our civilization, and which inserts itself into our human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s The Waves? Just contrast this with the movement that thinks abstract factory is an example of a design pattern. I believe you could summarize Christopher Alexander's philosophy as opposition to abstract factories.
LolNoGenerics 8y ago
The GoF book eventually did more harm then good. The outcome of GoF is that patterns are (ab)used to enforce a common code structure and a reference to the origin (book) is the legitimation for it. Code samples are good for newcomers to learn and improve, but more or less "rigid" patterns make it harder to think out of the box. The form of the solution is not relevant, just the solution. If we focus too much on the form we end up in a cargo cult. And there we are. One of my favorite real world patterns is PRG (Post Redirect Get). While it is a HTTP pattern, it can be described language agnostic, which is sufficient for a proficient programmer to solve the problem. It also clarifies HTTP and it shortcomings to a degree. It solves a real problem, the context is clear and is useful as a pattern to teach.
DanielBMarkham 8y ago
Writing a book on practical analysis and being both an OO and FP programmer (and architect, whatever that means), I've spent some time thinking about patterns. I think the key phrase is this: Marick's provocative claim that, as an idea, software patterns failed is various degrees of true and false depending on how you define 'patterns' and 'failed'. Yes. What we run into again, over and over again, is the difference between human language and understanding and formal languages and understanding. Human languages are mostly spoken, extremely loose, improvisational, and change while we're using them. Mathematical languages are all written, tight and consistent, and stay the same over decades or centuries. One of the things I learned from the linguists was that written human languages, which we mostly think of as language, is in fact a very recent thing -- and once a language gets written all sorts of other things happen as a result. People start viewing the symbols on paper as having some kind of power that a few grunts and turn of a phrase do not. Somehow they seem more important, more real...but just the opposite is true. Instead, they give the illusion of being just like formal mathematics without actually being so. (There's a wonderful scene in "The Wire" where two detectives view a recent murder scene and have a conversation using only the word "fuck". Masterful example of the difference between spoken and written language in action.) The way this plays into patterns failing is that yes, there are recurring situations where the same types of problems come up. At some point, you can mathematically generalize these kinds of problems into a formal pattern of constructs and the formal pattern is less of a hassle than simply continuing to analyze and code, but that's a different concept entirely from saying that these problems are an example of Pattern X. It doesn't work like that. Our brains work like that, but solving problems doesn't. This also explains the authors observation that students find patterns most useful. It gives them a formal construct to use using the computer language they already know that appears to give them traction on the problem. It explains why new folks to programming, architecture, and patterns tend to overuse them. Neither one of these groups has any larger context to know how to solve the problem, what the language can do or not do, how patterns fail, and so forth, yet a template for a solution looks to be right in front of them. Why not use it? After all, it's good enough! That's the way we think. We naturally are attracted to the purity of math and are inveterate over-generalizers. We have to be. Otherwise we couldn't get out of the bed in the morning. For those interested in learning more about some of the concepts, here's a Wiki page I wrote up on the book: http://wiki.info-ops.org/?ref=hn http://wiki.info-ops.org/?ref=hn
charlysl 8y ago
The best and most useful role that I have found for design patterns is to use them to systematically synthesize the code directly from the design as part of a very well defined methodology. This is very well described in the MIT OCW 6.005 Elements of Software Construction course, 2008 version [1]: "Most SE courses teach design patterns as a big catalog. Instead, we’re going to learn the patterns that are relevant to moving from behavioral design to code for each of the paradigms.". The point here is that you don't just pluck a design pattern out of thin air in an ad-hoc fashion, where every GoF pattern is a potential candidate, but rather you first do behavior driven design following well defined steps in one of 3 paradigms (state machine, functional or OO, you can mix and match of course), build a model, and only when you are ready to start coding do you map each key design element to code by choosing from a reduced set of suitable design patterns. The point of the patterns is to make much of the coding almost automatic by directly translating the design to code. In particular in [2] when the design is in the state machine paradigm (machine as class (Singleton), as object, state as object (State), as enumeration), when the design is in the functional paradigm [3,4] (Composite, Interpreter and Visitor, variant as class, Facade) and the OO paradigm [5] (relation as field, relation as map, subset as boolean field) [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/ https://ocw.mit.edu/courses/electrical-engineering-and-compu... [2] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec05.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [3] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec11.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [4] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [5] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec19.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...
mirekrusin 8y ago
Patterns are just named best practices, you can't argue they, as a concept, failed, it's ridiculous. Some patterns solving problems in C++/Java context don't translate to ie. Haskell/OCaml - and that's fine, I don't think it bothers anybody just as patterns in Ethereum/Solidity smart contracts don't make sense in Javascript - the context is completely different. Patterns (named, best practices) and anti-patterns (named arrangements to be avoided) - are sign of any maturing thing (programming languages, frameworks, databases, ui etc).
- dan-robertson 8y ago
  I think this comment has little to do with the article. You say patterns are X and X is useful therefore patterns didn’t fail, whereas the article says that patterns are meant to be Y and X is not as useful as Y so patterns failed. I think what you call a pattern is what the article would call a building block and the article does not talk much about whether or not building blocks are useful.
- matwood 8y ago
  > Patterns are just named best practices Agreed, and this is one of the most important parts of patterns - being able to quickly communicate with someone else. In OO land, explaining to someone that this is a factory or a decorator lets them immediately understand the purpose. Patterns also haven't gone anywhere. They are simply different for different languages and contexts. If someone sits down at a JS UI project and they are told it uses a one way data flow pattern vs. a two-way binding pattern they will immediately have a clear high level idea of what's going on. I think people are too quick to get lost in the GoF patterns (and then mix in OO hate miss the forest through the trees). They forget that the GoF said these are common patterns that they saw while creating software. At no point did they say those were the only patterns or even the best patterns for evermore. For me, the real win for going over the GoF was a reminder to think at the next higher level of abstraction. To use the example above, Redux is a way to implement one way data flow pattern. Decoupling the implementation from abstract idea allows a higher level of understanding that is also transferable across technologies.
- stcredzero 8y ago
mark_l_watson 8y ago
Looking on my bookshelf I see that Design Patterns for Smalltalk is only about 40% of the length of Design Patterns for Java. Design patterns are not much required for reasonable dynamic languages. Interestingly, they don't seem to be needed for functional languages like Haskell either. All that said, when I did a lot of Java programming over about a 15 year period, I found the Java Design Patterns to be useful.
thom 8y ago
Patterns failed because almost nobody does any actual software design worthy of sharing. There are very few architectural decisions to make when you're working with a modern web framework, for example. That's how 99% of us live, day to day: most programming involves basically no design at all.
- drostie 8y ago
  I am not sure if I am in the 1% or if you are wrong in a foundational sense of “you have the latitude if you'll use it.” Like, in the past week I had to add a feature to a front end that is heavily based on jQuery and its ecosystem, so lots of variables that are module-local but otherwise global, and every modification to that globalish state needs to update all of it consistently. I introduced maybe 80 lines of code and comments to define a Model as an immutable value with a list of subscribers to notify when that value changes, a Set method to change the value and update the subscribers, methods to subscribe and unsubscribe easily, and another function which multiplexes a bunch of models into one model of the tuples of values. The result plays nice with that jQuery globalish code but it's terser and more organized, “define the state, define how updates must covary in one place.” But I can also see that it is not quite structured enough: it lacks functional dependencies which would structure the state more, “you select a ClientCompany in this drop-down and that wants to update the ProductList because each ClientCompany owns its own ProductList,” not because there happens to be a subscriber which has that responsibility. Also means that there is a sort of eventual consistency in the UI which was always there but now I may have an approach to remove it. So I think that I have a good deal of latitude to try new high-level structures for my code, but it's possible that I just happen to be in a lucky place where I have that freedom.
  - dbt00 8y ago
    I mean, that sounds very much like react + redux, which is where I’d recommend you start if you were building the thing you just described from scratch.
    - thom 8y ago
      Yes, and 'reactive programming' is the exact sort of architectural choice that is good to capture with a name and a clear context and motivation. The system works, folks.
mcguire 8y ago
Are Alexander's patterns influential in the architecture community? I know they get mentioned a lot, but I've never seen anything that was specifically designed by him or students following him.
kizer 8y ago
Design patterns are derived from practice and experience. The linked talk described them as being harvested. It’s easy to note reappearing patterns. It’s difficult to consider a task, identify a worthy pattern, and then “apply” it as if it were a recipe and not not a general postulate that seems to work well in a class of situations.
stcredzero 8y ago
Because it's much easier to collect a baseball card than to play professional baseball. It should have been about understanding the collective experience of programmers, not about showing dominance through having a collection. The collector mentality seems to have gripped algorithms. You shouldn't read algorithms to be able to regurgitate them. If you can apply an algorithm, that's good. But if you can learn from the techniques used to construct and analyze them, that is the underlying knowledge. Collecting baseball cards is a fine hobby. The point of the analogy isn't that collecting things or facts is bad. What's bad is the mistake of thinking that collecting by itself gives you the skills of a practitioner. Feynman's knowing anecdote: https://blogs.ubc.ca/edutara/feynmans-knowing-anecdote/ https://blogs.ubc.ca/edutara/feynmans-knowing-anecdote/
codr4 8y ago
I skimmed both books several times back in the days, but didn't really have enough experience to know what to make of it. I once used the bridge pattern to write a multi backend GUI framework, looked it up in the book and all. 32 years into the game my perspective is that patterns is exactly what I don't want in my code...
lkrubner 8y ago
Re-read “Object Oriented Programming Is An Expensive Disaster Which Must End” and you’ll see it is making a similar point, but with more of the history of how the idea of Patterns developed and then faded: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr...
- gdy 8y ago
  Is that a parody?

166 points by matt_d 8y ago

I have found it interesting when I learn of a new trend or convention, which I think is a superset of patterns, only to realize part of the way into learning it that I’ve already used it in places before. Intuitively I managed to figure out the patterns, but didn’t realize it at the time I was doing it. Once I found that it was considered a pattern, or a best practice, it became concrete. I think this speaks to patterns as being a mechanism for validating student code, but I don’t think patterns should be the method for conveying problem solving to students. Instead, much of what I learned from coding patterns early on came in the form of intellisense hints from Resharper. I would write nested loops and it would suggest the alternative LINQ query. Then Visual Studio started doing the same thing and automatically refactored my code. This meant I deconstructed the problem first, and understood the problem, and now I could simply figure out the translation. Perhaps a better way to instill patterns for new programmers is to build more robust code convention and anti-pattern recognition into the IDE, with code rewrite capabilities. For example it should be relatively trivial to recognize when local variables are clustered around certain regions of a method. When the IDE intellisense compiler recognizes this, it starts to suggest breaking out a new private method, or at least an internal function. Perhaps include a more robust hint with details about unit testing and why small methods are easier to unit test. Patterns are a broad concept though so I’m not sure how well this idea would scale.

blt 8y ago
Wow, I did not know IDEs were making suggestions like this.

pan69 8y ago

Did patterns really fail? Or did we just out grow them? For me personally patterns have always been valuable as a means of communication. Before patterns one team would talk about "device for when at rest" and another team would talk about "timber and fabric object for relax position". Now we just call it "chair" and it's common. Just like, singleton, command, proxy, whatever. Maybe design patterns simply have done their job.

tonyedgecombe 8y ago
Yes, several people I have spoken to said the main thing they got from the GoF book was giving a name to things they were already doing.
- danielbarla 8y ago
  I always felt that this is a larger value than the implementation details. The software industry was / is still in need of more standardization and common vocabulary.
- gmueckl 8y ago
  The other way to use GoF and related texts is as an inspiration. It's been a while since the last difficult software design problem that I had to solve. But I reread GoF to get a new perspective on what I was trying to solve. Also, I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. But that's how the application of design patterns leads to failure. These are raw building materials for your design. You always have to shape them to fit your exact needs. Extend them, reduce them, cut them in half and glue the halves back together with their backsides - do what you must to get a clever design that leads to simple code.
  - Terr_ 8y ago
    > I found that some people tend to take the descriptions of design patterns as a kind of gospel and any deviation from the Right Path outlined therein is heresy. I think the key aspect which distinguishes "dogmatism" from "reasonable" is whether the choice they're concerned with would cause a communication-error or leaky-abstraction.
BerislavLopac 8y ago
Yes, creating common terminology is important, and the fact that we're still doing it for basic things simply shows that this field is still in its infancy. As we all know, naming things is hard, and in many cases it was less than fortunate. E.g. I'm really excited by the concepts of "event sourcing" and "CQRS", but think that those names are quite unfortunate choices. On the other hand we have "singleton", which might not be to everyone's liking as a concept, but I think we can all agree that the name is quite clear and descriptive (that said, I've always been sorry that we didn't go for the alternative choice, "highlander").

ncmncm 8y ago

Patterns failed because they aren't patterns. But if the GoF had published a Glossary of Software Things We Find We Use, few would have bought it. In one sense DP wasn't a failure, because it made its authors boatloads of money. That's usually considered enough, if your expectations are not unreasonable. It didn't revolutionize software development, but software development already was and still is dead in the middle of a continuous revolution, with no end in sight. That revolution is driven by programming languages getting better at enabling programmers to capture ideas in libraries. Progress mostly happens by existing languages adopting good ideas. Sometimes the ideas have been tried out first in a new language, but as often not. If you have a good language idea, you stand an overwhelmingly better chance of people using it if you get it into a widely used language. As a consequence, C++ has, over the past 20 years, turned into a language that is enormously more fun than its first standardized version. C++11 is more fun than C++98, C++14 is more fun than 11, 17 is more fun than 14, and 20 will be more fun than 17. The bleeding edge is discovering how to express good ways to control the non-von Neumann hardware whose computational capacity completely overwhelms the pile of cores we are handed. It's not clear that libraries will be able help very much with that.

dualogy 8y ago
> The bleeding edge is discovering how to express good ways to control the non-von Neumann hardware whose computational capacity completely overwhelms the pile of cores we are handed Namely? What non-von-Neumann hardware are you thinking of here? Certainly not the very-much-von-Neumann innards ubiquitous today in consumer or workstation machines, mobiles, embedded/wearable/IoT gadgets, game consoles, I reckon.. so what are you thinking of here, custom-designed ASICs / FPGAs / SoC or ...?
- tow21 8y ago
  I think ncmncm means “people”. The cutting edge of computational systems organization is finding ways to effectively work with the complex multiagent systems running on wetware.
  - manicdee 8y ago

regularfry 8y ago

The main thing I learned by actually reading the Alexander book is exactly how far GoF missed the mark in translating "patterns" into the software domain. They're hierarchical, and span a vast range of scales. If one end of the scale is "Iterator", to match Alexander the other end of the scale would need to be set at "Ecosystem" or "International Community". Less than a quarter of the book would have anything to do with data structures or bytes in a file. I think there's room for a proper Software Development Pattern Language book, but GoF is definitely not it.

watwut 8y ago

I still find patterns useful, I am glad I learned them and I am super glad that they are now named consistently thanks to those books. They also make it easier to think about structures. When you need undo and redo, knowing about command pattern made it easy. When I see word decorator or iterator in code I know exactly what it is. It was useful and it is still useful if you work in object oriented language and problems that match it.

Retra 8y ago
>When you need undo and redo, knowing about command pattern made it easy Undo and redo are easy even if you don't know about "command pattern"s. Every computing problem can be solved using a virtualization layer, and that's all the command pattern is. It's not even a pattern, really... it's just the way computing works.
- watwut 8y ago
  Of course it is pattern and of course patterns are largely the way computing works. It is even one of original patterns in that book. If it seems so ordinary to you, then it is more of success ot patterns then any kind of failure. Nowdays, you learn these ideas just by reading code here and there, they are so ubiguous and simple and standard. Back then, people complained they are complicated. Everything in computing is just a way computing works. Functional programming is also just the way computing works and it still makes sense to study it's structures. And eventually someone will come up with names eventually everyone will "just know". If everything is vurtualization layer, the I don't find the term particularly useful. Then it is just the same as saying "a thing".
  - Retra 8y ago
    I didn't say "everything is a virtualization layer". I said every problem could be solved with one, because it is a fundamental capability of computing. It's the same difference between implementing something in hardware vs software.
    - 8y ago

mindcrime 8y ago

Patterns didn't "fail" they just became part of the background like everything else in this industry eventually does. Because we're all so busy chasing the latest shiny new fad, and once some "thing" is no longer "the new hotness" people quit talking about it, writing blog posts about it, writing books about it, etc. But if it was useful to begin with (as patterns were) people just quietly continue using $whatever like it was always there.

js8 8y ago

In my opinion, patterns have failed because they were not formalized enough. You need to understand something exactly before you can successfully approximate it. I personally find type classes (in the sense of e.g. https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia) to be much better replacement. Related to that, being able to describe things to computer is very useful for compilers etc. Patterns are a language intended to aid computer programming, but usable only for human consumption - inevitably it had to be a failure.

irq11 8y ago

GOF is one of the most useful books I’ve read in my software career (now spanning over 20 years), and I’d recommend it to any beginning developer. Design patterns did not “fail”; they’re ubiquitous in software. At worst, you can say that the terminology has changed because our industry has the attention span of a caffeinated ferret.

Jach 8y ago
GoF changed the terminology, too. To quote Peter Norvig: "Before the Gang of Four got all academic on us, ``singleton'' (without the formal name) was just a simple idea that deserved a simple line of code, not a whole religion." I recommend any new developers to familiarize themselves with dynamic languages (hopefully beyond JS) and to consider the idea that design patterns are just missing programming language features, and different languages will have (or not have) different patterns based on their feature set. (Norvig, again, for some intro material: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/)
- watwut 8y ago
  But even then, I would not use dynamic language for large project expected to live long nor the kind of projects that is currently done in "enterprise". So even in cases where pattern is workaround for language not being dynamic, changing langauge just for that might not be what you want.
  - Jach 8y ago
    Of course there are always tradeoffs to make when choosing a language, especially if you expect "enterprise" scale. Others will choose (and have chosen) a dynamic language, even if you don't; many dynamic languages can scale to mega sized systems just fine. (Here's an interesting talk from a while ago from a startup thinking about building for a scale beyond what startups normally deal with, and how Clojure was a nice fit for them: https://www.youtube.com/watch?v=BThkk5zv0DE https://www.youtube.com/watch?v=BThkk5zv0DE) Changing languages also has a bunch of tradeoffs, but in mega sized software you ought to have already solved the modularity problem that lets you get that big in the first place. Being well modularized, you should be able to introduce a new language without too much impact on the rest of the systems. I used to be pretty pessimistic that more interesting languages could never be introduced to BigCo and survive, but seeing the evolution of JavaScript and Java play out, plus what's going on in mobile with Objective C + Swift and Java + Kotlin, and BigCo developers adapting to all this new syntax (both JS's and Java's latest versions are very much completely new languages compared to what the codebases started in) I'm more optimistic that developers can in fact be taught something new. The real difficulties are political, and only one minor component of that is being able to reassure that learning is fairly easy and possible.

olliej 8y ago

Patterns (in the gof sense) failed due to over creation of new “patterns” that were not general solutions to a general class of problems. They failed because many developers decided that the correct way to design software was to choose patterns and then build their software around them. They failed because they were given these excessively complex definitions that meant things were woefully misused (“Singleton” pattern is particularly terrible example) They failed because people tried to use them as something other than a general vocabulary to discuss software.

deleted 8y ago
[deleted]

InclinedPlane 8y ago

You can't not use patterns, period. You can only be intentional or accidental in how you apply them, and careful or careless in your intentional application as well. The problem with patterns is, as with most things in tech, relying on them like they are magic and using them to show off rather than simply being pragmatic. The other big problem is viewing the GoF book as the bible and the end of the discussion about patterns rather than just the start of a conversation. The GoF list of patterns includes a bunch of workarounds for limitations in Java which are simply not applicable in other languages. It also missed plenty of patterns that are useful in other kinds of programs. And it can give the impression that in any decent system you need to cram every conceivable pattern when the reality is that most of the time you're going to be heavily leaning on a tiny handful of patterns. Edit: some other issues at play here are not doing the work to identify and document existing patterns, especially bad or less good ones (like big ball of mud) and developing a culture of using pattern language to describe existing codebases. Also, it's a bit rich to talk about patterns "failing" when every modern language leans heavily on iterators, decorators, commands, delegates, facades, and factories. The heavy lifting blue collar patterns are out there doing the work without getting the recognition.

dragandj 8y ago
> bunch of workarounds for limitations in Java While i agree with you, I just want to point out that the GOF book was written before the release of Java (and its rise to popularity) and that the book uses C++ and shows bunch of workarounds for limitations in C++, not in Java.
- jhanschoo 8y ago
  I'll go further: it seems as though that when Java was designed, there was express consideration that design patterns would find clear expression and use in Java. That is, it is not the case that design expressions are suitable for Java because of uninspired design, but because Java was designed to support programs making heavy use of design patterns.

Jach 8y ago

I started reading Richard Gabriel's book Patterns of Software just recently, enjoying it immensely. He has it available at https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf It's very much not a GoF "patterns" book but about more important (though harder to nail down) concepts like "code habitability". It's even got an introduction by Christopher Alexander himself that I appreciated. If "Patterns" have failed, it's at least in part because we've been reading the wrong material.

MaxBarraclough 8y ago
Interesting book, thanks for the link. Very philosophical. Interesting read about 'habitability'.

BerislavLopac 8y ago

For me, the epiphany about design patterns happened some fifteen years ago, when I was trying to understand and learn the abstract factory pattern, in PHP back then. After constructing all the concrete factory classes and the whole setup, I suddenly realised that, in PHP, it all boils down to a simple: $className = 'FooBar'; $newInstance = new $className(); And other dynamic languages, like Javascript and Python, have their own mechanisms to dynamically define the class you want to instantiate. This is not about dynamic vs static languages -- it's simply that I then realised that the GoF patterns are not some generic programming constructs; instead they are simply recipes for dealing with certain specific type of constraints arising from a specific set of programming tools. Dynamic languages (or any other tool) have their own constraints, and there are "design patterns" around them.

mojuba 8y ago
Agreed, generally class factories make little sense in languages where a class reference lives at run-time in some or other form. Even some static languages have this, e.g. ObjC. I would even go with a broader generalization and say that existence of patterns (i.e. things that require a lot of typing) in a given language means the language is underdesigned and/or is behind the times. Which is certainly true for Java for example.
watwut 8y ago
When you know in advance which object to use and object does not require configuration, instantiate that object without factory or dynamic construct. The factory is useful only if you are a.) about to wire object into something complex or b.) create it based on complicated external rules or c.) decided that some group of objects is better to be initialized all at the same place for code readability (rare). Even in java, there is not other use. As in, your php code foes not replaces factory and using factory where you phone code works is unnecessary overkill.
realharo 8y ago
You could still do the following in Java: Class<? extends FooInterface> c = FooBar.class; FooInterface newInstance = c.newInstance() But people usually choose not to, because it still leaves the construction details up to the caller (and forces the class to have a no-arg constructor). The point of a factory is to create a fully "configured" object, e.g. maybe the factory has a set of specific constructor arguments it uses for all the objects it creates, that the caller then doesn't have to know about, etc. It's true however that people would simply use higher order functions for this in JavaScript, e.g. function createButtonFactory(color, background) { return function(text) { return { type: 'button', color, background, text } } } const buttonMaker = createButtonFactory('grey', 'blue') and then you can pass `buttonMaker` to somewhere that wants to create buttons by just specifying the text (i.e. some function that will be calling `buttonMaker('hello')`) This has nothing to do with the language being "dynamic" though, it's about having this specific feature. You could do the same thing in C++ now that it has lambdas. The contract of the thing that uses the factory is "I need to be able to create buttons by just specifying their text", i.e. type ButtonMaker = (text: string) => Button function loadGui(buttonMaker: ButtonMaker) so the factory has to take care of all the other details (if any) to make that possible.

klmr 8y ago

Disappointingly, the article misrepresents the most serious criticism of the GoF patterns: > we often heard folks say that software patterns existed only because people used horrible languages like C++ and Java Maybe folks say that. But (at least when they thought about it a bit more) what they actually mean is that the patterns from the GoF, and similar constructs, only exist because people use “horrible” languages. Nobody is seriously disputing the existence and usefulness of functional design patterns. But they are on a higher level, and arguably more useful, than the basic building blocks from the GoF book. Peter Norvig famously found that most GoF patterns are implicit and not worth talking about in dynamic, functional languages [1]. But he isn’t saying that higher-level patterns are useless or only exist in “horrible” languages. Contrary to what the article says, the common criticism of GoF patterns isn’t an “error”, it’s spot-on. It just criticises something different from what the author thinks: few people seriously criticise the usefulness of Alexander’s pattern language. [1] http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/

fapjacks 8y ago
It is sort of generally true that I usually find myself only using patterns to "fill in" functionality that isn't as easily achievable (or lacking completely) in a particular language. But being able to do this is incredibly important, and I can think of at least one time in my life when having this capability put myself and my team at a significant tactical advantage. I think you could find a lot of parallels with for example AvE on Youtube, who builds the tools he needs when he doesn't have them available. I never heard any of the hype surrounding patterns, so I can't really say whether or not they lived up to it. But I recommend to young programmers that I mentor to learn about patterns, and it's been my experience that they are universally better programmers for it, even if they aren't using them except in edge cases.
Shorel 8y ago
Design patterns without language support are all instances of the human compiler. Some human has to do all the work. In a language with no functions or objects, like assembler, functions and objects are design patterns. You use the subroutine pattern and the abstract data type pattern. Yes, I was taught about abstract data types in C, instead of using a language with objects. This doesn't mean you should forget what functions and objects are if you use a language that supports them. What it means is that the compiler will perform additional checks to ensure the function is well defined, and it will perform additional checks to that objects are well defined. So, a more complex design pattern is something you have to care about and check for yourself in a simpler language, and something you have to care about but also something the language cares about and checks for you, in a more complex language.

moomin 8y ago

Another component of this: _mathematically sound_* patterns do seem to be useful. You can see this in most languages in the shape of list comprehensions, LINQ &c, and in Haskell in Monoids, Functors and so on. I think the big difference is: you can reason about these constructs at a higher and composable level, but patterns are just tricks of the trade that don’t compose into large patterns. Seen from this perspective, patterns are folk remedies, re-usable data structures are medicine. *or at least, close enough that they’re useful.

marcosdumay 8y ago
List comprehension functions are just that: functions. Monoids, Functors and etc are type classes, some semantic element of a language. List comprehension syntax is a DSL with some specific capabilities. None of that is a pre-made structure one would impose on code. Those are all functionality that the language makes available for you to use when desired.
- moomin 8y ago
  I’m not sure how you think a typeclass differs from a pre-made structure you impose on code. The average typeclass has parts that are enforced by the compiler and “laws” which aren’t. The functionality you describe is provided only when you conform to the pattern required by the library/compiler. I don’t think the division is as cut and dried as you set out.

deleted 8y ago

[deleted]

mbrock 8y ago

I believe Christopher Alexander's architectural approach could also be considered a failure in terms of mainstream adoption and impact on urban architecture. The vision of a "timeless way of building" based on participatory design and traditional yet evolving harmonious patterns at every level of scale is beautiful but kind of steamrolled by technical capitalism, division of labor, economies of scale, CAD, etc. It's still something to admire and advocate, I think. I feel the same way about computers. In fact computers could be considered an aspect of the general Alexandrian project of harmonious life. They exist in our pockets and homes just like wallets and kitchen sinks. And computing environments are themselves architectural. Patterns of user interfaces, of social network design, of data representation, generally patterns of how the digital world is constructed—this seems like a more authentically Alexandrian field than patterns of low-level software engineering. Alexander writes about lived environments, worlds for humans to inhabit, social processes of inhabitation, and how to make sure our worlds are humane, human-scaled, and beautiful. He's not a theorist of technical construction. That's why he asks, in the foreword he was asked to write for Richard P. Gabriel's Patterns of Software, about programs written using "design patterns": > Do people actually feel more alive when using them? Is what is accomplished by these programs, and by the people who run these programs and by the people who are affected by them, better, more elevated, more insightful, better by ordinary spiritual standards? Describing the change of perspective that comes from his way of thinking: > Two things emanate from this changed standard. First, the work becomes more fun. It is deeper, it never gets tiresome or boring, because one can never really attain this standard. One’s work becomes a lifelong work, and one keeps trying and trying. So it becomes very fulfilling, to live in the light of a goal like this. > But secondly, it does change what people are trying to do. It takes away from them the everyday, lower-level aspiration that is purely technical in nature, (and which we have come to accept) and replaces it with something deep, which will make a real difference to all of us that inhabit the earth. Yet: > But at once I run into a problem. For a programmer, what is a comparable goal? What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars? Can you write a computer program on the same level as Fermat's last theorem? Can you write a program which has the enabling power of Dr. Johnson’s dictionary? Can you write a program which has the productive power of Watt’s steam engine? Can you write a program which overcomes the gulf between the technical culture of our civilization, and which inserts itself into our human life as deeply as Eliot’s poems of the wasteland or Virginia Woolf’s The Waves? Just contrast this with the movement that thinks abstract factory is an example of a design pattern. I believe you could summarize Christopher Alexander's philosophy as opposition to abstract factories.

LolNoGenerics 8y ago

The GoF book eventually did more harm then good. The outcome of GoF is that patterns are (ab)used to enforce a common code structure and a reference to the origin (book) is the legitimation for it. Code samples are good for newcomers to learn and improve, but more or less "rigid" patterns make it harder to think out of the box. The form of the solution is not relevant, just the solution. If we focus too much on the form we end up in a cargo cult. And there we are. One of my favorite real world patterns is PRG (Post Redirect Get). While it is a HTTP pattern, it can be described language agnostic, which is sufficient for a proficient programmer to solve the problem. It also clarifies HTTP and it shortcomings to a degree. It solves a real problem, the context is clear and is useful as a pattern to teach.

DanielBMarkham 8y ago

Writing a book on practical analysis and being both an OO and FP programmer (and architect, whatever that means), I've spent some time thinking about patterns. I think the key phrase is this: Marick's provocative claim that, as an idea, software patterns failed is various degrees of true and false depending on how you define 'patterns' and 'failed'. Yes. What we run into again, over and over again, is the difference between human language and understanding and formal languages and understanding. Human languages are mostly spoken, extremely loose, improvisational, and change while we're using them. Mathematical languages are all written, tight and consistent, and stay the same over decades or centuries. One of the things I learned from the linguists was that written human languages, which we mostly think of as language, is in fact a very recent thing -- and once a language gets written all sorts of other things happen as a result. People start viewing the symbols on paper as having some kind of power that a few grunts and turn of a phrase do not. Somehow they seem more important, more real...but just the opposite is true. Instead, they give the illusion of being just like formal mathematics without actually being so. (There's a wonderful scene in "The Wire" where two detectives view a recent murder scene and have a conversation using only the word "fuck". Masterful example of the difference between spoken and written language in action.) The way this plays into patterns failing is that yes, there are recurring situations where the same types of problems come up. At some point, you can mathematically generalize these kinds of problems into a formal pattern of constructs and the formal pattern is less of a hassle than simply continuing to analyze and code, but that's a different concept entirely from saying that these problems are an example of Pattern X. It doesn't work like that. Our brains work like that, but solving problems doesn't. This also explains the authors observation that students find patterns most useful. It gives them a formal construct to use using the computer language they already know that appears to give them traction on the problem. It explains why new folks to programming, architecture, and patterns tend to overuse them. Neither one of these groups has any larger context to know how to solve the problem, what the language can do or not do, how patterns fail, and so forth, yet a template for a solution looks to be right in front of them. Why not use it? After all, it's good enough! That's the way we think. We naturally are attracted to the purity of math and are inveterate over-generalizers. We have to be. Otherwise we couldn't get out of the bed in the morning. For those interested in learning more about some of the concepts, here's a Wiki page I wrote up on the book: http://wiki.info-ops.org/?ref=hn http://wiki.info-ops.org/?ref=hn

charlysl 8y ago

The best and most useful role that I have found for design patterns is to use them to systematically synthesize the code directly from the design as part of a very well defined methodology. This is very well described in the MIT OCW 6.005 Elements of Software Construction course, 2008 version [1]: "Most SE courses teach design patterns as a big catalog. Instead, we’re going to learn the patterns that are relevant to moving from behavioral design to code for each of the paradigms.". The point here is that you don't just pluck a design pattern out of thin air in an ad-hoc fashion, where every GoF pattern is a potential candidate, but rather you first do behavior driven design following well defined steps in one of 3 paradigms (state machine, functional or OO, you can mix and match of course), build a model, and only when you are ready to start coding do you map each key design element to code by choosing from a reduced set of suitable design patterns. The point of the patterns is to make much of the coding almost automatic by directly translating the design to code. In particular in [2] when the design is in the state machine paradigm (machine as class (Singleton), as object, state as object (State), as enumeration), when the design is in the functional paradigm [3,4] (Composite, Interpreter and Visitor, variant as class, Facade) and the OO paradigm [5] (relation as field, relation as map, subset as boolean field) [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/ https://ocw.mit.edu/courses/electrical-engineering-and-compu... [2] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec05.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [3] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec11.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [4] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec15.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu... [5] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-elements-of-software-construction-fall-2008/lecture-notes/MIT6_005f08_lec19.pdf https://ocw.mit.edu/courses/electrical-engineering-and-compu...

mirekrusin 8y ago

Patterns are just named best practices, you can't argue they, as a concept, failed, it's ridiculous. Some patterns solving problems in C++/Java context don't translate to ie. Haskell/OCaml - and that's fine, I don't think it bothers anybody just as patterns in Ethereum/Solidity smart contracts don't make sense in Javascript - the context is completely different. Patterns (named, best practices) and anti-patterns (named arrangements to be avoided) - are sign of any maturing thing (programming languages, frameworks, databases, ui etc).

dan-robertson 8y ago
I think this comment has little to do with the article. You say patterns are X and X is useful therefore patterns didn’t fail, whereas the article says that patterns are meant to be Y and X is not as useful as Y so patterns failed. I think what you call a pattern is what the article would call a building block and the article does not talk much about whether or not building blocks are useful.
matwood 8y ago
> Patterns are just named best practices Agreed, and this is one of the most important parts of patterns - being able to quickly communicate with someone else. In OO land, explaining to someone that this is a factory or a decorator lets them immediately understand the purpose. Patterns also haven't gone anywhere. They are simply different for different languages and contexts. If someone sits down at a JS UI project and they are told it uses a one way data flow pattern vs. a two-way binding pattern they will immediately have a clear high level idea of what's going on. I think people are too quick to get lost in the GoF patterns (and then mix in OO hate miss the forest through the trees). They forget that the GoF said these are common patterns that they saw while creating software. At no point did they say those were the only patterns or even the best patterns for evermore. For me, the real win for going over the GoF was a reminder to think at the next higher level of abstraction. To use the example above, Redux is a way to implement one way data flow pattern. Decoupling the implementation from abstract idea allows a higher level of understanding that is also transferable across technologies.
stcredzero 8y ago

mark_l_watson 8y ago

Looking on my bookshelf I see that Design Patterns for Smalltalk is only about 40% of the length of Design Patterns for Java. Design patterns are not much required for reasonable dynamic languages. Interestingly, they don't seem to be needed for functional languages like Haskell either. All that said, when I did a lot of Java programming over about a 15 year period, I found the Java Design Patterns to be useful.

thom 8y ago

Patterns failed because almost nobody does any actual software design worthy of sharing. There are very few architectural decisions to make when you're working with a modern web framework, for example. That's how 99% of us live, day to day: most programming involves basically no design at all.

drostie 8y ago
I am not sure if I am in the 1% or if you are wrong in a foundational sense of “you have the latitude if you'll use it.” Like, in the past week I had to add a feature to a front end that is heavily based on jQuery and its ecosystem, so lots of variables that are module-local but otherwise global, and every modification to that globalish state needs to update all of it consistently. I introduced maybe 80 lines of code and comments to define a Model as an immutable value with a list of subscribers to notify when that value changes, a Set method to change the value and update the subscribers, methods to subscribe and unsubscribe easily, and another function which multiplexes a bunch of models into one model of the tuples of values. The result plays nice with that jQuery globalish code but it's terser and more organized, “define the state, define how updates must covary in one place.” But I can also see that it is not quite structured enough: it lacks functional dependencies which would structure the state more, “you select a ClientCompany in this drop-down and that wants to update the ProductList because each ClientCompany owns its own ProductList,” not because there happens to be a subscriber which has that responsibility. Also means that there is a sort of eventual consistency in the UI which was always there but now I may have an approach to remove it. So I think that I have a good deal of latitude to try new high-level structures for my code, but it's possible that I just happen to be in a lucky place where I have that freedom.
- dbt00 8y ago
  I mean, that sounds very much like react + redux, which is where I’d recommend you start if you were building the thing you just described from scratch.
  - thom 8y ago
    Yes, and 'reactive programming' is the exact sort of architectural choice that is good to capture with a name and a clear context and motivation. The system works, folks.

mcguire 8y ago

Are Alexander's patterns influential in the architecture community? I know they get mentioned a lot, but I've never seen anything that was specifically designed by him or students following him.

kizer 8y ago

Design patterns are derived from practice and experience. The linked talk described them as being harvested. It’s easy to note reappearing patterns. It’s difficult to consider a task, identify a worthy pattern, and then “apply” it as if it were a recipe and not not a general postulate that seems to work well in a class of situations.

stcredzero 8y ago

Because it's much easier to collect a baseball card than to play professional baseball. It should have been about understanding the collective experience of programmers, not about showing dominance through having a collection. The collector mentality seems to have gripped algorithms. You shouldn't read algorithms to be able to regurgitate them. If you can apply an algorithm, that's good. But if you can learn from the techniques used to construct and analyze them, that is the underlying knowledge. Collecting baseball cards is a fine hobby. The point of the analogy isn't that collecting things or facts is bad. What's bad is the mistake of thinking that collecting by itself gives you the skills of a practitioner. Feynman's knowing anecdote: https://blogs.ubc.ca/edutara/feynmans-knowing-anecdote/ https://blogs.ubc.ca/edutara/feynmans-knowing-anecdote/

codr4 8y ago

I skimmed both books several times back in the days, but didn't really have enough experience to know what to make of it. I once used the bridge pattern to write a multi backend GUI framework, looked it up in the book and all. 32 years into the game my perspective is that patterns is exactly what I don't want in my code...

lkrubner 8y ago

Re-read “Object Oriented Programming Is An Expensive Disaster Which Must End” and you’ll see it is making a similar point, but with more of the history of how the idea of Patterns developed and then faded: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr...

gdy 8y ago
Is that a parody?