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

151–158 of 158 posts

Re: Patterns.dev

#151

Post by naasking »

moron4hire wrote: post #118
naasking wrote: post #107

Earlier quoted context omitted.

Yes and no. Some patterns exist because the language isn't expressive enough. This is one reason why the patterns made sense in the OP's .NET programs, but made less sense in JS. JS simply doesn't require as much ceremony for some things because it's dynamically typed and reflection kind of comes for free.

I would say that reflection in JS is terrible compared to .NET. You can only just barely figure out what is in an object , but it's a hell of a time figuring out what any of those things can do. I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

> I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

I used "reflection" because that's how it's abstracted in popular statically typed languages. My point was that JS has abstractions and idioms that eliminate some of the need for design patterns like, factory, decorator, strategy, etc., and some of the reasons are because JS's core objects are basically just fancy hashmaps.

Re: Patterns.dev

#153

Post by salutis »

viraptor wrote: post #61
TINJ wrote: post #58

Earlier quoted context omitted.

> 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…

No, dynamic programming is when you split your bigger problem into a smaller one + 1 step to get to your bigger size. Then apply that recursively until you solve the trivial problem at the end and get back the answer for your original problem size.

No, that is plain old recursion. Dynamic programming is recursive programming with a twist. The twist is that identical sub-problems are short-circuited with memoization.

Re: Patterns.dev

#154

Post by rglynn »

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…

I agree with the first half as it echoes my experience, but the second half hasn't been my exp.

To talk about design patterns as not as useful, only to then mention big O notation seems strange to me unless you are in a context where performance is critical?

Worrying about O(n) IME is far less important than choosing the right architectural pattern. O(n) issues are usually observable via metrics or QA and are typically straightforward to fix. By contrast, recognising that your pattern choice is wrong is harder (since it manifests during dev rather than in prod) and takes more effort to rectify.

I also disagree that patterns don't deserve a name. I have found it very useful when discussing with both seniors and juniors to have a common name for a pattern being described. Seniors known instantly and it can be helpful to have a resource to point juniors to if they aren't familiar. I have also found it useful when English isn't the first language.

I do agree that seniors don't typically try to fit standard patterns to their problem in a way that a junior might, that's a fair point.

Re: Patterns.dev

#155

Post by rglynn »

Yokohiii wrote: post #80
palata wrote: post #57

Earlier quoted context omitted.

I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it. Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous. Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you shoul…

You point out the cultural issue that this creates and sweep it under the rug, violently. The thought model complicates the process of writing new code, "what pattern do i need here?" and the perception of existing code, "oh this is pattern X, why isn't that communicated clearly?". The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity an…

> The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity and quality of problems is infinite.

I think once you have spent enough time in a software space, nothing is really new under the sun. That's why I think the GoF has aged well (controversial opinion I know!).

Re: Patterns.dev

#156

Post by socketcluster »

Yokohiii wrote: post #80
palata wrote: post #57

Earlier quoted context omitted.

I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it. Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous. Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you shoul…

You point out the cultural issue that this creates and sweep it under the rug, violently. The thought model complicates the process of writing new code, "what pattern do i need here?" and the perception of existing code, "oh this is pattern X, why isn't that communicated clearly?". The truth is that design patterns are at best stagnant in quality and quantity over time (GoF is over 30 years old!), but the quantity an…

This is a good point, nowadays I always try to account for human psychology. Like a tool might be a positive in some way but maybe it will have a negative impact on people's morale and it might end up being a negative.

Or some tool makes it easier to write code safely, but in doing so, it encourages people to architect their code in a certain over-complicated way and it ends up being a net negative.

Re: Patterns.dev

#157

Post by socketcluster »

agumonkey wrote: post #49
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.

I think the problem is that people will never agree about the same definitions when discussing complex topics. For example, even when it comes to testing, I find that developers tend to disagree about definitions of 'Unit tests' vs 'Integration tests' vs 'End to end tests'. Some people will insist that a unit test should stub out all the dependencies and if you're testing a module and it invokes some internal sub-module (not mocked), they will insist that it's an integration test... Some people will say it's only an end-to-end test if it includes the front-end as well; other will say that if the test involves interaction with the database or other IO operations; then it can be called e2e.

There are a surprising number of topics; not only in engineering, but in day-to-day life as well, that we tend to think we all understand and have consensus about, but in reality nobody agrees on the same thing and there is no real consensus.

People tend to form consensus over labels; not over concepts. They may fully agree over labels but actually fundamentally disagree over the underlying concepts; they only realize this once they start defining their interpretation of the terms.

Re: Patterns.dev

#158

Post by dominicrose »

css_apologist wrote: post #105
dominicrose wrote: post #99

Earlier quoted context omitted.

I've used Clojure/Script in the past and it's good to enforce working with immutable data. Immutable.js has similar data structures but it's not the standard way of doing things and uglier to debug. Using standard objects, immutability is not enforced in JS and throwing a few Object.freeze calls won't change that so we lose half the benefits that Clojure would bring: parallel/concurrent programming benefits, easier d…

I've used these things. IME, nowadays it's not worth the bundle size to bring in these libraries. map/filter seems quite optimized, {...obj} is fast since its only shallow. Yes it does come down to practices vs better libraries, but in practice, it's fine IME One thing to note, i was very excited that we have a bunch of lazy methods on Iterator protocol, but they are slow as shit as of earlier this year. I wrote a pa…

I think the goal of lazy iterations is to make less iterations, not to make iterations themselves faster.
Post reply on HN