表象と切り離したプログラミングの本質、ってのがあったとしても、人間が書くプログラミングでは表象もめちゃ重要だよなー。
Rubyの「驚き最小の法則」とか、Rustが強調するergonomics とかは、どっちも表象レベルで人間にとっての扱いやすさを目的にしてる
ランプが横に10個並んでいて、ランプそれぞれの手前にひとつづつシーソースイッチがあったとして、一番左のスイッチは、一番左のランプに対応するであろう みたいなのも論理的制約かも><
その上で、各シーソースイッチのうち、奥側に倒されているものに近いランプが点灯し、手前に倒されているものは消灯していたら、奥が点灯であり手前が消灯であると多くの人が推定するかも><
全てのランプが消灯し、全てのスイッチが奥になっていたら、点灯は手前であると解釈する人の方が多いかも><
(シーソースイッチを知らない文化圏の人であっても、1:1でスイッチがある事の法則性に気づけば、「それをどうにかすれば変化する」と、対応に気づける程度の多くの文化圏であればたぶん気づけるかも?><)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索 - http://app.m-cocolog.jp/t/typecast/50463/49479/87341399
> ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
> したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
単3乾電池の電池ボックスも多くの場合物理的制約による直感的・・・かつその失敗によるエラーを起こさせたり、それを減らすために図示によって、正しい向きでセットさせるデザインであることが多いかも><
電池の+極の突起を使って、逆には填まらないようにしたり、ちょっと微妙なのでも逆につっこんだ場合に電極に触れないようにしたり><
電池ボックスそのものがビジュアルに逆方向の取り付けを防止する形状が分かりにくい時には、取り付け部の底に、向きがわかるように図があったりする><
これは、電池をそこに取り付ける必要があるとだけわかっていれば、それ以上の知識がなくとも物理的制約により正しく取り付けられる可能性があると言える><
これはある程度直感的なデザインと言えるかも><