
Design Patterns in Dynamic Programming (1996) [pdf] - tosh
http://norvig.com/design-patterns/design-patterns.pdf
======
wwweston
Key takeaway point: "Dynamic Languages have fewer language limitations, less
need for bookkeeping objects and classes, less need to get around class-
restricted design. Study of the Design Patterns book: 16 of 23 patterns have
qualitatively simpler implementation."

Or as someone else once put it, "design patterns" might more accurately be
called something like "palliative idioms for pain points in static manifestly
typed class-oriented languages."

That's a little bit unfair, given Smalltalk's place in all this, but one of
the wastes of time over the last 20 years has been the ways in which some
dynamic languages cargo-culted practices from, say, the Java world because
Design Patterns™ were The Mark of A Professional™.

The fact this happened in JavaScript with Angular is particularly atrocious.

~~~
neilv
FWIW, the gang-of-four patterns book was a good idea. And still would've been,
even if people were using crazy-powerful dynamic languages like Lisps instead
of C++ (though the examples would've been very different, and then some would
seem odd to include).

One way to look at the patterns book is that it communicated a bunch of
software architectural patterns that a developer might learn over many years
of reading code others had written, and writing their own code. Suddenly, a
new programmer could recognize and use those patterns immediately.

Of course, at the time, it wasn't lost on the people who knew a bunch of OO
analysis and design methodologies and programming languages, that there was
heavy C++ bias to the exact patterns included. And we started to make comments
like Norvig did here. But design patterns and the book were a good idea.

Also, I was just a kid developer at the time, but, when the book first came
out, I recall one of the principal engineers was looking into how patterns
might be used for _documenting_ large, well-engineered OO systems.

~~~
erokar
The point Norvig makes is that these patterns have emerged to mitigate
shortcomings/lack of expressiveness in languages like e.g. C++ and Java.
Expressive, dynamic languages lack these limitations and thus there simply is
no need for most of these patterns.

~~~
neilv
But some of them (we won't speak of Singleton) are patterns that are helpful
in conceiving of and understanding architectures or how the implementation
language is used, even if an instance of the pattern looks like a very simple
expression in the implementation language?

------
neilv
The title might be confusing today: today, the title might instead say simply
_dynamic languages_ , rather than the _dynamic programming_ that makes people
think of current coding interview customs.

~~~
adenadel
I was looking forward to reading Peter Norvig's writing on dynamic programming
:(

~~~
neilv
I was looking forward to blaming Peter Norvig for the current software
developer interview theatre shibboleth. :)

------
tosh
pg in
[http://www.paulgraham.com/icad.html](http://www.paulgraham.com/icad.html)
(via
[http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures](http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures))

> This practice is not only common, but institutionalized. For example, in the
> OO world you hear a good deal about "patterns". I wonder if these patterns
> are not sometimes evidence of case (c), the human compiler, at work. When I
> see patterns in my programs, I consider it a sign of trouble. The shape of a
> program should reflect only the problem it needs to solve. Any other
> regularity in the code is a sign, to me at least, that I'm using
> abstractions that aren't powerful enough-- often that I'm generating by hand
> the expansions of some macro that I need to write.

~~~
xtracto
For me, patterns define ways how you put language constructs units together to
solve typical "higher-level" problems. For example, "how do I implement an
undo mechanism". Of course for static/object-oriented languages, the patterns
will be different than for dynamic languages.

I am currently listening to the Software-Engineer Radio Podcast from
2006/2007, and they talk heavily about patterns. Even though the POSA books
patterns may not be applicable to dynamic languages like Ruby or JavaScript, I
think the right idea is to define new patterns that are useful for these type
of languages.

Maybe one reason why we don't have this is because nowadays to solve a more
"specific" problem the only thing you need to do is to install some third
party library from github that already does it? (like if I wanted to implement
an undo-redo fucntionality I will use maybe this:
[https://www.npmjs.com/package/undo-redo](https://www.npmjs.com/package/undo-
redo) )

------
dang
A thread from 2010:
[https://news.ycombinator.com/item?id=1059822](https://news.ycombinator.com/item?id=1059822)

------
sampo
This is about dynamically typed languages, not dynamic programming the
mathematical optimization method.

~~~
gitgud
Yes, I was initially confused too. Maybe the term "Dynamic Programming" wasn't
a popular phrase back in 1996?

------
timClicks
I never knew that Norvig worked at Harlequin and was a Dylan advocate

------
asimpletune
I thought this was about dynamic programming. Maybe the title should be
changed?

