『Out of the Tar Pit』
複雑さについて書かれた論文
ソフトウェアは本質的に複雑だが、複雑さの種類があり、コントロールできる
2006/2/6
66ページある
著者
参考
解説
↓をわざわざ読んだけど、↑この記事でかなり十分、というきもちになった
要点としては
まず、Complexityと呼んでいるものが、大きく分けて2つに分類できるということを意識すること
そして、出来る限りAccidental Complexityを排除すること
そして、残ったComplexity (Essentialと一部のAccidental)の依存関係を調整すること
Abstract
Brooksは、現代のComplexityの殆どがシステムの本質である、と前提しているが、それを批判する
1 Introduction
システムのComplexityの主な要因
状態
コード量
flow of control
OOPもFPも異なるアプローチをしてるが、各々様々な問題がある
OOP, FP, RDBのアイディアを組み合わせる
2 Complexity
複雑さ一般について
『No Silber Bullet』での4つの困難
Compexity
Comformity
?
Changeability
Invisibility
?
あんまり何も言ってない
3 Approaches to Understanding
システムを理解するためのアプローチは2つある
Testing
システムをブラックボックスと捉え、外部から理解する
ある特定の状況でのシステムの振る舞いの結果を確認する
テストに依って達成できることには本質的な限界がある
特定のパターンしか見れないし
より多くのエラーを検出できる
Informal Reasoning
内部からシステムを調査し理解する
エラーの発生を減らすことができる
こちらの方が重要
具体的にどういう操作のこと？
「Informal」なので形式的なものではなく、経験や直観によるシステムの内部分析
ER図等を用いてアーキテクチャを理解する、みたいな感じだろうか
いずれにせよ、両方を併用しても限界があるのでシンプルにすべし、といった結論
4 Causes of Complexity
状態が引き起こす複雑さ
外部から見ても、内部から見ても辛い
前者はテストがつらいこと、後者は可読性が悪いことを言ってる
Controlが引き起こす複雑さ
順序は重要だが、常に必要なわけでもない
↓このようなコードがあるとき、各行は直交してるので並行に実行されても良い
しかし、このコードを読んだ人は、上から順に実行されることを期待する
_a := b + 3
c := d + 2
e := f + 4暗黙的に順序を強制される
Ozは並行に実行されるらしい
コード量が引き起こす複雑さ
他の原因と比べて測定しやすい
他の原因と相互作用が大きい
その他
状態を許可するような言語を使う場合は常にそれに気を配る必要がある
JSだとthrowされる可能性を常に気を配る必要がある感じか
5 Classical approasches to managing complexity
imperative, funcitona, logicでのアプローチ
OOP
状態
OOPのすべての形式は状態に依存しているので、状態に関する問題に悩まされる
複雑さを回避するための適切な基盤を提供できない
FP
状態
状態を完全に排除する言語だと、上述した複雑さの一つを完全に排除できる
Control
暗黙的な順序はあるものの、抽象的な制御を提供してるのでマシ
純粋関数はすべての引数を並列に評価できる
関数の引数を見るだけで制御されるものが分かる
Logical Programming
Prologとかの話
具体例を知らないので全然わからんね
↑この辺は別に読まなくても良い感じだった
↓この辺からがおもしろポイント
6 Accidents and Essence
Brooksが「現代のComplexityの殆どがシステムの本質である」と前提していることに対する批判と深掘りをしている
Brooksを採用すると「複雑なんだ、しゃあないね」となってしまう
そうではなく、更にComplexityを大きく2つに分類した
Accidental Complexityはなくてもシステムを実現できる
したがって、こちら側をきる限り排除することでComplexityを小さくできる
7 Recommended General Approach
理想世界を考えて何がEssentialなのかを分析していく
理想世界には形式化すらない
コンピュータで動かすために最終的に形式が必要になるが、その過程で複雑さが増えないようなものであって欲しい
言語の筋の良さにめちゃくちゃ依存するということだろう
理想のインフラストラクチャで実行されることを想定する
目的だけを記述する宣言的プログラミング的になる
>It is interesting to note that effectively what we have just described is in fact the very essence of declarative programming - i.e. that you need only specify what you require, not how it must be achieved.
理想世界で、その状態が必要なのかどうかを考えて分類する
Data and State
| Data Essentiality | Data Type | Data Mutability | Classification |
| Essential | Input | - | Essential State |
| Essential | Derived | Immutable | Accidental State |
| Essential | Derived | Mutable | Accidental State |
| Accidental | Derived | - | Accidental State |
左のカラムの
Data Essentiality の判断は、informal requirementsに含まれるかどうかで判断している
例えば、ユーザが直接入力するデータはessentialだし、
キャッシュなど要件に含まれないものはAccidental
とにかく、Derivedして作られる状態はAccidental State
Jotaiとかでプログラミングしてると具体例として「あー、あれのことか」というのがイメージしやすいな
曰く、典型的なプログラムには多くのAccidental Stateが含まれており、それによって無駄に複雑化している
ControlはすべてAccidentalである
理想世界では全て0秒で完了する
並行処理が必要とかそういうのはinformal requirementsにも出てこないし
確かにAccidentalなものは省略可能だが、そうすると表現が複雑になってしまうこともある
例えば、ユーザの位置は、初期開始位置とその後の動きから計算できるが、毎度それで計算するのもなあ、という感じ
パフォーマンスの問題もある
複雑さを処理するための推奨事項
避ける
分ける
Types of complexity within a system
| Complexity | Type | Recommendation |
| Essential Logic | Separate | |
| Essential Complexity | State | Spearate |
| Accidental Useful Complexity | State/Control | Separate |
| Accidental Useful Complexity | State/Control | Avoid |
宣言的に書くのがEssentialで、実際の手続きはAccidentalなので、そこも分離すべき、というのは面白い
8 The Relational Model
relational modelについて
9 Funcitional Relational Programming
10 Example of an FRP system
11 Related Work