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

101–110 of 158 posts

Re: Patterns.dev

#101

Post by berkes »

palata wrote: post #92
Yokohiii wrote: post #80

Earlier quoted context omitted.

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…

I did not mean "everybody has to learn the vocabulary". I meant the opposite, actually: it's fine not to know the word for the tool (I don't enjoy reading about patterns just to learn about patterns, it's not my thing at all). Say I build a tool that makes it easier for me to drive a nail and call it a "Naildriver". If I show it to a colleague, they may be able to tell me "oh, this is generally called a hammer!". May…

The other thing that design patterns allow, is to learn pitfalls, applications and other attributes about them.

To keep in your analogy, if you have a 3KG naildriver with a 2m handle you'll quickly find out that driving nails into a drywall with that leaves you with no wall. And that it's a bad idea to use a "Naildriver" to drive these "spiralled-slothead-nails" (aka screws) into wood.

But with a common language, such as design patterns, you can easily learn where they are good, what their limits are, in what cases other patterns fit better, and what pitfalls to avoid and so on.

If I search the web for "why is it so hard for my naildriver to drive in spiralled-slothead-nails" I'll get zero results. But when I search for "why is it hard to hammer in a screw" I'll get good results. May sound like a silly example, but for me that sillyness illustrates how obvious designpatters should be.

Re: Patterns.dev

#103

Post by palata »

berkes wrote: post #101
palata wrote: post #92

Earlier quoted context omitted.

I did not mean "everybody has to learn the vocabulary". I meant the opposite, actually: it's fine not to know the word for the tool (I don't enjoy reading about patterns just to learn about patterns, it's not my thing at all). Say I build a tool that makes it easier for me to drive a nail and call it a "Naildriver". If I show it to a colleague, they may be able to tell me "oh, this is generally called a hammer!". May…

The other thing that design patterns allow, is to learn pitfalls, applications and other attributes about them. To keep in your analogy, if you have a 3KG naildriver with a 2m handle you'll quickly find out that driving nails into a drywall with that leaves you with no wall. And that it's a bad idea to use a "Naildriver" to drive these "spiralled-slothead-nails" (aka screws) into wood. But with a common language, suc…

I totally agree with that!

And it doesn't mean at all that everybody should learn the whole encyclopedia of tools by heart. But having it formalised somewhere is useful: as soon as someone tells me "what you're trying to do sounds like this design pattern", I can start searching and reading about it.

Of course if that someone tells me "you suck, you should know that there is a design pattern for that because you should read about design patterns every night before you go to sleep", it will be different :-).

Re: Patterns.dev

#104

Post by ssrc »

skydhash wrote: post #81
emaro wrote: post #79

Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used. Now I'm working on an old…

A lot of patterns only make sense in languages like C# or Java, which are inflexible by design. You have two hierarchical trees (inheritance and namespaces) that you have to work around. With something simpler like C, Go, JavaScript, you don’t have those obstacles and a solution can be way simpler to implement.

Some patterns in the GoF book only apply to C++/Java as they were in 1994, but I don't see any reason why other languages would have no useful patterns. The Linux kernel (C) is full of patterns for example.

Funny thing, Peter Norvig also has this position, that patterns only apply to languages like Java, but his book on Lisp and the Python course he had on Udemy (?) are super-pattern-y.

Re: Patterns.dev

#105

Post by css_apologist »

dominicrose wrote: post #99
css_apologist wrote: post #89

this site reads like its 2017 its low quality, breadth but no depth more important is to deeply understand the basics of working with immutable data. try writing applications with no for loops or forEach (and actually use the array methods as they are intended), no cloneDeep hacks and obviously no direct property mutation, always create a new object. in real world you still use for loops plenty, but as a junior its g…

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 parser a year ago with extreme use of .map (every step of processing was cloning the tokens), and i thought, let's migrate it to lazy iterator - it got ~10x slower :(. The compile time was fine for my use cases, so i didn't give immutable-js a try, but it was a surprise

I did some benchmarks on map+filter vs mutable for of + push, and on firefox up to 200-300 elements map+filter is actually faster (unforunately not on chrome).

Of course, its not the best, but my experience is that modern js engines are fast enough for most use cases to not have to bring in any libraries anymore

Re: Patterns.dev

#106

Post by daxfohl »

emaro wrote: post #79

Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used. Now I'm working on an old…

Yeah, I've seen (okay, and been responsible for) a lot of "the road to hell is paved with good intentions" due to jumping to some pattern or other because, well, it feels like the right thing to do. It makes the code cleaner at delivery time, and is usually very intuitive when the design is fresh in your mind. But IME it doesn't take long before that freshness goes away, and the next time you look at it (let alone anyone else) you find it hard to follow the logic anymore. Usually "constructing" the pattern and "executing" the pattern are in different places in the code, and there's not a straightforward way to mentally step through one without continually cross-referencing the other. At some point you wish you'd just written one long switch block that you could step through.

And that's all before new requirements that break the pattern, or other engineers that don't have time to grok the design and hack in something that looks like a switch block for their thing, which eventually takes over most of the code anyway.

Re: Patterns.dev

#107

Post by naasking »

layer8 wrote: post #93
emaro wrote: post #79

Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used. Now I'm working on an old…

I would put it slightly differently: Patterns (including anti-patterns) happen whether you call them such or not. Any developer will sooner or later come up with patterns like Adapter or Builder or Composite or Iterator. In that sense, patterns are not invented, but discovered. The benefit of design patterns is to be able to communicate these discovered patterns, and to define agreed names for them, so that you don't…

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.

Re: Patterns.dev

#108

Post by Kwpolska »

microtherion wrote: post #72
Kwpolska wrote: post #54

Earlier quoted context omitted.

I've read that book, and it felt very childish and condescending. Design patterns cannot be applied in every language. While some patterns are applicable everywhere, many of them provide replacements for missing language features. For example, the Builder pattern is not very useful in languages with default parameters and named arguments.

I'm not sure what Builder would have to do with default parameters and named arguments. Builder is extremely useful to pair with a parser, e.g. SAX. The parser parses the input, and the builder then decides what to do with it.

Here is an example of the Builder pattern that illustrates my point: https://www.baeldung.com/java-builder-pattern#bd-classic-bui...

Let’s remove the category argument and you get this:

    Post post = new Post.Builder()
      .title("Java Builder Pattern")
      .text("Explaining how to implement the Builder Pattern in Java")
      .build();
This builder is a more readable alternative to this:

    Post post = new Post("Java Builder Pattern", "Explaining how to implement the Builder Pattern in Java", null);
But if Java supported named arguments and default values (the default would be null), this could just be:

    Post post = new Post(title: "Java Builder Pattern", text: "Explaining how to implement the Builder Pattern in Java");

Re: Patterns.dev

#109

Post by arscan »

threetonesun wrote: post #94
jonkoops wrote: post #82

Earlier quoted context omitted.

This is a common thing I see when developers that come from an OOP enterprise environment familiar with Java, C#, etc. do JavaScript, they try to use all the same patterns, default to classes for everything. It just doesn't fit the language.

It was fascinating to me to see JavaScript add the class keyword, have it be widely adopted thanks to React, then just a few years later seeing `class` in JavaScript code is, as you said, a clear sign a Java/C# dev was here.

I haven’t done JavaScript in a long while, is using ‘class’ not a favored way of writing JS these days? I wrote JS heavily pre-class, and never really got comfortable using it before switching my focus to other languages.

Re: Patterns.dev

#110

Post by sureglymop »

DHRicoF wrote: post #67
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 your example, if both lists are small enough, the constant factor on the cost of creating the hashmap eliminates any advantage you could have. Anyway, it's not like most places were I've seen a nested loop used for search the developer had cared. Today I am in a bad mood. I have to touch some of the most unnerving modules in a legacy project and everything is a trap. Lot's of similar repeated code with ugly patte…

Don't kill yourself. Stop and leave. Every day you will build up a tiny bit more resentment and then first you will become more cynical but eventually you will burn out. Be proactive and leave this behind, move on with life.
Post reply on HN