ビジュアルプログラミングの考え方と、テキストプログラミングの違いについて
Nobkzビジュアル言語のことを、「表現力がない」と言われたりして、その今するところがわたしには分からなかった。なぜなら、むしろ、テキスト言語の方が表現力に乏しいと私は思っているからだ。
Nobkzたが、私はそんなことはどうでも良いのだ。どちらが、表現力があるかないかなんてどうでも良い。そんなことよりも、個人的に脳みその使い方が違うように思えるので、そのところが描きたい。
おそらく、その違いが「表現力」に依存してくると思うからだ。
Nobkzテキストプログラミングは、ある意味、シンボリックというか、形式的だ。例えば、GUIをテキストで記述するとき、モデル部と、表示部に分けることが多いし、その方が正しいと思われている。
Nobkzモデルと表示部(実際には、表示のみではなくユーザーが操作も含まれるが)に分けると言う発想は何故正しいのだろうか？
Nobkzモデルとビューやコントローラに分けるという発想そもそも、ドメインロジックに対してのUIは変化しやすいものだと考えられているからだ。変化しやすい部分と、変化しにくい部分を分けておいて、UIの変化にドメインが変更されないようにするというのが、その理由の一つであるように思う。
Nobkzまた、そもそも視覚的なUI操作と、裏側のロジックは同一ではないと考えられているように思う。UIの操作は裏の操作を引き起こすためにきっかけ（イベント）に過ぎないと。そのきっかけから、起こったドメインロジックを通して結果を表示するわけだ。
Nobkzでもこれってつまり、直接操作性を阻害している状況が生まれているように私は思う。UIの操作が直接UIの表示に間接的につながっているからだ。
NobkzGUIのビューで、Mが変化しないのに、Vが変化するというのは、ある意味トポロジーみたいなもので、位相が同じように開発者は考える。しかしながら、Vが変化するというのはユーザにとっては大きな変更だ。そのことを開発者は忘れがちであるように思える。
Nobkzビジュアルプログラミングの話に戻そう。私がViscuitやScratchを書き続けて思ったのが、最初に思ったのは言語的に機能が不足しているのでは？というものであった。しかし、今思えば、テキストプログラミングのやりかたをビジュアルプログラミングに持ってきすぎであったのだ。
Nobkzテキストプログラマはビジュアルな表現を何かしら、UIの部分から分離したがる。だから、分離した結果、複雑な状態やデータ構造を使いたがる。そして複雑な構造を作り出した結果をUIにしたがるのだ。
Nobkzたとえば、テトリスを実装しようとしたとき、に我々は配列構造を使いたがる。ステージの表示を配列に変換して、それを操作したがる。なぜそれをするのだろうか？というと、そもそも配列などのデータ構造はテキストプログラミングにとって有利な構造だからだ。
Nobkzしかしながら、Scratchはそうじゃない。わざわざ、裏側のデータ構造を考えたりせずに、「見たままの状態」をそのままルールで記述するのだ。配列のデータの状況ではなく、そのまま「一列にブロックが並んでいるように見えるとき」を書く。
Nobkz裏側でやっているものもすべて見えるようにするのがScratchのプログラミング肝だと思った。それがビジュアルプログラミングであると思っている。
Nobkzテキストプログラミングがキッチリしているという意見を聞いて、ついったで意見を述べた。