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

121–130 of 158 posts

Re: Patterns.dev

#121

Post by Yokohiii »

palata wrote: post #103
berkes wrote: post #101

Earlier quoted context omitted.

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

I have mixed feelings about this.

I think Julian Assange once said he would refer to things in discussion just as "Tomato" (or similar), in discussion to have a shortcut for something unnamed with some meaning. We do this all day in programming, we give a complex component a name and it means a lot more then just the actual word. The problem is that this specific meaning is often not universal, it's contextual.

If you take a hammer, an integer and design patterns, the latter is the least universal thing. They depend on domain, context and conventions, and can change quite a lot depending on the language. Removing hammers and integers from the world would cause collapse, removing design patterns would do almost nothing.

I guess the active celebration of design patterns as a catalogue of general wisdom is my primary issue here. I'd welcome any project/team/company that maintains a catalogue of their individual "patterns". But a universal source of truth has too much bible flavor to me. (Oh it also dictates OOP by default which renders it's inherent "wisdom" completely useless in many languages)

Re: Patterns.dev

#122

Post by gcau »

arscan wrote: post #109
threetonesun wrote: post #94

Earlier quoted context omitted.

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.

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.

Re: Patterns.dev

#123

Post by actionfromafar »

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."

"Javascript" === "Chaotic neutral lisp"

Re: Patterns.dev

#124

Post by mrsmrtss »

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.

How do optional inheritance and namespaces (which you can ignore to use a single global namespace) make a language inflexible? If anything, these traits make your language more powerful, not less.

Re: Patterns.dev

#125

Post by moron4hire »

actionfromafar wrote: post #123
moron4hire wrote: post #118

Earlier quoted context omitted.

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."

"Javascript" === "Chaotic neutral lisp"

Yeah, I don't like the comparisons of JS to Lisp, because I think they mostly center on the existance of the map and filter methods of Array. To me, that's just not what Lisp is about. C# has map/filter/etc, and we don't say C# is-a Lisp.

And there are many other such features that were once unique/unique-ish to Lisp, that were major selling points for using Lisp at the time, but are now pretty common across a very diverse set of languages. Garbage collection being one. Higher order functions being another.

Lisp's big idea that stuck to being unique to Lisp is homoiconicity. It's the one thing that continues to be valuable enough to warrant using Lisp, despite everything else that has been stolen and copied.

Of course, not that I ever used Common Lisp, and not that I use Racket anymore. I enjoyed the hell out of programming in Racket. Up until the point I needed to access a database. Man, who's got time for that Jankasarous Rex? But I really would love a homoiconic language for the .NET CLR. That would be pretty sweet.

Re: Patterns.dev

#126

Post by vips7L »

zelphirkalt wrote: post #111
viraptor wrote: post #62

Earlier quoted context omitted.

I wouldn't say it's cringe. A factory is a factory. Calling it that in the code may not be the best idea, but having the shared vocabulary is nice. Basically, patterns work well when they're descriptive rather than prescriptive. There are two cases that are unique though: state machines and visitors are so much things on their own, that you'll use those names almost every time you run into the pattern.

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?

Re: Patterns.dev

#127

Post by vips7L »

Kwpolska wrote: post #108
microtherion wrote: post #72

Earlier quoted context omitted.

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

Funny part is that Java does have named parameters, but only for annotations!

Re: Patterns.dev

#128

Post by no_wizard »

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."

>You can only just barely figure out what is in an object

There's a couple really well documented and understood ways of doing this in the language. I'm not sure what you're specifically referencing without more information.

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

Is this anymore different than .NET deriving everything from a base `System.Object`[0] type?

Also, what is missing in JS reflection wise that you can't do that would make sense for its environment? (namely, this excludes compile time reflection stuff I know .NET can do, it wouldn't make sense for a scripting language as it currently is)

[0]: https://learn.microsoft.com/en-us/dotnet/api/system.object?v...

Re: Patterns.dev

#129

Post by socalgal2 »

actionfromafar wrote: post #123
moron4hire wrote: post #118

Earlier quoted context omitted.

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."

"Javascript" === "Chaotic neutral lisp"

lisp to me is (1) the language itself is a lists of lists (2) defmacro lets you manipulate those lists of list at compile time. JS doesn't this do either of these at all AFAICT and so is absolutely nothing like lisp.

Most lisp programs are about writing DSLs using defmacro.

What's the similarity to lisp except that both are programming languages?

Re: Patterns.dev

#130

Post by moron4hire »

no_wizard wrote: post #128
moron4hire wrote: post #118

Earlier quoted context omitted.

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."

>You can only just barely figure out what is in an object There's a couple really well documented and understood ways of doing this in the language. I'm not sure what you're specifically referencing without more information. >I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps." Is this anymore different than .NET deriving everything from a base `Syste…

In JavaScript, one can tell if an object has a method by iterating over the object keys and seeing if the value is `instanceof Function`.

But that actually tells you very little. You might be able to tell that it takes a certain number of parameters, if you are running on a system that implements Function.prototype.length. But you will have no way of telling what the arguments to those parameters should be, or even what they were even named. There's no way to tell if the function is a method that needs to be `.call()`ed with a value for "this", or if it's just a function that happens to live in an object literal, or if it's actually a class constructor that must be called with `new`! And there is certainly no way to tell whether the function returns a value, say nothing about the type of value it returns.

With .NET reflection, I can do ask those things I lament missing in JS, and guarantee the type safeness of it.

Post reply on HN