3 ms·

I think patterns are stupid idea. You bother learning a way of doing things (the pattern), and you bother all you colleagues learning that way of doing things.

I think patterns are stupid idea. You bother learning a way of doing things (the pattern), and you bother all you colleagues learning that way of doing things. OK, cool, that sounds good. But you never bother to teach it the computer! The computer should understand the pattern as well, in form of some abstraction. Because now you force yourself and others to recognize pattern every time you need to use it (either read or write it in the code). That's ridiculous. In some languages, patterns are commonly expressed via macros. Instead of learning patterns, you learn set of macros. That way, even computer understands those patterns and it is clearly obvious from the code what pattern was used, you don't have to translate code back to patterns. But the macros are not the only way to do it.

mbrock 12y ago
Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" in his 1996 book Patterns of Software [1]. To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern. As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better. [1]: https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
- asgard1024 12y ago
  Thanks, didn't know the book, looks like an interesting read. However, I think when you program the pattern you have already instantiated it, anyway. At least when you used it several times throughout your program. In those cases I think it's then better to explicitly abstract it away (i.e. tell the computer you are using the pattern).
- malisper 12y ago
  > Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" I think patterns should always be "abstracted and instantiated". I always found his example of actual code in support of his argument a bit weird. From the book: Does the following code fragment: (mismatch sequence list :from-end t :start1 20 :start2 40 :end1 120 :end2 140 :test #’baz) seem easier to understand than this pattern of use: (let ((subseq1 (reverse (subseq sequence 20 120))) (subseq2 (reverse (subseq list 40 140)))) (flet ((the-same (x y) (baz x y))) (loop for index upfrom 0 as item1 in subseq1 as item2 in subseq2 finally (return t) do (unless (the-same item1 item2) (return index))))) Gabriel then goes on to argue that the advantages of the first one (that it is more efficient and more compact) go away once faster computers and good editors are thrown into the mix. I completely disagree with this. Just try to figure out what test is being used in the second example. The first example clearly says: :test #'baz That tells me that the test is baz. In the second example, there is no such indication. You have to actually parse the entire piece code to figure out where the test is. This makes a huge difference not only in reading code, but also in debugging code. There are many more things that could go wrong in the second piece of code than in the first. If there was a bug in both examples, it would be much easier to find it in the first example since there is so much less of it. This is just like Hoare's saying, "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it". In the first example there are obviously no bugs since the code is so simple. In the second, it is much harder to tell since there are so many more things going on than in the first.
  - mbrock 12y ago
    I wouldn't claim conclusively that the second version is better, but I see Gabriel's point. Yes, the first version is elegant, and it is easier to spot the predicate—but I also can't tell you exactly how the predicate is used, because I don't know the definition of MISMATCH. For example, should a positive result from BAZ mean that the items are the same? There's no way to tell. You could argue that this is because of poor keyword argument naming, but that's part of the point: in the second version, there's no need for such considerations, because the use is explicit. (Consider yourself lucky that the function uses keyword arguments to begin with!) Nor do I agree that the first example is obviously bug-free. How would I know? The definition of the actual logic is in some other file. Yes, that's true for the library functions used in the second example, but those are standardized. Other examples of ambiguities: Are START1 etc counted from the end of the list or from the beginning? What happens if there are several mismatches? What's the time complexity? Etc. Of course these would be part of the documentation, in an ideal world. I should point out that Gabriel isn't arguing that patterns should not be abstracted (or "compressed"), only that there are tradeoffs.

mbrock 12y ago

Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" in his 1996 book Patterns of Software [1]. To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern. As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better. [1]: https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

asgard1024 12y ago
Thanks, didn't know the book, looks like an interesting read. However, I think when you program the pattern you have already instantiated it, anyway. At least when you used it several times throughout your program. In those cases I think it's then better to explicitly abstract it away (i.e. tell the computer you are using the pattern).
malisper 12y ago
> Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" I think patterns should always be "abstracted and instantiated". I always found his example of actual code in support of his argument a bit weird. From the book: Does the following code fragment: (mismatch sequence list :from-end t :start1 20 :start2 40 :end1 120 :end2 140 :test #’baz) seem easier to understand than this pattern of use: (let ((subseq1 (reverse (subseq sequence 20 120))) (subseq2 (reverse (subseq list 40 140)))) (flet ((the-same (x y) (baz x y))) (loop for index upfrom 0 as item1 in subseq1 as item2 in subseq2 finally (return t) do (unless (the-same item1 item2) (return index))))) Gabriel then goes on to argue that the advantages of the first one (that it is more efficient and more compact) go away once faster computers and good editors are thrown into the mix. I completely disagree with this. Just try to figure out what test is being used in the second example. The first example clearly says: :test #'baz That tells me that the test is baz. In the second example, there is no such indication. You have to actually parse the entire piece code to figure out where the test is. This makes a huge difference not only in reading code, but also in debugging code. There are many more things that could go wrong in the second piece of code than in the first. If there was a bug in both examples, it would be much easier to find it in the first example since there is so much less of it. This is just like Hoare's saying, "There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it". In the first example there are obviously no bugs since the code is so simple. In the second, it is much harder to tell since there are so many more things going on than in the first.
- mbrock 12y ago
  I wouldn't claim conclusively that the second version is better, but I see Gabriel's point. Yes, the first version is elegant, and it is easier to spot the predicate—but I also can't tell you exactly how the predicate is used, because I don't know the definition of MISMATCH. For example, should a positive result from BAZ mean that the items are the same? There's no way to tell. You could argue that this is because of poor keyword argument naming, but that's part of the point: in the second version, there's no need for such considerations, because the use is explicit. (Consider yourself lucky that the function uses keyword arguments to begin with!) Nor do I agree that the first example is obviously bug-free. How would I know? The definition of the actual logic is in some other file. Yes, that's true for the library functions used in the second example, but those are standardized. Other examples of ambiguities: Are START1 etc counted from the end of the list or from the beginning? What happens if there are several mismatches? What's the time complexity? Etc. Of course these would be part of the documentation, in an ideal world. I should point out that Gabriel isn't arguing that patterns should not be abstracted (or "compressed"), only that there are tradeoffs.