what are your thoughts on design patterns?
Feb 21 · 2 months ago · 👍 iikorni
🔒 Locked by Admin
29 Comments ↓
🚀 lars_the_bear · Feb 21 at 17:48:
Generally somewhat sceptical. I used to teach a course on patterns in Java, back when folks thought it was a new idea. There's nothing wrong with the concept, but all it's really saying is that programmers tend to end up solving the same problems repeatedly. Giving it a fancy name just makes it sound more of a big deal than it deserves. Just my $0.02.
🌆 skyjake [...] · Feb 21 at 18:06:
They are a bit of a double-edged sword, I think. On one hand, they offer experienced programmers a toolbox of solutions for common situations, making the implementation faster and less bug-prone. But on the other hand, you need to actually understand the tradeoffs involved so a less experienced programmer may apply the patterns in a too dogmatic or overengineered way, which leads in inefficiency and challenges in maintaining the code.
I first learned about design patterns in university, after having already seriously programmed for about 10 years, so it was easy to understand that they are crystallizations of many solutions I had already intuitively come across on my own. There are many useful concepts (e.g., factories) that are applicable even if you don't implement the pattern completely, so learning about the various patterns on a theoretical level can have value. One just has to remember that it may take a few tries before one gains the skills to implement a pattern in a way that best suits one's program/situation.
I think they're both underhyped and overhyped. Obviously, the original GOF Design Patterns book was written with pure OOP in mind, and...that hasn't always stood the test of time, especially now with plenty of more "functional" ways of accomplishing things. Simultaneously, for OOP languages, I think they represent a good set of "best practices" in most cases...although, I know in the case of enterprise Java, which is/was mildly dogmatic about them, it can get a bit silly. For me...I don't often really...think about them?
🚀 lars_the_bear · Feb 21 at 18:24:
@skyjake : "...so a less experienced programmer may apply the patterns in a too dogmatic or overengineered way, ..." I think this is exactly what happened in the open-source Java world. Every comp. sci. graduate knew about patterns, and wanted to apply them. So now we have Java code full of classes with names like "FooSortedIteratorVisitorComparatorFactory" and the like. It's totally incomprehensible.
🍀 gritty [OP] · Feb 21 at 21:06:
I am the less experienced programmer in this situation, trying to improve my code. almost refactored design patterns on my project, but ended up asking around first. friends had much the same opinions stated here.
is it safe to assume that through the sheer act of planning, coding, and refactoring, you end up learning versions of these patterns anyway? you just have to keep at it and rework things. at least that's what I'm getting from this thread.
I think it's good to review models early on to get an idea for how other people have handled similar problems - idioms in programming languages exist for a reason, and it's usually either because the solution is more scalable (which is the primary attraction behind Design Patterns), or the solution is "more ergonomic" in the particular language.
In general my advice would be to read code, write code, and see what works best for you in maintaining things. Often, getting locked into the trap of "will this scale" is premature optimization - Design Patterns were built for enterprise software, with large numbers of independent programmers working with a single project. Most of the things you will create, especially independently, will probably not need that level of scalability, and just getting something _working_ is half the battle.
Another way to look at it: if you get something working, regardless of how it works, you then have a mental model to refactor it, as much as you need to :)
In the end I have one pattern: 3 rewrites.
- First: understand the problem and get something working.
- Second: use more appropriate datastructures and algos.
- Third: get it right, because I realize how dumb I was before.
It is hard not to keep looping on step 3, but you must.
For me it is essential to do a near-complete rewrite as trying to fix crappy code invariably turns ugly fast.
🐦 wasolili [...] · Feb 21 at 23:42:
My main thought on design patterns is that too many people learn the patterns, but not the anti-patterns. recognizing the anti-patterns and code smells is much more useful.
Design patterns show up in languages that lack abstraction power, otherwise you just make an abstract version of said pattern and provide it as a library, instead of telling people to rewrite the same thing over and over again, so that they get it subtly wrong in different ways every time.
I don't know about that... Take smalltalk, perhaps the most dynamic of languages, although completely lacking macros. Or Lisp, with the most amazing macrology. Design patterns were just an attempt to organize human reasoning.
So that muggles can write code like 100x wizards.
smalltalk exists and that's about all it does, it probably has design patterns, cause if it had abstraction power people would actually care.
lisp has no design patterns.
wizards write libraries, muggles use libraries, simple as that, if you have abstraction, and if you don't, everyone regardless of their bloodline keeps finding new buggy ways to write a basic refcount or a linked list.
I tend to agree with Chuck Moore: you must never write any libraries.
Every task is different and the idea of taking off-the-shelf blocks, stacking them 16-deep and wiring them together is precisely why everything sucks.
If an intrusive linked list is something you dread writing and/or it takes you more than 10 minutes, your opinion does not matter.
whaever you can write in 10 minutes is going to be useless, you shouldn't be proud of writing useless code
intrusive linked list is not a one well defined thing, you can't just write it once, but you can write a library that enables you to create various kinds of inrusive linked lists easier and with less bugs (not faster, writing things fast is not good in programming), and that others can read and understand better (which is much more important than writing), meanwhile 99% of liked lists that people keep writing over and over again have no business being intrusive
There are different approaches and I am certainly not saying which ones are 'wrong'. I've tried many.
The idea that a linked list is so complicated to write that you need to link in a library -- and same for every little bit of trivial algos, or worse yet, using a giant library full of trivial code horrifies me.
That is how you wind up with a 100MB application like Bale a Etcher, that does exactly what 'dd' does.
There are people who can cook. They understand how to match flavors, and can improvise a fine meal with whatever is on hand, fast.
And then, there are people (like me as food goes), who have no clue and need at least a recipe to be followed exactly, to make a passable meal. Some people need even more -- pre-chopped packs of onions and pre-portioned ingredients because they have poor knife skills and can't use a scale.
In the end, there is nothing wrong with cookbooks and Trader Joes cut veggies. It makes it possible for more people to enjoy homemade food.
But it would be absurd to claim that you are a better cook _because_ you go strictly from a recipe and pre-portioned factory food, because it's less error-prone or more consistent.
Adding an intrusive linked list to some datastructure is close to zero mental load for me. And I might decide that I want to do something subtly different in the process which makes my code 10 times faster, something a generic library would force me to do an extra sort on.
Yes, you are talking to an f'ing maestro of code. Enjoy your food and for god's sake learn to chop your veggies with a sharp knife.
🚀 lars_the_bear · Feb 24 at 15:54:
@stack : But "linked list" isn't really a design pattern, though, is it? It's just a common data structure. If we start use the term "pattern" for that kind of thing, I think it changes the discussion completely.
I don't know why we're even talking about linked lists or libraries.
Dats structures is a much more worthwhile study than "design patterns".
Yín Wáng’s post is worth reading.
— Deciphering ‘Design Patterns’
I don't know why we're even talking about linked lists or libraries
it was an extreme example of what can become a design pattern when you lack the means to reuse code, in my overall argument that design patterns are indications of weaknesses of a given language. I've seen projects in C(obviousy), Action Script 3 (the typescript before Typescript), Java, Javascript, C# and Python all suffering from linkedlistitis, where you bake it in as a part of your "business logic" and not a separate reusable utility. If you keep designing the same thing over and over again that's a design pattern, I don't think you can define it in any better way.
to link in a library
That is how you wind up with a 100MB application
that's the C ptsd talking - you don't have proper tools to express the pattern in the language in a modular way, so you push the abstraction into the runtime creating bloat. The usefulness of abstractions is supposed to entirely dwarf its cost, and a language has two options there,
- either bloat the runtime in advance and provide an overkill solution (like dynamic typing, infinite memory, sophisticated fundamental types and so on), to give yourself enough room to fit in all sorts of abstraction with no extra cost,
- or restrict yourself specific kinds of abstractions that can be optimized away by a compiler (generics, macros, meta programming or other high arcane cruft like whatever tf mercurylang is doing)
not mutually exclusive.
it's also fitting that you chose to compare your work to domestic cooking, instead of any actual engineering discipline (or even professional cooking), makes a lot of sense for our snake oil industry that hinges on marketing alone, where warranty is unheard of, and everything is expected to break all the time. Now imagine wanting to wrap transformers by hand working on any serious electrical engineering project today (cause you're real good at it according to yourself), and how hard you'd be laughed out of the room for even suggesting that. Just use standard components, and if you want to design a transformer then drop this project and go do that in isolation and if you can actually come up with a new design that is even remotely better than standard in any aspect, that would likely be the greatest achievement of your entire career, and everyone and their granmas will immediately start manufacturing and using it all over the place. A less extreme example would be designing a new kind of a power supply, which is more conceivable but still not something you'd just randomly do in a completely unrelated project, just take an existing proven design, tweak whatever you are supposed to tweak and put the components on the board, that's what you do, when you are an engineer and not a maestro.
From personal experience with Model/View/Controller pattern in Smalltalk... I remember cursing a lot and going in circles pushing code from one class to another in vain whenever trying to implement anything real.
@namark - appreciate your response and kind of agree.
I consider myself more of an artist than an engineer and program entirely for the joy it brings me on a variety of levels.
My art is bug-free code. It consists of clever, concise and generally very small handmade code. Amusing comments that sometimes run for several pages when a roadside attraction gets interesting. Side projects with weird probabilistic data structures. etc. Odd interpilers and macrology.
A visual artist will spend a lifetime drawing faces and hands. Some get very good at it. Offering a set of rubber stamps will be declined with a variety of levels of politeness. A suggestion that a 10-min sketch cannot be executed well is likewise offensive.
Factory code...
There is a corporate drive to lock coding away from people. It is done through locking processors with hardware keys, factory code tech, ridiculous B2B patent trade, warranties. unions. degrees in computer pseudoscience.
Also calling what some call art 'snake oil'.
Factory crap is obviously necessary. You will not get a handcrafted chair at your office.
If the precise dimensions, repeatabilty and warranty is your only constraint, you can be proud of factory products...
If you want a custom made chair that fits you, a different story altogether. And then there are museum pieces.
off-topic intensifies...
one of those things is not like the others...
warranties
where have you seen such a thing? There are no warrnaties on any software, commercial or otherwise, even when the client is a big enterpice or a freaking government we still go "no warranty of course, why yes, of course", like the absolute clowns that we are. If waranties actually becoma a thing we all can finally stop complaining that you can't make money on free software, and maybe concider starting a real local businesses serving the general public, providing software design, installation, confoguration and WARRANTY
so what I'm saying is that your artworks are not restricted to your garage only because of the overall sorry state of the industry. A transformer you wound can be better than the one in your phone charger only if said charger came without warranty. Software insdusty is an extreme case of that where there is nothing but marketing driving it
@namark, 'warranty' was mentioned by you!
makes a lot of sense for our snake oil industry that hinges on marketing alone, where warranty is unheard of, and everything is expected to break all the time.
I don't think we are disagreement.
I may be more focused on the craft than completed product at any cost
Warranty, license, insurance and union walls have not yet been erected. Soon, with AI help desk requirements.
nah we don't agree
tldr on this off topic:
I say warranty good - you say warranty bad;
you say corporate want warranty, I say corporate hate warranty
reminder how this connects to OP:
no warranty - no quality;
no quality - anything goes;
anything goes - most things are shit;
most things are shit - your hand rolled cruft doesn't look that bad anymore;
your had rolled cruft doesn't look that bad anymore - you can keep hand rolling same cruft over and over again and feel important;
you can keep hand rolling same cruft over and over again feel important - design patterns
My penultimate OT remark here:
@namark, I tried to keep it civil. We do not have to agree on everything, and I tried pretty hard to communicate something that is important to me personally without actual personal insults.
If you want to think of my life's work as 'hand-rolled cruft' that is there 'to make me feel important', that is your choice. Verbalizing it as you have: another choice and speaks to your character.
I am bully-proof; I feel sorry that you are so insecure that you need to resort to ad hominem insults.
lol dude, next you gonna tell me you weren't even ironic calling youself maestro? Massive ego go brrrrrr
Imma clarify that I was talking about everyone and their granmas who ever wrote any code, not you in partciular, in case admin decides to pull out the banhammer over your tear jerking last words.
Brah, just to clarify: I am dead serious. A lifetime of coding compilers and other deep tech. If there is such a thing as a Master Programmer, I am it (for some kinds of code). Not ashamed to tell the truth.
And to reiterate: hostile tone and personal insults are not necessary or appreciated. Look up the definition of ad hominem
🍀 gritty [OP] · Feb 26 at 02:14:
Soooo...
how about that weather? snow gone yet in NYC?
anyways, what I got out of all this, on topic, is that in general, it's good to know what patterns are but you don't crowbar them into your code without good reason. I appreciate the (mostly) good content and explanations here. thanks to all.