Complexity
4つの原因
状態
制御
ifなどの制御構文
プログラムサイズ
巨大になると把握できなくなる
プログラミング言語ができることが多い
例えば、状態を扱えるとか
複雑さとは、ソフトウェアシステムの構造に関連するもので、システムを理解し変更することを困難にするものです
ただ単に大きいシステムのことを指すわけではない
大きくても理解しやすければ複雑ではない
複雑さの定義をしている
$ C =\sum_p{c_pt_p}
システムの全体的な複雑さ（C）は、
各部分 p の複雑さ（$ c_p）と
開発者がその部分に費やす時間の割合（$ t_p）
によって決定される
複雑さと戦うための2つのアプローチ
コードをシンプルで明白にして複雑さを排除する
カプセル化する
$ t_pを減らす
複雑なものが一箇所に存在していて、普段の作業時に意識しない状態になっていれば問題にならない
複雑に感じる
単純に概念の数が多いパターン
数が多すぎてそれらの関係性を一望できない
一望できたとして、頭の中にロードできない
状態が多い
時間を意識する必要がある分、考慮が難しい
そもそも状態を減らす、
制御(分岐)が多い
ルールを見直すとか？
具体的なルールが多すぎることが問題？
これはあまり感じてないので体験した具体例がぱっと浮かばないmrsekut.icon
できることが多い
機能を制約する
Interfaceを制限して口をしぼめる
DSLを使ってできることを減らす
そもそも機能を減らす
多いと頭に入らなくなって、ふくざつだぁ〜になる
結局、量なのかmrsekut.icon
量が多ければ認知の範囲を超えて「複雑だ」と感じる
頭にロードする工夫が必要
あるいはそもそもロードしなくても目的を果たせるようにする
Scrapboxとかはそれ
目的のものが見つかれば良いだけなのでロードする必要はない
統一的な構造が広く使われていると理解が容易になる
なんかの機能を作るときに共通のinterfaceを持っているとか
例えば検索機能を作るときに、A,B,Cで検索できるが、どれも同じ実装の見た目をしているとか
Haskellも言語全体でそれが行き渡っている
知らん型に、FunctorやTraversableなど、一般的な型クラスが実装されていれば、それの使い方の推測がつく
更に良いことに、同じ関数の使い回しで使える
コードを読むときの手がかりが増えるというか、
記述量をそもそも減らせるというか、
まあ、「関数を作る」がやっていることも同じではあるか
上記の「量が多い」があったとしても、内部の構造が大体似通っていたらそこまでしんどくない