Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patterns.dev

patterns.dev

Post reply on HN
Print view View original

41–50 of 158 posts

Re: Patterns.dev

#41

Post by crabmusket »

This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc.

In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway").

This is because you can't just take a pattern on its own; it forms part of a larger whole.

Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them.

This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day.

One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh.

*EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.

Re: Patterns.dev

#42

Post by z3t4 »

phplovesong wrote: post #36

When overused these kind of "patterns" always lead to slow and hard to grasp code that is a nightmare to maintain.

My experience is that they are best discovered independently as a way to abstract code, and let them come naturally to solve a problem. So for most things in Dev, if you do something prematurely you might end up with a good solution for a non existing problem.

Re: Patterns.dev

#43

Post by crabmusket »

crabmusket wrote: post #41

This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc. In A Pattern Language , each pattern is hyperlinked to other patterns in a kind of hierarchy, w…

Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine.

---

Short Passages (132)

[Context, or pre-links]

The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131).

[Problem statement]

Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves.

[Pattern contents here]

[Pattern summary]

Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall.

[Elaboration, or post-links]

Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)

Re: Patterns.dev

#44

Post by socketcluster »

I find that the more senior you become, the less you rely on software design patterns.

Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns.

There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems.

In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time.

Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns.

On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.

Re: Patterns.dev

#46

Post by zwnow »

socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

For webdev especially everything I do is basically singletons... For UI state management its just perfect and that's about the hardest thing in web dev. Also easy to recover state with, in a SPA if a user refreshes the site. Or control whether a modal is open or not. Easy to centralize logic too... Never looked into any other patterns as a lot of them seem like bloat.

Re: Patterns.dev

#47

Post by rswail »

Patterns are needed for languages for which the actual underlying concept is unavailable.

For example, prototype pattern is for languages that don't have a way to express interfaces/traits etc as something that can be attached to other language entities.

Re: Patterns.dev

#48

Post by hyfgfh »

socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

Agreed! The problem is that some 'seniors' never cared to learn patterns in the first place. That’s a huge problem for frontend, where we have increasingly complex architectures and people with very little experience with design.

Even some principles aren't known. I always recommend the book Head First: Design Patterns. It's in Java, but the lessons can be applied in every language.

Unfortunately, we are in a 'post-knowledge' era... I don't know how we can keep things up at this pace.

Re: Patterns.dev

#49

Post by agumonkey »

socketcluster wrote: post #44

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more comp…

What about the social / communication aspect ? Having a common vocabulary of pattern may help reduce cognitive load when reading others code. Just a soft opinion because I assume it's the reason frameworks and conventions help teamwork. Less per-context custom solutions.

Re: Patterns.dev

#50

Post by jakubmazanec »

neogodless wrote: post #16
android521 wrote: post #7

The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are: Module Pattern Factory Pattern (factory functions) Mediator / Middleware Pattern (as function pipelines) Hooks Pattern (custom hooks, generalized) Container / Presentational Pattern (implemented with function components + hooks) Everything else is either neutral, UI-only, or fights POSD (Singl…

What does POSD stand for?

I'm assuming John Ousterhout's book A Philosophy of Software Design [1], which I would recommend reading before reading about design patterns, because it's more fundamental.

[1] https://news.ycombinator.com/item?id=37975558

Post reply on HN