Patterns of software
In Patterns of Software, the respected software pioneer and computer scientist, Richard P. Gabriel, gives us an informative inside look at the world of software design and computer programming and the businesses that surround them. In this wide-ranging volume, Gabriel discusses such topics as what makes a successful programming language, how the rest of the world looks at and responds to the work of computer scientists, how he first became involved in computer programming and software development, what makes a successful software business, and why his own company, Lucid, failed in 1994, ten years after its inception. Perhaps the most interesting and enlightening section of the book is Gabriel's detailed look at what he believes are the lessons that can be learned from architect Christopher Alexander, whose books - including the seminal A Pattern Language - have had a profound influence on the computer programming community.
Stats for nerds
31recommend
70mentions
40people
2007–2026years
70% recommend27% neutral3% critical
Mentions per year
What Hacker News says
- If you're trying to connect Alexander to software patterns like GOF, it's important to include Gabriel's "Patterns of Software" [1] as the first genuine attempt to apply Alexandrian patterns to software. It also introduces the first and probably the best takedown of OO inheritance as not reuse but instead a form of _compression_ that is in many ways worse than just copy-and-paste.
- I don't think you're missing much. Yeah, the main point seems to be that if your language has closures, you suddenly can express a lot of things that were out of reach before. Not a new insight. But there's another point I think that is hinted at on the topic of control abstractions. Or at least I'm reminded of the topic. It's better and more succinctly and explicitly talked about in an early chapter of the free book Patterns of Software: https://dreamsongs.com/Files/PatternsOfSoftware.pdf
The extra point might be that more languages should facilitate defining your own control abstractions just as they support defining your own data abstractions. Functions are one way of making data abstractions, but languages often provide multiple ways. Closures are one way of doing a type of control abstraction (involving such things as delayed or multiple evaluation), but there are other ways too. For some reason we see value and a need for defining our own data abstractions, but not so much for control abstractions, even though (according to the book) once they were often co-designed, like Fortran's arrays and DO loop. And for some reason even in the few languages that do support making your own control abstractions, like Lisp, you'll still find users who disapprove of doing so, claiming all you need are the standard existing methods like looping, map/reduce style functions, and some non-local exits.
- > Functional programming can express patterns just as well as OOP.
No! Patterns are just crutches for missing language features or "design patterns are bug reports against your programming language." GoF patterns are concepts useful in OOP, but the recurring patterns and architectures you see in other paradigms are totally different. And they don't apply to Lisp: https://www.norvig.com/design-patterns/ Most don't even apply in Go: https://alexalejandre.com/programming/software-architecture-...
> visitor is type switching, singleton global variables, command and strategy are first class functions with closures, state is building a state machine with first class functions
If you could perfectly compress your code, repeated patterns would be factored away. Macros do this. In Lisp, when you find a pattern, you write code which generates that pattern, so you don't have to.
https://mishadoff.com/blog/clojure-design-patterns/
> if patterns are discovered, arise out of independently invented idioms
Yes. That's the point behind Christopher Alexander's pattern concept - he found architectural patterns which seemed to promote good social habits, happiness etc. Gabriel's Patterns of Software presents this far better than GoF. I strongly suggest you read it: https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
- I would also recommend 'Patterns of Software' by Richard Gabriel. In one of the chapters he discusses how Christopher Alexander's work can be applied to software and argues that GoF interpretation of 'pattern language' totally misses the point.
- You might enjoy the insights in Richard Gabriel's book Patterns of Software.
- Richard Gabriel's book Patterns of Software has some good insights, but it's not a how-to manual.
Related
Software architecture
1 recommend · 6
Design Patterns
95 recommend · 491
2021–2025
Understanding Software Dynamics
6 recommend · 8
2009–2026
The psychology of computer programming
44 recommend · 122
The art of computer programming
336 recommend · 1,799
Software tools
21 recommend · 44
Elements of programming
recommend · 58
