|
|
|
|
|
|
by RangerScience
3391 days ago
|
|
|
Oh, neat! It's always cool when the authors of content pop onto HN (I see from you karma you're new here, welcome!) Yeah - I heard your point when I first read your post, but it took some more time and reading to understand it. It's a good distinction. What I'm not getting is... So you've got a really precise and elegant line between "language" and "library", but it's not clear what the difference is between patterns and.... maybe idioms? attr_accessor, has_many, and carrierwave's mount_uploader (to provide many examples) are all examples of a "pattern" (in the sense of a repeated thing, not a design pattern) in Ruby, but I can't determine what's then in need of "fixing" or what abstraction features could be added to remove the "pattern". |
|
|
You missed the "created: 3246 days ago" bit, then? :-) But you're right that I don't spend much time here - thanks for the welcome!
> it's not clear what the difference is between patterns and.... maybe idioms?
You're right, it's not a clear distinction. But for our purposes, the important point about design patterns is "must be reimplemented from scratch for each use". Have you read the Gang of Four book? Their patterns all require the programmer to define a bunch of new classes from scratch each time the pattern is used. Compare the Decorator pattern (https://en.wikipedia.org/wiki/Decorator_pattern) to Python's decorators - the pattern requires the programmer to create new classes, forward methods, etc, but the Python feature requires the programmer to write one line of code (which then does all the class-creation and method-forwarding under the hood). The Python feature has successfully obviated the need for the pattern. You still need to write the same amount of application-specific business-logic code, but the machine handles all the tedious plumbing for you. Similarly, attr_accessor and has_many handle the tedious plumbing of getters/setters and collections-backed-by-join-queries, respectively. So the necessary abstraction features have already been added, and there's nothing left to fix. An interesting intermediate case is the Iterator pattern in Python (https://en.wikipedia.org/wiki/Iterator_pattern). Python still has explicit iterators, but standardises the interface so library code can make use of user-provided iterators. It also provides a convenient language-level facility for building iterators, using generator syntax. Haskell, arguably, has entirely absorbed iterators into the language, replacing them with lazy lists.
It's worth noting that the key property of Ruby that allows for things like attr_accessor is the ability to add methods and fields to an object or class at runtime, and thus to do so programmatically. Lisp can similarly dispense with a lot of patterns that are necessary in Java, because Lisp has compile-time code generation in the form of macros. Peter Norvig's talk on this is great: http://norvig.com/design-patterns/ppframe.htm