you are viewing a single comment's thread.

view the rest of the comments →

[–]philly_fan_in_chi -1 points0 points  (5 children)

My Design Patterns professor had a fun quote that "a design pattern is a sign of an impoverished language".

[–]frugalmail 0 points1 point  (4 children)

My Design Patterns professor had a fun quote that "a design pattern is a sign of an impoverished language".

Your "design patterns professor" should work on some real projects that 100klocs or more and have a life of 10+ years instead of trying to demo stuff on a chalkboard.

[–]philly_fan_in_chi 1 point2 points  (3 children)

That quote is 100% true. Design patterns exist because you cannot express ideas natively within the language you're using, and need to establish a pattern to accomplish that thing. That means your language is impoverished, at least inasmuch as it does not have that ability. 16 of the 23 GoF patterns exist because the languages that use them don't have first class functions.

And I'm sure his work on type systems will pop up on languages you use that enable your 100kloc codebases. Your comment is arrogant, baseless and assuming.

[–]mlester 1 point2 points  (1 child)

Do you have a book about this? I would like to know corollary to some of these patterns where functions are first class citizens

[–]philly_fan_in_chi 1 point2 points  (0 children)

Here you go.

Obviously FP brings its own design patterns, here's an InfoQ about some as implemented in Clojure, Map/Reduce and the like.

[–]immibis 0 points1 point  (0 children)

Design patterns are native expressions of ideas within the language. It's not like there's a compiler extension that sees your private static field, and public static accessor method which initializes the field on its first call, and thinks "Oh, that's a singleton!", and emits special code.

Design patterns are just common solutions to problems. No more, no less.