Habitable Software
akkartik.name
Habitable Software
1–10 of 11 posts
Re: Habitable Software
#2Re: Habitable Software
#3Maybe software is more like a city. Maybe buildings are more like patterns, data structures, etc.
Re: Habitable Software
#4Extremely modular/functional code can require understanding more separated moving pieces, which may well be scattered to the winds in a zillion different files and combined in clever but counterintuitive ways
Extremely object-oriented code has lots of mutability, inheritance, and encapsulation gotchas that make users of an API less likely to understand what's happening under the hood of some class
Extremely terse code can be difficult to parse the logic out of, extremely verbose code can take forever to read and be hard to hold in your head, extremely abstract code can be hard to parse out how it accomplishes the application, extremely purpose-specific code can be ridiculously idiosyncratic and be hard to separate into digestible pieces, and so on and so forth. I've heard a lot of code organization advice and could keep doing this for hours.
I had a student tell me a personal project's codebase looked like the necronomicon once after an overhaul I made to make it more readable from my perspective
There are sometimes takeaways from all these analogies and policies and just generally opinions about how to write code people can supposedly maintain or modify or read more easily, and I definitely use and take some of them to heart. But most advice is really bad at generalizing, and I often feel that the most readable style of code is whatever one that I prefer and can convince people who work with me on it to prefer (Or, you know, vice versa as the case may be)
Re: Habitable Software
#5The building analogy doesn't work, software is not a building. There are essentially templates for buildings, there is no template for software. Maybe software is more like a city. Maybe buildings are more like patterns, data structures, etc.
[1]: https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
Re: Habitable Software
#6The building analogy doesn't work, software is not a building. There are essentially templates for buildings, there is no template for software. Maybe software is more like a city. Maybe buildings are more like patterns, data structures, etc.
The concept of "pattern" in software is based on Christopher Alexander's concept of "pattern" in architecture, which was introduced to the software community[1] by the same Richard Gabriel the article quotes (though the modern idea of software pattern is quite different, focusing only on details rather than multiple levels of patterns which combine to form a coherent whole). [1]: https://www.dreamsongs.com/Files/Patt…
EDIT: although thanks for reply, it is interesting to know that bit of history / link with architecture.
Re: Habitable Software
#7Re: Habitable Software
#8I'm not sure any specific pattern or structure could possibly be good for all software.
The Design Patterns (GoF) book explicitly has a complete section about "Applicability" for every pattern it discusses, and makes no bones about circumstances where a pattern is not a good fit to a problem. Further, under "Consequences" it discusses (again: for every pattern in the book) negative as well as possible positive consequences of using the pattern. Then in "Implementation" it discusses tradeoffs, gotchas and variations...
The notion of Design Patterns was never intended to be prescriptive nor to suggest inherent "goodness". It was merely an attempt (largely successful, imho) to establish a common vocabulary for software designers, saying, effectively, "Look, lots of people faced with problem X have solved it in this way. Here are some(!) of the considerations, use-cases and tradeoffs, and here are some things you might want to think about, when using this pattern.
Not sure how the notion got so badly screwed up in peoples' minds.
Re: Habitable Software
#9Re: Habitable Software
#10It seems like every few months I read some new way of articulating the idea that code that's hard to maintain and modify is frustrating. Some, like this, don't really pose solutions, some do, but most I think fail to realize that their advice inevitably falls apart in some case Extremely modular/functional code can require understanding more separated moving pieces, which may well be scattered to the winds in a zilli…