Live data from Hacker News

Patterns.dev

patterns.dev

131–140 of 158 posts

Re: Patterns.dev

#131
post #122
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.

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, events get handled in callback closures, responses to HTTP requests get handled with promises, etc. Sprinkle in some JSDoc comments and you even get fairly workable autocomplete suggestions. Of course, the web APIs are built on prototypes/classes, so it's not like they're totally absent. But with things like data attributes, querySelector, and HTML templates, the usual needs for my own code to be OOP (or even structs-with-methods a la Go/Rust) just don't emerge that much.

Re: Patterns.dev

#132
post #103

Earlier quoted context omitted.

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

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 have different names in different contexts or languages, and that's fine. I don't find it weird to have a discussion around "in this language there is this pattern that they call X, does that ring a bell for you working on that other language? The idea is [...]", and maybe the answer is "yep we have it too" or "oh, we call that Y, but that's pretty similar".

Re: Patterns.dev

#133

Earlier quoted context omitted.

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

Let me ask you instead, do you consider there to exist any Lisp which has no compiler?

Re: Patterns.dev

#134

Earlier quoted context omitted.

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

Well put.

Re: Patterns.dev

#135
post #122
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'm not denying the existence of class in JavaScript, but at least from what I've seen when React went to functions so did most of the JavaScript community that had moved to class based syntax, except for those who worked with Java/C# as well.

Re: Patterns.dev

#136
post #132

Earlier quoted context omitted.

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

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 ceremony comes down to some kind of brainwash. Which mostly affects newbies and cultists. The article for example isn't overtly critical on singletons, while past design pattern writings often heavily disregarded the use of it. So we don't just always reiterate the good, but also the bad.

Re: Patterns.dev

#137

Earlier quoted context omitted.

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

Isn't this just a fundamental limitation of dynamic typing?

Re: Patterns.dev

#138
post #76

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…

> Very useful pattern but I don't believe it has a name. This is an instance of “use the right data structure for the job”. To me it has little to do with architectural design (where design patterns live), but it has to do with algorithmic design.

This is the thrust of much of the excellent "Algorithm Design Manual" by Skiena -- choosing the right data structure to model your problem can take you 95% of the way toward the best solution.

Re: Patterns.dev

#139

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/PatternsOfSoftware.pdf

Re: Patterns.dev

#140

Earlier quoted context omitted.

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

Isn't this just a fundamental limitation of dynamic typing?

Most of it is not. Most of the data necessary to support reflection should be available to the runtime or else it wouldn't be able to operate. The runtime is parsing the syntax of the function, it should be able to tell if all exit conditions have a return of any kind. It should be able to tell me at least the names of the parameters. It should know if a function is bound to a "this", or of it's a constructor. It just doesn't give any way to tell me.
Post reply on HN