あれ、1巻だけ読んでウーンとなったので続きは読んでない
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索 - http://app.m-cocolog.jp/t/typecast/50463/49479/87341399
> ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
> したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
そもそもポヨグヤミングに「誰もが理解できる」とこを期待していない(工学の人間としては良くない考えかもわからんけど)
図で表現されていれば無条件に分かりやすい,というような向きもあるけど,それって図も言語であり文法を持っているということろを失念していると思うんだよ.
プログラミングはピクトグラムじゃないのだし,単純な図形で表現できるものではないと思う.
誰のためのデザイン? 増補・改訂版の第3章がだいたいその話だけど、長すぎてどこを引用すればいいのかわからない><;
量子プログラミングは基礎レベルだとビジュアルというかテキストというか、チャートみたいな感じみたいだし、その上で実現されるであろう高レベル言語がどうなるかは全然想像つかないな。まずテキストで作られるだろうが……
現代のプログラミングをできるようにするためのビジュアルプログラミング環境は無駄だと思ってるんだけど、未来においてはわからない。
ただ少なくとも、平面ディスプレイに文字列表示することを超える情報密度と、キーボードを超える入力効率を達成するデバイスが必要だと思う。
これ、「疎か」というのは語弊があって、その環境における非本質的知識というのは身に付くと思うけど、世の中の大半はビジュアルプログラミングではないので、それを役に立てることができないと思うんだよね。ビジュアルプログラミングの方が優勢になればそういった問題はなくなると思うけど……
実際にプログラミングを行うに際して、全然本質的ではないけれども当然に突破しなければならない部分というのは確実にあって、ビジュアルプログラミングはそこが疎かになってしまい、後で壁に当たりやすくなるのではないかという予想をしている。
オレンジのさっきの文脈上のそれは、その言語の作者が勝手に決めた部分以外みたいな意味><
(もちろんScratchとかにもそれらのデザイナが勝手に決めただけの部分もあるけど、ビジュアルだとより切り離しやすい><(この部分を説明しようとすると、ノーマンの本から長文引用しないといけなくなる><;))
私の理解では、「問題を解く」ということを、問題を記号列に翻訳してオートマトンが受理するかどうかということに帰着しておき、チューリングマシンと形式文法の等価性からオートマトンの記述に記号列、すなわちテキストを使うというのがより「本質」に近いだろうという感覚。