3 ms·
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 wit
by layer8 11mo ago
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 have to describe the pattern each time you talk to another developer, but can refer to it by a well-understood name. (Or when not yet well-understood, can refer to the corresponding pattern description.) It extends the language we use to talk about software design.
The point of design patterns is less about the individual patterns, than about having "design pattern" as a general concept of coding patterns relevant to software design, that you name and describe because they keep reoccurring.
- zeroq 11mo agoI would go even further. For me design patterns are more of vocabulary than a tool. It's not about - hey I found this book and we'll be using these building block from now on - rather, it's about having words that everyone immediately recognizes and associate with exact same ideas.
- naasking 11mo agoYes 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.
- moron4hire 11mo agoI 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."
- actionfromafar 11mo ago"Javascript" === "Chaotic neutral lisp"
- moron4hire 11mo agoYeah, 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.
- actionfromafar 11mo agoWell put.
- socalgal2 11mo agolisp 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?
- actionfromafar 11mo agoLet me ask you instead, do you consider there to exist any Lisp which has no compiler?