4 ms·

In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps,

by js8 10y ago

In a galaxy far far away, there was a kingdom where people didn't know structured programming. Their programming languages only had (conditial) branches, jumps, or GOTOs (as they were colloquially called). And they had a very influential programming book, called "GOTO design patterns". Here's a few examples of design patterns from the book: - "IF pattern" - If you need to execute code only if some condition is true, you write a conditional GOTO that lands after the code that is to be executed conditionally. - "IF-ELSE pattern" - If you need to execute code only if some condition is true, and some other code if the condition is false, you use IF-ELSE pattern. It's similar to IF pattern, but at the end of the code in the IF pattern, you add another unconditional GOTO that branches after the code that is to be executed if the condition is false. - "WHILE pattern" - If you need to repeatedly execute code and check some condition after each execution, you add a conditional GOTO at the end of the code that goes back to the beginning of the code you want to repeatedly execute. - "BREAK pattern" - This is a pattern to use with the WHILE or UNTIL patterns. If you need to, on some condition, stop repeated execution of the code in the middle of the code, you add a conditional GOTO into the middle of the code that just branches after the repeatedly executed code block. Everyone was happy with the book. No more messy spaghetti code full of random GOTOs (as was common before the book appeared), because young apprentices memorized all the patterns in the book, and they just applied them rigorously. Also, understanding code became easier, because everybody instantly recognized those patterns in the well written code, and they had a common vocabulary to talk about these things. One day, a traveler from another world came into this kingdom. He looked at the book and wondered: "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" Unfortunately, he was executed for the heresy.

thom 10y ago
This is, and always has been, a poor criticism of design patterns, by people who think they're just a library of code that idiots are supposed to cut and paste to be better programmers. A common example from the GoF book is the Strategy pattern - most functional programming snarks will jump in and say you don't need this! We have first class functions you can pass around! And it's entirely true that an implementation of this pattern (a good, simple one even) is just accepting functions as arguments - cool, you probably get it! But the _design_ principle is about making strategies _explicit_ - allowing decisions to be made or policies to be enforced in ways you don't anticipate. I still see _tons_ of libraries written by smart people in functional languages that will still accept an enum of some kind to tell them what do in certain situations (e.g. a lot of HTTP libraries' extremely limited retry logic). That's an explicit design decision - to limit options instead of opening them up. Having a language to talk about the _design decisions_ at a higher level, instead of conflating them with language features, is the whole point. Everybody knows you can pass functions around as arguments, that doesn't necessarily prompt you or make it easier to discuss implementing a Strategy. Design patterns aren't a static, finite set of code snippets, and I actually think things like the linked post that mostly treat them that way aren't helpful. They give you a way of naming and talking about components of a design, possibly at a higher granularity than your programming language (and sure, different languages have different granularities). We've been hearing this same exact criticism for literally 20 years and it's boring at this point. I get that most people don't bother creating new design patterns in public these days (because they've internalised that modern languages have 'design patterns' built in), but if you look at something like React and think it's just JavaScript and there are no design decisions in there worthy of reifying, I think that's sad and unproductive.
- js8 10y ago
  My main point (just to make sure we are on the same page) was that whatever patterns are, we should also tell computers "look, here I use this pattern", and not rely just on humans to see it. Unfortunately, computers are idiot savants, so this very well might require those to be formally defined. Anyway, I think we have an ontological disagreement here. I don't believe the "design patterns" which cannot be formally defined are useful, or even that they exist. I consider them to be just phantoms, which when you attempt to formally define them, you either understand them much better (to the point where you can see how they are related), or they disappear as something that was misconceived in the first place. You seem to think that there is something real.. fine. Possibly, why I see it that way is my mathematical training. In mathematics, this battle was fought more than a century ago and the formalism camp won. That doesn't mean that intuition is completely useless.. just that people mostly keep their intuitions (and inspirations and analogies) for themselves, and when they communicate, they strive to be formal. To your React example - it's not a pattern, it's a piece of concrete reusable code. We don't need "React pattern", but we need React. Just like mathematicians, we should communicate "patterns" via reusable code.
  - mbrock 10y ago
    There are downsides to abstraction, too. The result of the urge of explicitly abstract every pattern can end up being a brittle network of dependencies. It can become really hard to adapt the formal abstractions to small requirement changes—either that or the abstractions end up byzantinely parameterized. Or you have to spend decades doing category theoretical research to discover the platonic essence of your patterns... Formalization hasn't really won in math communication, has it? How much math researched is published as Coq terms or whatever? Maintaining all of math as a network of formal abstractions is really difficult. Basically the insistence on maximal abstraction seems to imply that you try to minimize the length of application source code and as a side effect you maximize the complexity of programming languages and frameworks. By the way, Richard Gabriel discusses this issue in a chapter of his book "Patterns of Software" (free PDF available).
    - js8 10y ago
cessor 10y ago
> "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" I often asked myself this question! Why do I have to say public class DatabaseConnectionSingleton { public static DatabaseConnectionSingleton getInstance (){ ... }; } and then get an object using: var db = DatabaseConnectionSingleton.getInstance(); Why can't I say public singleton DatabaseConnection {...} and just go var db = new DatabaseConnection(); and let my runtime make sure that I get the appropriate instance? Left aside the discussion of how useful that pattern is, I would like my language to be more powerful. I am aware of alternatives (Borgs in Python) and that many people consider Singletons an antipattern, as it helps introduce globally shared state, etc. but then, why do I have to care about how instances are implemented? After all, in C#, foreach interacts with iterators, why not push other mechanisms down into the language in the same way? Ideas: // Unit of work, commits changes before the reference gets removed from stack public unit CustomerForm { } // There can be only one. public singleton DatabaseConnectionHighlander {} // Any method called updates values in some way public builder QueryString {}
- kdevrou 10y ago
  Just one of many reasons that Scala is such an attractive option for Java developers: // There is only one object DatabaseConnectionConnor {}
  - cessor 10y ago
    It's true that other languages often don't require certain patterns. Strategy and Visitor are often unnecessary when a programming language has functions as first class citizens. I found that it often helps to remember that the GoF book was written about object oriented patterns with C++.

by js8 10y ago

thom 10y ago

This is, and always has been, a poor criticism of design patterns, by people who think they're just a library of code that idiots are supposed to cut and paste to be better programmers. A common example from the GoF book is the Strategy pattern - most functional programming snarks will jump in and say you don't need this! We have first class functions you can pass around! And it's entirely true that an implementation of this pattern (a good, simple one even) is just accepting functions as arguments - cool, you probably get it! But the _design_ principle is about making strategies _explicit_ - allowing decisions to be made or policies to be enforced in ways you don't anticipate. I still see _tons_ of libraries written by smart people in functional languages that will still accept an enum of some kind to tell them what do in certain situations (e.g. a lot of HTTP libraries' extremely limited retry logic). That's an explicit design decision - to limit options instead of opening them up. Having a language to talk about the _design decisions_ at a higher level, instead of conflating them with language features, is the whole point. Everybody knows you can pass functions around as arguments, that doesn't necessarily prompt you or make it easier to discuss implementing a Strategy. Design patterns aren't a static, finite set of code snippets, and I actually think things like the linked post that mostly treat them that way aren't helpful. They give you a way of naming and talking about components of a design, possibly at a higher granularity than your programming language (and sure, different languages have different granularities). We've been hearing this same exact criticism for literally 20 years and it's boring at this point. I get that most people don't bother creating new design patterns in public these days (because they've internalised that modern languages have 'design patterns' built in), but if you look at something like React and think it's just JavaScript and there are no design decisions in there worthy of reifying, I think that's sad and unproductive.

js8 10y ago
My main point (just to make sure we are on the same page) was that whatever patterns are, we should also tell computers "look, here I use this pattern", and not rely just on humans to see it. Unfortunately, computers are idiot savants, so this very well might require those to be formally defined. Anyway, I think we have an ontological disagreement here. I don't believe the "design patterns" which cannot be formally defined are useful, or even that they exist. I consider them to be just phantoms, which when you attempt to formally define them, you either understand them much better (to the point where you can see how they are related), or they disappear as something that was misconceived in the first place. You seem to think that there is something real.. fine. Possibly, why I see it that way is my mathematical training. In mathematics, this battle was fought more than a century ago and the formalism camp won. That doesn't mean that intuition is completely useless.. just that people mostly keep their intuitions (and inspirations and analogies) for themselves, and when they communicate, they strive to be formal. To your React example - it's not a pattern, it's a piece of concrete reusable code. We don't need "React pattern", but we need React. Just like mathematicians, we should communicate "patterns" via reusable code.
- mbrock 10y ago
  There are downsides to abstraction, too. The result of the urge of explicitly abstract every pattern can end up being a brittle network of dependencies. It can become really hard to adapt the formal abstractions to small requirement changes—either that or the abstractions end up byzantinely parameterized. Or you have to spend decades doing category theoretical research to discover the platonic essence of your patterns... Formalization hasn't really won in math communication, has it? How much math researched is published as Coq terms or whatever? Maintaining all of math as a network of formal abstractions is really difficult. Basically the insistence on maximal abstraction seems to imply that you try to minimize the length of application source code and as a side effect you maximize the complexity of programming languages and frameworks. By the way, Richard Gabriel discusses this issue in a chapter of his book "Patterns of Software" (free PDF available).
  - js8 10y ago

cessor 10y ago

> "Why don't you just add these patterns into your computer language as abstractions? Wouldn't that aid comprehension even more?" I often asked myself this question! Why do I have to say public class DatabaseConnectionSingleton { public static DatabaseConnectionSingleton getInstance (){ ... }; } and then get an object using: var db = DatabaseConnectionSingleton.getInstance(); Why can't I say public singleton DatabaseConnection {...} and just go var db = new DatabaseConnection(); and let my runtime make sure that I get the appropriate instance? Left aside the discussion of how useful that pattern is, I would like my language to be more powerful. I am aware of alternatives (Borgs in Python) and that many people consider Singletons an antipattern, as it helps introduce globally shared state, etc. but then, why do I have to care about how instances are implemented? After all, in C#, foreach interacts with iterators, why not push other mechanisms down into the language in the same way? Ideas: // Unit of work, commits changes before the reference gets removed from stack public unit CustomerForm { } // There can be only one. public singleton DatabaseConnectionHighlander {} // Any method called updates values in some way public builder QueryString {}

kdevrou 10y ago
Just one of many reasons that Scala is such an attractive option for Java developers: // There is only one object DatabaseConnectionConnor {}
- cessor 10y ago
  It's true that other languages often don't require certain patterns. Strategy and Visitor are often unnecessary when a programming language has functions as first class citizens. I found that it often helps to remember that the GoF book was written about object oriented patterns with C++.