Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

8
  • 2
    Personally, I somehow really like this idea. But then, code should be readable by humans and people like patterns. Patterns help us finding our way around. Removing all patterns from our code will make it unreadable. Commented Nov 13, 2016 at 11:58
  • 2
    @Frank I think where PG is coming from is that a pattern is a 'smell' of an underlying function that you can abstract, & the fact that you haven't pulled it out into a function or macro is what's causing the repetition ― like if you didn't have a String.replace function, you could imagine it popping up as a pattern, but better to write it once rather than continuing to reimplement it. Agree that if you don't name these things properly it would make it harder to read, but when it's done right, code reads more declaratively IMO (e.g. the getOrElse style of option monads vs null checking) Commented Nov 13, 2016 at 13:21
  • 12
    Paul Graham's quote was about keeping your solutions DRY, which is different from the GoF "pattern" idea. The GoF idea was about giving names to commonly used solutions. We already were doing that long before the GoF published their book. For example, I can tell my co-worker that I'm going to use a queue, and my co-worker immediately knows what I'm talking about without my having to explain the details of what a queue does or how it works. But, see Michael Borgwardt's excellent answer, above. Commented Nov 13, 2016 at 19:46
  • 10
    In my opinion, this answer misunderstands what patterns are. A design pattern is an often encountered solution to a common problem. It isn't some code duplication. Say, take an iterator. You solve the problem of abstracting away the container so you can go through the elements inside it regardless of what the container is. Thus you create an iterator class which does that for each of your containers and make them implement a common interface. What's to abstract here? An iterator already is an abstraction. And, of course, it's implemented differently for all containers, so no code duplication. Commented Nov 14, 2016 at 9:10
  • 3
    The key part of Graham's quote is often that I'm generating by hand the expansions of some macro that I need to write. This references Lisp macros specifically. There is only so much abstraction one can do without macros. Commented Nov 14, 2016 at 12:43