Live data from Hacker News

Design Patterns Are Temporary, Language Features Are Forever

ptrtojoel.dev

31–40 of 67 posts

Re: Design Patterns Are Temporary, Language Features Are Forever

#31
Anyone who is interested in pattern matching and the visitor pattern (and the benefits of various encodings of state and behavior) who hasn't seen them should check out:

* Li Haoyi's Zero-Overhead Tree Processing with the Visitor Pattern (https://www.lihaoyi.com/post/ZeroOverheadTreeProcessingwitht...)

* Noel Welsh's Uniting Church and State: FP and OO Together (https://noelwelsh.com/posts/uniting-church-and-state/ or https://www.youtube.com/watch?v=IO5MD62dQbI is you like video)

* Bruno C. d. S. Oliveira and William R. Cook's Extensibility for the Masses Practical Extensibility with Object Algebras (https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf)

Re: Design Patterns Are Temporary, Language Features Are Forever

#32
This reminds me of when I was still in university. During our compilers course we used the "Modern Compiler Implementation in Java" book. Because I was really into FP at the time, I instead used the "Modern Compiler Implementation in ML" version of this book (which was the original, the Java and C versions were made to make it more accessible). We noticed during the course that my version was missing a whole chapter on visitors, likely because ML's pattern matching made this kind off trivial.

One of the other students made a similar remark, that software design patterns are sometimes failures of the language when they have no concise way of expressing these kinds of concepts.

Re: Design Patterns Are Temporary, Language Features Are Forever

#33
I got about halfway before completely losing the thread as I had no idea what was being said, unfortunately.

Is "visitor" pattern ever defined in this article?

Is there anything in this article explaining the assertion "Design Patterns Are Temporary, Language Features Are Forever"? I couldn't penetrate the specific example being discussed.

Re: Design Patterns Are Temporary, Language Features Are Forever

#34
Language features are not forever.

Language features can be deprecated as obsolescent and after a period of obsolescence, removed.

"implicit int" declarations are no longer a C language feature. The (void) parameter list is now obsolescent; as of C23, () means the same thing as (void), like in C++.

Design patterns can end up in libraries. But library and language features are the same. A popular library which everyone uses cannot be thrown out overnight any more than a language feature.

Re: Design Patterns Are Temporary, Language Features Are Forever

#36

Language features are not forever. Language features can be deprecated as obsolescent and after a period of obsolescence, removed. "implicit int" declarations are no longer a C language feature. The (void) parameter list is now obsolescent; as of C23, () means the same thing as (void), like in C++. Design patterns can end up in libraries. But library and language features are the same. A popular library which everyon…

[deleted]

Re: Design Patterns Are Temporary, Language Features Are Forever

#37

Earlier quoted context omitted.

Object-oriented order and elegance compared to an object-infested mess of special cases and complications. Remember that 25 years ago C++ wasn't a pleasant place and Design Patterns was an impressive step forward.

Oh, I do remember the grim story really well. I was there. I still have all the books. And the scars. Back then I was a young innocent programming soul trying to reconcile C++ and GoF and UML and all that. And Modern C++ Design. And const here const there const copy constructor by reference. Anyway. I like vanilla C. And Go at times.

I spent about 12 years doing C++ at the very peak of its OOP hype and did the same... then finally left, certain that I would hate doing "real" work in any other language, and a funny thing happened...

I realized I was suffering from severe Stockholm Syndrome. Node.js was just.... so gd easy to do anything in. Maybe too easy (a la leftpad), but build/deploy cycles were instantaneous, adding new libraries was easy- again maybe too easy, JS has a tiny fraction of the footguns and you don't have to know them all to write code that isn't going to blow up on you or cause memory leaks and performance issues.

Python... was the same. I have even taken some dives into Java, and while I don't love the architectural monuments Java devs tend to produce, its still less of a hassle than C++.

I was so happy when there was a move towards templates and data oriented design and the priests of OOP were getting knocked off their pedestals- for a period you were at risk of getting shunned for not kneeling at the gods of OOP and the GOF book and UML diagrams.

Re: Design Patterns Are Temporary, Language Features Are Forever

#38
post #33

I got about halfway before completely losing the thread as I had no idea what was being said, unfortunately. Is "visitor" pattern ever defined in this article? Is there anything in this article explaining the assertion "Design Patterns Are Temporary, Language Features Are Forever"? I couldn't penetrate the specific example being discussed.

This is an article about design patterns (in particular the 1994-200x craze for them after the Gang of Four book was published). Having emerged from that era might be table stakes for understanding this article.

Visitor pattern is a code inversion where inheritance and/or function overloading fills in for a missing language feature (concise runtime pattern matching on types). It has its pros and cons but seemed like opening your third eye circa 1995.

Re: Design Patterns Are Temporary, Language Features Are Forever

#39
The author took the thesis in one direction, but there's another interesting way to think of it.

C++ is an epitaph for every discarded concept in OO design. Diamond inheritance, generics to a fault, operator overloading to a fault, the richness of STL types. Those "patterns" are dead, but the language features must continue to be supported.

Re: Design Patterns Are Temporary, Language Features Are Forever

#40
I always tell people who obsess over design patterns as clean code and good coding practices to remember that design patterns often indicate a lack of language features.

For example, are you using a Builder? Would you use the Builder pattern if the language had named variables in arguments?

My favorite reference on the topic is Peter Norvig's "Design Patterns in Dynamic Languages" (1996!) https://www.norvig.com/design-patterns/

Post reply on HN