3.7 KiB
Software Design for Flexibility
- tags
- programming
- source
My notes on the book.
Title: Software Design for Flexibility Subtitle: How to Avoid Programming Yourself into a Corner Authors: Chris Hanson & Gerald Jay Sussman
Chapter 1
Page 19
In computer science we are taught that the "correctness" of software is paramount, and that correctness is to be achieved by establishing formal specification of components and systems of componenents and by providing proofs that the specifications of a combination of components are met by the specification of the components and the pattern by which they are combined[^19]. We assert that this discipline makes systems more brittle. In fact to make truly robust systems we must discard such a tight discipline.
[^19]: It is hard, and perhaps impossible, to specify a commplex system. As noted on page 7, it is easy to specify that a chess player must play legal chess, but how would we specify that it plays well? And unlike chess, whose rules do not change, the specifications of mmost system are dynamically changing as the conditions of their usage change. How do we specify an accounting system in the light of rapidly changing tax codes?
Chapter 2
This chapter introduce a notion of code organisation it is name DSL. Domain Specific Language.
The first part was quite difficult to dig into. It uses someting that looks like lost discussion on function arity. While the subjet is quite important to me "combinators" them made it shallow and not that interesting. I was not happy. They lost a lot of energy tacklink the tedious problem of function arities. Coming from Haskell every function only has a single argument and thus makes this issue trivially fixed.
Here they used a quite terrible approach to anotate the arities on a global set hash-map. They also use advanced Scheme functions that can provide the min and max nunber of argument of a function. Let just say, i wasn't really impressed.
They just declared comp and some parallel combinators.
I think they should have probably left the arities details in the appendice.
The second part of this chapter is about generating a composable language to generate clean regular expressions. This one was a lot better. They show how the current implementation of regular expression was generally terrible and provide a nice composable DSL for it. Not something totally new, but it was better than a SQL DSL while similar in spirit.
The third part of this chapter discuss about writing a system for a board game rules. As a non-native English speaker I haven't understood that referee is the English name of the game "les dames". So as they also mention a "generic board game" and mention chess, I was quite confused by the code and choices I saw. So once I understood it. It was a nice example about what not to do while designing a system. They give two pass of the same code. In the first pass, the rules and the executions are mixed together. They explain how to fix this shortcoming and made another pass where they split the system in three parts. A generic "board-game" system, that could be used by most board games. An execution system that would take care of applying rules using the board game system API. And lastly a system to only expres rules that could be used by the previous system. The interesting part being that you can adapt the rules from referee to chess by only changing the rules and not the rest of the code. There are still visible problem with this architecture. But it was a pretty nice introduction to show how composability is kind of preferable than a specialized system.