88 lines
3.6 KiB
Org Mode
88 lines
3.6 KiB
Org Mode
|
#+TITLE: Software Design for Flexibility
|
||
|
#+Author: Yann Esposito
|
||
|
#+Date: [2021-04-03]
|
||
|
|
||
|
- tags :: [[file:2020-06-03--19-49-30Z--programming.org][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.
|