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

141–150 of 158 posts

Re: Patterns.dev

#141

Post by arscan »

kbolino wrote: post #131
gcau wrote: post #122

Earlier quoted context omitted.

The poster you're replying to is plain wrong, using "class" is ubiquitously common in the javascript/typescript world, it's the idiomatic way to create classes, and it has better semantics than trying to use prototypes. You might compile away the class keyword for compatibility, though.

But you don't have to do either of those things. There's a third way, with functions and bare objects. I'm not sure that's what GP meant, but a lot of the JS I've written (which tends to be for the browser, mostly vanilla, and quick-and-dirty, to be fair) never touches classes or prototypes. The JSON data being produced/consumed is just a bag of fields, the operations on the document are just top-level functions, eve…

Yeah, I would do a lot with plain objects, and using closures and iifes to do encapsulation and what-not. It was ugly and a bit of a pain, but once you learned how it all worked it made sense and was doable. I felt that classes were a bit of a bolt-on that violated my own internal understanding of how JavaScript worked, but by that point I was moving on to other stuff so never really got used to it.

Re: Patterns.dev

#142

Post by thunderfork »

gcau wrote: post #122
arscan wrote: post #109

Earlier quoted context omitted.

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.

The poster you're replying to is plain wrong, using "class" is ubiquitously common in the javascript/typescript world, it's the idiomatic way to create classes, and it has better semantics than trying to use prototypes. You might compile away the class keyword for compatibility, though.

I think the real sign of this is a class where all the members are static, or pure data classes - ie, classes as a default rather than classes for things where classes make sense

Re: Patterns.dev

#143

Post by crabmusket »

spopejoy wrote: post #139
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…

If you're trying to connect Alexander to software patterns like GOF, it's important to include Gabriel's "Patterns of Software" [1] as the first genuine attempt to apply Alexandrian patterns to software. It also introduces the first and probably the best takedown of OO inheritance as not reuse but instead a form of _compression_ that is in many ways worse than just copy-and-paste. 1 - https://www.dreamsongs.com/Files…

This looks great! I am diving right into the yak of producing a HTML version of this.

Re: Patterns.dev

#144

Post by zelphirkalt »

vips7L wrote: post #126
zelphirkalt wrote: post #111

Earlier quoted context omitted.

The visitor pattern is my go to example for patterns, that you don't really need, when you have a language that has first class functions, which implies among other things, that you can pass functions as arguments, like you can pass anything else. The magical "visitor" pattern becomes nothing more than simple callback passing or passing a function, which is one of the most natural things to do in a modern programming…

I've always seen the visitor pattern as a poor-mans pattern matching. How do you solve the same thing with callbacks?

Instead of defining a Visitor interface and then making objects to implement the interface and then passing those objects to whatever traverses a graph or iterates through something, you pass the function, that will be called, by whatever traverses a graph or iterates through something.

Re: Patterns.dev

#145

Post by liampulles »

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.

I went from Java to Go for my last job. I think there is a reduction in pattern stuff but there are still many (at least in my project).

Java is kind of "begging" for patterns IMO, with all its static package protected final stuff and beliefs around encapsulation. Go is plainer, which is to its benefit.

Re: Patterns.dev

#146

Post by palata »

Yokohiii wrote: post #136
palata wrote: post #132

Earlier quoted context omitted.

I feel like we're talking past each other. I tend to agree with you, I don't like having a "bible" and "celebration of design patterns as a catalogue of general wisdom". But formalising concepts with words makes sense. If your company maintains a catalogue of their patterns, and someone happens to know that this specific pattern is usually called a "singleton", I would find it weird to call it a tomato. Some patterns…

Well I guess I am not clear enough. Naming stuff is a normal human habit, maybe even why we have language? So we can agree on that, it's helpful. But you say it yourself, a thing is called different in another language, so the thing is bigger then the word. But everyone can handle it better in his own head and in communication with a word for it. I guess my usual grief is that any kind of excessive celebration and ce…

I don't mind the celebration and ceremony as long as they don't bother me personally. I wouldn't fight against the existance of a PatternConf, I just wouldn't go :-).

I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their newly-learned concept and the hierarchy doesn't allow me to prevent them from doing it, anyway they will do it. So instead of fighting I just let them, and if it turns out to be a waste of time in the end... well that's not my problem: I was not in a position to prevent it in the first place.

It's not only patterns though: some juniors have a way to try to use every exciting framework or library or tool they just discovered.

Re: Patterns.dev

#148

Post by Yokohiii »

palata wrote: post #146
Yokohiii wrote: post #136

Earlier quoted context omitted.

Well I guess I am not clear enough. Naming stuff is a normal human habit, maybe even why we have language? So we can agree on that, it's helpful. But you say it yourself, a thing is called different in another language, so the thing is bigger then the word. But everyone can handle it better in his own head and in communication with a word for it. I guess my usual grief is that any kind of excessive celebration and ce…

I don't mind the celebration and ceremony as long as they don't bother me personally. I wouldn't fight against the existance of a PatternConf, I just wouldn't go :-). I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their ne…

The silly thing is that I've been the same when I started. A high energy kid playing around and celebrating everything fresh and new, with a big ego.

Probably a bad habit trying to stop them, they need to learn walking before they can sprint. The question is always how to put limits on them? I say it's overengineered, they say it's modern code and I am old. So what do you do if they send you a PR that is just plain wrong? I mean it seems like you delay the conflict from upfront design/planning to pull requests.

Re: Patterns.dev

#149

Post by vips7L »

zelphirkalt wrote: post #144
vips7L wrote: post #126

Earlier quoted context omitted.

I've always seen the visitor pattern as a poor-mans pattern matching. How do you solve the same thing with callbacks?

Instead of defining a Visitor interface and then making objects to implement the interface and then passing those objects to whatever traverses a graph or iterates through something, you pass the function, that will be called, by whatever traverses a graph or iterates through something.

Kind of like how sum types and matching are implemented in library code? Example from D here:

    Fahrenheit toFahrenheit(Temperature t)
    {
        return Fahrenheit(
            t.match!(
                (Fahrenheit f) => f.degrees,
                (Celsius c) => c.degrees * 9.0/5 + 32,
                (Kelvin k) => k.degrees * 9.0/5 - 459.4
            )
        );
    }

Re: Patterns.dev

#150

Post by palata »

Yokohiii wrote: post #148
palata wrote: post #146

Earlier quoted context omitted.

I don't mind the celebration and ceremony as long as they don't bother me personally. I wouldn't fight against the existance of a PatternConf, I just wouldn't go :-). I've had some debates with junior devs who really wanted to enforce their newly-learned patterns, and my experience there is that passed a certain point, there is no convincing anymore: if they really insist about overengineering something with their ne…

The silly thing is that I've been the same when I started. A high energy kid playing around and celebrating everything fresh and new, with a big ego. Probably a bad habit trying to stop them, they need to learn walking before they can sprint. The question is always how to put limits on them? I say it's overengineered, they say it's modern code and I am old. So what do you do if they send you a PR that is just plain w…

I have been in two different situations:

* Functional teams (established companies): enough seniors are here to tell the juniors when they are wrong, and the juniors naturally accept the criticism because it's expected in that environment.

* Dysfunctional teams (startups): most devs are juniors anyway, there is no clear hierarchy, managers are still at their first job so they have never seen a functioning team or had a competent manager themselves.

In the second case, there was absolutely no way I could win an argument: the "high energy kids with big egos" never believed me, I was the "old guy" as you mention. I remember an example where the "kid" failed and gave up with their "right" way after 3 months and I solved it in 3 days, exactly how I had suggested they did it in the first place. Next discussion, nothing had changed, they still knew better.

I can't really blame them, because the whole environment was like this. Everybody was always right, knew better, etc, even though it was their first job.

What I've learned is to protect myself and move away from that. Either by changing job, or by changing project. In startups I have been pretty successful at saying "I can help with this project if we do it this way, but if we do it that way, I can't help and I will work on something else". Of course it meant that I could not work on the most exciting project, but they made a mess out of them, so all in all I feel it was better working on my boring, stable, maintainable components.

Post reply on HN