[HN Gopher] "Design Patterns" Aren't (2002)
___________________________________________________________________
"Design Patterns" Aren't (2002)
Author : Tomte
Score : 64 points
Date : 2021-03-07 15:34 UTC (7 hours ago)
(HTM) web link (perl.plover.com)
(TXT) w3m dump (perl.plover.com)
| kgeist wrote:
| Design patterns appear in languages without enough syntax sugar.
|
| But having too much syntax sugar can be a problem, too. At least,
| design patterns translate between languages/systems, it's a
| common language. Syntax sugar isn't.
| cowanon22 wrote:
| I think the book "Fundamentals of Software Architecture, an
| Engineering Approach" (Oreilly) is much closer to what most
| engineers need today than the GoF book. It covers topics such as
| layers, pipelines, microkernels, events, microservices,
| components, and how to put it all together into a coherent
| design.
|
| GoF was great for it's time and context, but the world has moved
| on and even mid-level engineers need to be aware of software
| architecture and how to put it all together.
| hota_mazi wrote:
| The author of this presentation claims that Perl's type system is
| better than C++ and that
|
| "the C++ macro system blows goat dick".
|
| Quality arguments and vocabulary.
| neonological wrote:
| Don't let vocabulary or lack of evidence distract you from the
| main point. Lack of either doesn't invalidate the argument it
| just invalidates your bias.
|
| The burden remains on you to validate the argument and ignore
| your biases as obviously this author and the people who voted
| him up have their reasons for believing in what they believe.
| captainmuon wrote:
| The best explanation I heard of design patterns is, that they are
| not a template to slavishly follow when producing code, but a
| common language to talk about code. So you should be able to go
| and _identify_ , look, this is an iterator, this is a command
| pattern, this is a monad, and you have a clear and concise way to
| reason about your code and talk to other people.
|
| The second best explanation is that patterns are often a sign of
| shortcomings in the language. OP gives the example of iterators.
| Another example is the visitor pattern. Or async/yield as a
| replacement for explicit state machines.
|
| A thing I'd really like to see in a language would be language
| level support for the command pattern (being able to capture
| arbitrary blocks of code, lift the execution to an object, and
| undo/redo it). Or to be able to include the state of an object in
| the type system - not like Rust does it with typestates, but to
| be able to say `Child` is a `Person` where `age < 18`, and if the
| compiler can't prove that the condition always holds, then it
| will force you to write the precondition checks or check it at
| runtime.
| capableweb wrote:
| > The second best explanation is that patterns are often a sign
| of shortcomings in the language
|
| Agree. Came across a blogpost that describes this very well by
| using Clojure as an example: http://mishadoff.com/blog/clojure-
| design-patterns/
| BoiledCabbage wrote:
| That last thing you're looking for I believe is called
| dependent types.
| Smaug123 wrote:
| Dependent types are one way to achieve that effect, but I
| think what you're actually referring to is "refinement
| types".
| centimeter wrote:
| See LiquidHaskell for probably the most mature SMT-based
| refinement types implementation.
| matheusmoreira wrote:
| The best explanation I've ever seen for design patterns is that
| they are workarounds for weaknesses of the programming
| language. Usually Java and its contemporaries.
|
| http://journal.stuffwithstuff.com/2010/09/18/futureproofing-...
|
| Factories, for example. They're essentially just constructors.
| So why not use the new keyword? Turns out new has limitations:
| - Dependency on the constructed type at the ABI level -
| Cannot return subtypes of the constructed type - Special
| keyword, not orthogonal with the rest of the language
|
| Singletons, for example. They're essentially classes with
| static methods and state. Why not use these language features
| instead of coming up with incredibly convoluted ways to ensure
| only a single instance of an object has been created? Turns out
| classes have limitations: - Classes aren't
| objects - Classes cannot be passed as parameters -
| Classes cannot implement interfaces
|
| The need for all of these patterns simply disappears in a
| better designed language. In Ruby for example everyone uses
| factory methods without even realizing it and classes are fully
| featured objects that can be used in any context.
| riffraff wrote:
| for the second thing, there's a famous presentation by
| Norvig[0] showing how many GoF patterns are "invisible" in
| powerful enough languages.
|
| It's 25 years old, but still interesting.
|
| [0] http://www.norvig.com/design-patterns/
| hosh wrote:
| That's great, but misses the point. Christopher Alexander's big
| ideas involve the people who lives, works, and plays within the
| architecture. The pattern language was designed for them, so
| they can participate in the design process of their own living
| spaces.
|
| The equivalent would be a pattern language that app users
| themselves can use for their apps. Instead of having the app
| developers drive design with A/B testing to gain user traction
| (with a societal risk of dark patterns), the users themselves
| put things together that would work with how they are doing
| things.
|
| The implementation of the code would work from there. Something
| the end-users can change the code themselves.
|
| Smalltalk was designed to allow that level of user
| participation ... but the legacy we ended up with is OOP and
| gang of four.
|
| If anything, something like TCL/TK is closer to that vision
| than what we currently have. (What we currently have: mass
| lockin of consumers and end-users by a different Gang of Four
| -- Facebook, Amazon, Apple, Google).
|
| Alexander's keynote to the '96 OOPSLA conference goes into
| detail about his ideas and how it can be applicable to software
| engineering. He was imploring software engineers not to make
| the same mistake that architects did with his pattern language
| ideas ... but we still made the same mistake anyways.
| khaledh wrote:
| His blog post on the topic goes into more detail and examples
| [1]. I tend to agree with him, especially his conclusion that
| "Patterns are signs of weakness in programming languages."
|
| [1] https://blog.plover.com/prog/design-patterns.html
| neonological wrote:
| >What is a Pattern?
|
| >An 'element of reusable software'
|
| >A design pattern systematically names, motivates, and explains a
| general design that addresses a recurring design problem in
| object-oriented systems. It describes the problem, the solution,
| when to apply the solution, and its consequences. It also gives
| implementation hints and examples. The solution is a general
| arrangement of objects and classes that solve the problem. The
| solution is customized and implemented to solve the problem in a
| particular context.
|
| Interesting to note that the person defines a pattern as
| something exclusive to using Objects and classes or in other
| words OOP. So something like lenses or functors or programming
| techniques defined outside of OOP are not patterns.
|
| When I talk to people they often define design patterns as a
| common language for various methods that are common to
| programming and not exclusive to OOP. Doesn't english and
| vocabulary fill this space? You don't find carpentry workers
| referring to domain specific vocabulary as design patterns. Why
| don't FP practitioners or mathematicians call their techniques
| "patterns"?
|
| This may piss some people off and get me a load of downvotes, but
| honestly IMO I find design patterns to be just snobbery. Instead
| of saying someone is iterating through a list they say that
| someone is using the iterator pattern. It's really just prefixing
| the word "pattern" onto some vocabulary. I used the number
| pattern on the variable pattern and the addition pattern to get
| the sum of two numbers.
|
| I would've just called the book "Programming Tricks for OOP"
| rather then "Design Patterns."
| pc86 wrote:
| I agree with 99% of what you said - I think a lot of simpler
| patterns aren't actually "patterns" in the first place,
| iterator probably being the best example. However, for things
| like factories and things more complicated than that, it is
| helpful to have a lot of context come along with just a word or
| two. If someone says "facade" or "memento" you know exactly
| what they mean.
| neonological wrote:
| Sure call it an iterator, call it facade. Naming things for
| the purpose of abstracting away complexity is one of the
| foundational functions of the English language.
|
| But there's no need to group what is essentially just English
| Vocabulary into another sub category of "language" prefixed
| with "design" and then post-fix all internal concepts with
| "pattern."
| xapata wrote:
| I share your distaste for cargo cult programming, but ...
| iterating over a list can be done in multiple ways, and doesn't
| necessarily mean one is using the iterator pattern. Using the
| jargon "iterator" to refer to an object or closure that tracks
| the state of iteration has benefit in making conversation more
| concise.
| neonological wrote:
| Sure, my point is don't attach the word "pattern" to the end
| and don't call it a "design pattern"
|
| You're just iterating through a list and calling it
| "iterating" is perfectly fine.
|
| Don't get me wrong. Naming things to abstract away complexity
| is perfectly fine and a foundational aspect of the English
| language.
|
| Naming something the "iterator pattern" and calling it a
| concept within the sub field of "Design patterns" is the
| snobbery I'm referring to.
| xapata wrote:
| The iterator pattern is the use of an object or closure to
| encapsulate the state of the iteration. This is distinct
| from using a loop induction variable in the same scope as
| the loop block itself. In a language like C, which doesn't
| provide iterators by default, it seems reasonable to call
| that a design pattern.
| neonological wrote:
| It seems more reasonable to say you're iterating through
| a collection.
|
| It also seems more reasonable to just leave it as a
| programming technique rather then give it artificial
| weight and call it some bloated unnecessary academic term
| "design pattern"
| mirekrusin wrote:
| It feels like arguing about colors from the whole spectrum of
| the rainbow without saying which color we're arguing about.
|
| The point of patterns is to recognise things that reoccur all
| the time, ie. DFS is a pattern, FIFO queue as well, so stack,
| parser combinator, microservice, optimistic locking, proxy,
| demux etc.
|
| The whole point it to use common volabulary where you can drop
| this "pattern" suffix when discussing things.
|
| It can be anything, GoF described an idea and couple of
| patterns in OO context, there are many other books "Analysis
| Patterns", "Enterprise Integration Patterns", "Patterns of
| Enterprise Application Architecture" etc.
| neonological wrote:
| > It feels like arguing about colors from the whole spectrum
| of the rainbow without saying which color we're arguing
| about.
|
| Arguing about a rainbow or arguing about a color in the
| rainbow doesn't effect the validity of an argument, I'm not
| sure your analogy makes any fundamental sense here.
|
| >The whole point it to use common vocabulary where you can
| drop this "pattern" suffix when discussing things.
|
| Isn't this the purpose of the English language? The "Design
| Pattern" concept is a redundant concept existing recursively
| in English. English already provides a "common vocabulary"
| for "discussing things."
|
| What does design patterns provide on top of that? Only
| additional complexity and redundancy.
|
| That's why basically all fields outside of programming don't
| really use the word "design pattern" because it's not
| necessary. It's a bit of snobbish for a pilot to call a
| flight technique a "design pattern."
|
| >It can be anything,
|
| And that's why it's pointless. There are even design patterns
| in poetry if you follow this line of logic. The English
| language is pretty much the "language" designed to be
| "anything." For a concept within "English" to be useful it
| must focus on a smaller subset of "anything."
| mcphage wrote:
| > It's a bit of snobbish for a pilot to call a flight
| technique a "design pattern."
|
| What? Why do you think this?
| neonological wrote:
| No more recipes from cookbooks. Those are "design
| patterns" from a book on "nutritional design patterns."
|
| I take it back, everything is a design pattern now. I see
| the light.
| mirekrusin wrote:
| Rainbow analogy meant to mean that often arguments a) focus
| on narrow aspects and b) don't explicitly define context.
| Excel patterns will be different from patterns in x86
| assembly or high level software architecture.
|
| Sometimes patters are prose about arrangement, sometimes
| template can be provided and in some cases even fully
| functional, generic code can be provided.
|
| I don't see anything wrong with calling them "design
| patterns", software is about "designing" systems and
| "pattern" reflects the fact that they re-occur, can be
| reused, can be applied to similar problems etc.
|
| The value is in recognising similar structures,
| communicating them, reusing solutions to already thought
| through problems etc.
|
| Poorly designed code can be recognised straight away with
| ad-hoc, incoherent spaghetti. On the other side there are
| many poorly applied "pattern" implementations with idiotic
| verbosity that should be called out as "anti-patterns"
| instead (just mere change of the language is enough to move
| a pattern to anti-pattern).
|
| Just because it can describe about anything doesn't make it
| pointless, just like "best practices" section can be about
| anything, it doesn't mean it makes it pointless.
|
| Anti-patterns are very useful concept as well.
| neonological wrote:
| I don't think you understand my point. Programming
| techniques and giving names to these techniques is not
| pointless. What is pointless is pretentiously inflating
| these techniques and placing them into a pseudo academic
| field and calling it "design patterns."
|
| >The value is in recognising similar structures,
| communicating them, reusing solutions to already thought
| through problems etc.
|
| The English language already reuses concepts. You drive
| cars. You do not call it the "car driving pattern" and
| make is part of the concept of "design patterns" This is
| the pointlessness I am referring to.
|
| >Anti-patterns are very useful concept as well.
|
| Yeah in common English you call it "Bad techniques" or
| "ineffective methods". Everyone is already 100% aware of
| the concept of a technique that isn't "good" you don't
| need to teach people this concept. My argument here is
| that the name "anti-pattern" is pure snobbery. It's like
| calling standing still "anti-movement."
|
| No new concept was introduced by the word "anti-pattern."
| Anti-pattern refers to a very simple concept that every
| single human understands. The pretentiousness is in the
| word and inflates the perception of this concept to the
| point where someone like you thinks "anti-pattern" is a
| completely new mind blowing concept (It's not).
| mirekrusin wrote:
| It feels more like you had to deal with some idiot
| abusing word "pattern" than anything else; "pattern",
| "method", "solution" is "potato potato", what is
| important is recognising similarities, naming higher
| level concepts for good communication and implementing
| systems organised around sound abstractions as opposed to
| adhoc, shallow, not thought through mess holding on rolls
| of scotch tape.
| neonological wrote:
| Feels like your taking this on a personal tangent
| remarking on who I've dealt with in the past rather then
| taking the point head on because the logic is pretty much
| inescapable.
|
| Whether I have or have not dealt with such a person named
| Chris P. is irrelevant to the the point.
|
| >what is important is recognising similarities, naming
| higher level concepts for good communication
|
| Isn't this what the English language is for? Doesn't
| every single person on the face of the earth recognize
| all of these concepts and deploy all of these concepts
| using the English language on fields more numerous than
| computer science alone?
| jcelerier wrote:
| > What does design patterns provide on top of that? Only
| additional complexity and redundancy.
|
| understanding each other would be impossible if we just
| said, e.g. strategy or command.
|
| "we use a strategy" can mean a ton of stuff in the context
| of a chat between developers in a company. "we use the
| strategy pattern" will be clear to everyone.
| neonological wrote:
| Change the name strategy to something more clear. Kind of
| pretentious to use a common word "strategy" to describe a
| specific technique as if it's the most strategic pattern
| ever.
|
| It's like if someone came up with the "Logic pattern" or
| "Intelligence pattern."
| rbonvall wrote:
| FP practitioners are guilty of this as well, when talking about
| "the Maybe monad" or "the IO monad".
| neonological wrote:
| Naming stuff is ok. I understand this. It's done in every
| field.
|
| But calling the "naming of things" a "design pattern" is
| pretentious. Nobody calls Monads the "Monad pattern" and
| categorizes it as a sub field of "design patterns."
|
| It's just like how we abstract the concept of getting into a
| car and commanding the car under the word "driving." That's
| fine. What's wrong is if We called it the "driving pattern"
| and place it an area of study within the automobile field
| called "design patterns."
|
| Imagine if some expert race driver publishes a driving book
| called "Design patterns" then with an analogy relates it to
| architecture. Why not just call the book "Driving techniques"
| and eschew the useless analogy?
|
| I'll tell you why the GoF did this. Because "Design patterns"
| sounds more academic, and the catharsis of realizing the
| analogy between architecture and programming techniques
| inflates the perception of what these concepts actually are.
| In the end these are just programming tricks or techniques.
| alisonkisk wrote:
| FP programmers call their patterns Typeclass Laws.
|
| Mathematicians aren't building/designing things all day long so
| they don't need this word.
|
| "A pattern language is an organized and coherent set of
| patterns, each of which describes a problem and the core of a
| solution that can be used in many ways within a specific field
| of expertise. The term was coined by architect Christopher
| Alexander and popularized by his 1977 book A Pattern Language."
| (Wikipedia on Pattern Language).
| neonological wrote:
| >Mathematicians aren't building/designing things all day long
| so they don't need this word.
|
| Not true, they build proofs. Within proofs there are many
| many common techniques, aka "patterns."
|
| Either way you seem to imply that "patterns" are for people
| who "build" things, which isn't emphasized in your definition
| below:
|
| >"A pattern language is an organized and coherent set of
| patterns, each of which describes a problem and the core of a
| solution that can be used in many ways within a specific
| field of expertise. The term was coined by architect
| Christopher Alexander and popularized by his 1977 book A
| Pattern Language."
|
| The problem with the above definition is that English
| vocabulary already communicates what a pattern does perfectly
| fine. What is the point coming up with an over complex name
| and postfixing all of these things with "pattern?" It's
| basically a redundant concept.
|
| In fact, my communication with you at this very moment is
| employing many many common patterns. Check the pattern in the
| previous sentence "many many." I call it the double emphasis
| pattern and I've used that pattern twice in this reply. I'll
| write more about it in my book on Design patterns for English
| communication.
| bluefirebrand wrote:
| > This may piss some people off and get me a load of downvotes,
| but honestly IMO I find design patterns to be just snobbery
|
| 100%. I recently was interviewing so I decided to brush up on
| some design pattern terminology because plenty of job postings
| reference them and I didn't study them in school.
|
| I was blown away by how much of it's just complex-sounding
| terms for simple concepts.
|
| I was also surprised how poorly defined they really are.
| neonological wrote:
| Agreed.
|
| Also note that school generally doesn't teach it because
| these patterns don't have any formal basis in theory. It's
| the complex vocabulary that gives these things more academic
| weight than they actually have. "Tricks of the trade" doesn't
| sound as rigorous as "Design Patterns" but really it's the
| same thing.
| jcelerier wrote:
| > You don't find carpentry workers referring to domain specific
| vocabulary as design patterns.
|
| they don't call it a "design pattern", but a "technique".
|
| see e.g. https://www.amazon.fr/Woodwork-Step-Carpentry-
| Techniques-Mad... or http://www.basiccarpentrytechniques.com/
|
| to me, "hip roof framing" or "trench shoring" definitely sounds
| like "applying a visitor" or "implementing an abstract factory"
| would sound to a non-software-engineer carpenter.
| neonological wrote:
| Yeah and a technique is part of the "English" language.
| Techniques exist everywhere.
|
| But in computer science they had to basically make the same
| concept sound more snobbish. These aren't programming
| techniques, they are "design patterns."
| shoo wrote:
| Prior HN discussion of Christopher Alexander:
| https://news.ycombinator.com/item?id=17480178
| barefeg wrote:
| I didn't focus on the iterators at all and still didn't get the
| point. What I got so far; an architect wrote a book with some
| definitions that allows people discuss a solution. Then the
| author says we should take that seriously. Which is fine, but how
| exactly? The author spends a lot of time on explaining why (for
| his POV) software design patterns are wrong, but no example of
| how to use what the book says in software. What am I missing?
| carapace wrote:
| I think it's a reasonable critique of the concept of Pattern
| Language as adopted by IT. The interlocking nature of the
| patterns at various scales, the way that normal folk are expected
| to use the PL _in situ_ to evoke and evolve design organically
| from an intrinsic understanding of their own needs and an
| informed intuition of the potentialities of the space, these are
| wholly omitted from GoF PL. Not, I think, because of any fault of
| them themselves, but because the very idea of applying Pattern
| Language thinking to computer system design was so novel at the
| time they proposed it.
|
| Certainly CA is a genius and I think we would all benefit from at
| least skimming the original "Pattern Language". (His latter work,
| "Nature of Order", is sublime.)
|
| It's worth reading CA's "A City Is Not a Tree" as well:
|
| https://en.wikipedia.org/wiki/A_City_is_Not_a_Tree
|
| https://www.patternlanguage.com/archive/cityisnotatree.html
|
| I feel like Jef Raskin's work ("Humane Interface", the Canon Cat)
| are closer in spirit to a PL for computers than the GoF pattern
| catalog.
| ncmncm wrote:
| Each design pattern documents a weakness in the language or
| omission from the library, such that the pattern cannot be or has
| not been pulled into the library.
|
| Weaker languages usually get a new feature when the pattern is
| recognized. Stronger languages get a new library component, if it
| can be expressed well enough, or sometimes a new feature.
|
| Some languages have ossified, accepting neither new core features
| nor library components, and code in them is all-over patterns.
| dwenzek wrote:
| > How can you distribute responsibility for design through all
| levels of a large hierarchy, while still maintaining consistency
| and harmony of overall design?
|
| This how the author summaries the intent of Christopher
| Alexander's work. I have not read "A Pattern Language" so it's
| difficult to say if this is accurate or not. However this is such
| an important issue in software engineering that I would welcome
| any ideas to reduce the problem.
|
| I agree when the author that the GoF addressed a lower level
| problem. However, I'm also disappointed by these slides that
| provide not hints for a better high-level approach. The GoF
| patterns form a language for developers speaking to developpers.
| We also need a language across roles.
| dang wrote:
| If curious, past threads:
|
| _"Design Patterns" Aren 't (2002)_ -
| https://news.ycombinator.com/item?id=12849757 - Nov 2016 (122
| comments)
|
| _Design patterns aren 't_ -
| https://news.ycombinator.com/item?id=2675551 - June 2011 (30
| comments)
|
| _" Design Patterns" Aren't_ -
| https://news.ycombinator.com/item?id=284503 - Aug 2008 (18
| comments)
| q845712 wrote:
| I think there's a lot of utility in trying to achieve some
| conceptual consistency across a large codebase worked on by many
| people. Most organizations of even 12+ developers wind up with an
| internal informal "pattern language" that you learn while
| onboarding, and it can be wildly helpful if that's explicitly
| acknowledged as an area of knowledge to help new teammates
| acquire.
|
| To me a lot of the tension comes from the "endless september"
| nature of software, that over the last 20 years we just keep
| absorbing more and more new-ish folks who come in with vastly
| varying levels of formal and informal education.
|
| I'm tempted to describe one mindset as "catalogers" in contrast
| to other mindsets that might be called "explorers", "consensus
| builders", "hackers", "do-ers", etc. (not a complete list nor
| entirely disjoint categories -- i'm a lousy cataloger!)
|
| I think part of this endless Design Patterns discussion is that
| some, myself included, would like to push back when "design
| patterns" starts to become "a standard and nearly exhaustive
| catalog that the whole field uses with uniform meanings."
| Smaug123 wrote:
| In case you hadn't heard of Simon Wardley's "pioneers, town
| planners, settlers" model, it seems relevant to your third
| paragraph (https://blog.gardeviance.org/2015/03/on-pioneers-
| settlers-to...).
| dexwiz wrote:
| Design patterns fill a similar niche as recipes. You have learned
| the fundamentals, control flow, data structures, algos, etc, but
| you are t sure how to put that all together.
|
| After learning the fundamentals of cooking, you can start
| exploring different recipes. Most of them are instructional and
| assume a base level of knowledge like what golden brown or finely
| diced means. They let you use your skills to make something
| physical.
|
| Design patterns fill a similar niche, somewhere between abstract
| concept and concrete code. What differs is that most recipes can
| be made without prior dependency. You can make chicken for dinner
| no matter what you made before. Large software projects aren't
| like that. When deciding what to do you have to consider what you
| and your coworkers made for every previous meal. This makes a
| recipe much harder to choose, and often ends up as square
| peg/round hole.
|
| On the flip side most people start with recipes and only after
| much trial and error so they learn how to cook.
| phromo wrote:
| Alexander's works are wonderfully inspiring to read. I'm sure
| they can inspire many diverse interpretations useful for creating
| digital artifacts.
|
| To the curious, note that what the patterns are is not explained
| in 'A Pattern Language' but instead in the companion book
| 'Timeless way of Building'. It's quite a philosophical
| exposition. It talks about evoking 'The quality without a name',
| that every human has the capacity to feel, but not necessary to
| name or dissect.
|
| Here's a quote for the curious from 'Timeless way of Building'
| that I think captures somewhat what the post wishes more software
| designers thought about in relation to patterns:
|
| (page 236-237, speaking about the specialisation of professions
| in which people's pattern languages gets lost through
| disconnection)
|
| "... Of course, even now a town still gets its shape from pattern
| languages of a sort. The architects and planners and bankers have
| pattern languages which tell them to build gigantic steel and
| concrete buildings. The users have a few shattered patterns left
| in their vocabulary: a sheet of plastic to make a kitchen
| counter; huge plate glass windows for the living room; wall-to-
| wall carpet in the bathroom -- and they enthusiastically piece
| these patches together, whenever they have a free weekend.
|
| But these remnants of our former languages are dead and empty.
| They are based mainly on the by-products of industry. People use
| plate glass windows, formica counters, wall-to-wall carpet,
| because industry makes them available, not because these patterns
| contain anything essential about life, or how to live it.
|
| The time when a pattern language was a song, in which people
| could sing the whole of life, is gone. The pattern languages in
| society are dead. They are ashes and fragments in the people's
| hands"
| quantified wrote:
| First, please note that this is from 2002. Wish you could edit
| the title.
|
| The last slide in the series notes that the talk gets heavily
| flamed on. It gets flamed on for good reason, IMHO.
|
| From its intro:
|
| > Description
|
| The "design patterns" movement in software claims to have been
| inspired by the works of architect Christopher Alexander. But an
| examination of Alexander's books reveals that he was actually
| talking about something much more interesting.
|
| The presentation has two parts: a takedown of the Iterator (which
| kinda misses the point of iterator, it's not purely a way to
| implement for-loops), and then a description of how Alexander had
| different goals than the GoF in their book.
|
| Ok... the book isn't Alexander. Though the patterns community was
| on the path to trying to achieve similar goals, just this
| happened to be a handbook of patterns that were more recently
| discovered. Software architecture is not as well-codified a field
| as physical architecture, needs a century or two to catch up.
|
| The real complaint is that the book is not a "Pattern Language",
| or the same as the famous Chris Alexander book. That's not in the
| title of this talk. It's also not really what the speaker spends
| much time on. Saying the C++ macro system blows goat dick doesn't
| advance arguments about the difference between a handbook of
| patterns and anything else. Inspired by is absolutely true,
| inspiration has many effects and forms.
|
| However, GoF is also about discovering and communicating the
| patterns you discover, and contains useful examples. GHJV spend
| energy describing how the patterns were identified, clarified and
| named, and they use this language in presenting the examples.
|
| Meanwhile the author of these slides seems to thing it's the copy
| side of a copy-paste command, which it definitely is not. There
| is no one true Iterator, nor Factory, Visitor, Facade, or any
| other pattern listed.
|
| So he misses the point by quite a margin, IMHO.
| [deleted]
| vikingcaffiene wrote:
| I don't know why you are getting down voted. For what its worth
| I appreciate the analysis.
|
| I kind of feel like this post shouldn't exist without the
| author taking the time to explain his POV better than a few
| bullet points on a slide. The postscript kind of goes there but
| its not enough IMO. What we are left with here reduces whatever
| his point is to a few reductive statements that probably over
| simplify his arguments and leave the rest of us either nodding
| emphatically or shaking our heads in disgust because its just
| generalized enough to confirm any pre-existing bias we already
| have. In other words this wont change any minds.
|
| I guess the one good thing to come out of reading this is that
| I'll pick up that "Pattern Language" book and give it a read.
| Perhaps this post will gain some value in retrospect with that
| context.
| mjd wrote:
| > I kind of feel like this post shouldn't exist without the
| author taking the time to explain his POV better than a few
| bullet points on a slide.
|
| I agree. It was a five-minute throwaway talk.
|
| Here's the same guy writing a better article on a related
| subject: [Design Patterns of
| 1972](https://blog.plover.com/prog/design-patterns.html)
| quantified wrote:
| I get surprising downvotes a lot. Well, thank you for
| noticing!
| alisonkisk wrote:
| It's sad that we're bringing up a 20 year old throwaway
| presentation for ridicule. This article shouldn't have been
| posted.
| quantified wrote:
| I agree. I think it was brought up for thought and
| discussion, and the first comment was strongly critical. If
| there are other thoughts on it, hope they get shared too.
| meitros wrote:
| Richard Gabriel has a really interesting and more nuanced book
| about this that I read early in my career
| https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
___________________________________________________________________
(page generated 2021-03-07 23:01 UTC)