Gauche > Archives > 2010/10/20

2010/10/20 00:07:48 UTCshiro
#
こないだここであったbetter editorの話に関連するかもしれないような話。アーティストの使うツールはどんどん進化してるのに IDEWTF http://lukepalmer.wordpress.com/2010/10/18/idewtf/
#
途中で送っちゃった。「アーティストの使うツールはどんどん進化してるのに(MayaとかPhotoshopとか)、プログラマの使うツールの進化がそれにマッチしてないんじゃない」って話
#
しかしひとつのシーンデータをある人はMayaで、ある人はXSIでいじりたい、なんてことはないからなあ。
2010/10/20 00:36:22 UTCとおる。
#
すこしまえまで MAX で毎日悲鳴を上げてる人がまわりにたくさんいましたが、Maya に移行してだいぶ静かになりました(笑)。
#
でも、Visual Studio も 2008 で静的なコード解析機能を標準で搭載したり、2010 でかなり強力なコード補完機能がついたとか聞くので(自分では使ってないですが)、進化は相当しているんじゃないですかね。
2010/10/20 01:25:25 UTCshiro
#
それはあるでしょうね。greatest common denominatorとしてのテキスト形式、っていうのをキープするかどうかってのは別の問題としてあるかも。文法としてXMLを採用した言語がいくつかあったけど、ああいうのは高機能な構造化エディタ前提で人間が直接テキストに触らないってつもりだったんだろうが実際エディットしやすかったんだろうか。
#
Javaな人はantのbuild.xmlとかはやっぱり構造化エディタ使うのかな? プレインテキストの設定ファイル(e.g. Makefile)よりも編集しやすい/しにくい、って評価はあるんだろうか。
2010/10/20 01:37:57 UTCeyasuyuki@twitter
#
最近AndroidとAppEngineしかやっていないのでAntでビルドするとかやらなくなっちゃいました。設定類のXMLは直接編集してエラーだけ修正する感じかな。
2010/10/20 01:40:08 UTCshiro
#
XMLを直接見せない編集ツールもあるんですよね? 直接編集するのは手軽さ?
2010/10/20 01:44:58 UTCeyasuyuki@twitter
#
要素の入れ子構造はEclipseのエディタが補完してくれるので直接編集した方が手軽なんです。AndroidのEclipseプラグインにはLayout等を編集できるテンプレートがあるけど、それは初心者向けという意味合いが強くてほとんど使いません。
2010/10/20 01:49:59 UTCeyasuyuki@twitter
#
AppEngineに関してはSlim3を使えばソースコードにアノテーションを書くだけでDatastore関連ソースを自動生成してくれるので、モデルを書いてテストを書いてロジックを書くような感じでXMLを触らずに開発できます。
2010/10/20 01:51:06 UTCshiro
#
うむ、その場合は結局テキストが大元のソースになってるわけで、やっぱりテキストなんですよねぇ。
#
テキストって形式が抽象化の境界としてベストである理由、っていうのは何だろうかなと。「直接触ってる感」はあるんだけれど、それもまたイリュージョンなんだよな。
2010/10/20 01:56:08 UTCeyasuyuki@twitter
#
テキストファイルを編集してるんだけどエディタはソースコードをパーズしていて構造を解釈している状態です。saveした時点でコンパイルされているのでビルド等は意識する必要がありません。
#
人間が言語以外によっては思考することができないからでは。RT : shiro: テキストって形式が抽象化の境界としてベストである理由、っていうのは何だろうかなと。「直接触ってる感」はあるんだけれど、それもまたイリュージョンなんだよな。
2010/10/20 02:07:56 UTCshiro
#
でも例えば3Dシーンのエディットに関しては、有向グラフを編集する方が直感的だ > 人間が言語以外によっては思考することができないからでは。
#
名前付けの問題かな。3Dシーンの場合、有向グラフのノードはたいてい、対応するオブジェクトが3Dのシーン中にあり、それと対応してユーザの頭の中にもある。ユーザは3Dのビューの対応するオブジェクトを選択することでグラフの特定のノードにアクセスできる。
#
プログラムはグラフではあるけれどもっとずっと抽象的で、具体的なマッピングをつくるよりも名前をつけて管理した方が扱いやすい、とか。
#
前に増井俊之さんとちょっと話したんだけど、私はプログラムが木に見えてるのでS式の方が直感的だといったら、増井さんはそうではない(テキストとして考えてる、だったかな)ってことで、プログラマ間でも脳内モデルがかなり違ってて、落としどころはテキストしかないのかも、という可能性もある。
2010/10/20 02:26:51 UTCとおる。
#
まえ Gauche のイベントで、プログラムは言葉で記述することは本質的に重要なことみたいなことを黒田さんが言ってませんでしたっけ? ただ、言葉であることと「テキスト」であることは、必ずしも同義でないと思いますが。
2010/10/20 02:31:08 UTCshiro
#
言葉=シンボルをルールによって構造化したもの、と考えるなら、MayaのDAGだって広義の言葉と言えなくはないんですよね。
2010/10/20 02:40:10 UTCeyasuyuki@twitter
#
音声言語は思考にとって本質的なものだけど、書き言葉は後から獲得する外部化された思考だからなあ。
2010/10/20 02:43:00 UTCshiro
#
先天性聾者は手話が母語になるので、「音声」であることが本質ではないと思うけど、書き言葉にワンクッション入ってるってのはあるかなあ。
2010/10/20 03:03:42 UTCnobsun
#
書かれたものは消えないけれど,音声や手話のように時系列に乗っているものはどんどん消えてしまうという違いは結構大きいとおもう.
2010/10/20 03:09:45 UTCnobsun
#
時系列にのって消えてしまうものの全体を把握するには,記憶を辿って,事象を記号化して,描かれた様子を想像するしかないような気がする.
#
音楽なんかはそうじゃないですか?スコアにするから全体の構造が見えてくるということはないのかしらん?
2010/10/20 03:25:22 UTCnfunato@twitter
#
増井さんやy佐藤さん@産総研と昔ご一緒しましたが、テキストの入出力を大事にする的考え方は理解できます。お二人ともパーサ生成器とか作成経験があって、必要なら脳内変換が苦にならないかも。佐藤さんのCOSMOSとかC言語用のLisp環境みたいですが
2010/10/20 03:40:20 UTCnobsun
#
プログラムを木として把握するのは,独立した複数の事象が並行してあるから.
#
1次元のテキストとして把握するのは,計算機上の動作として事象を理解するから.
#
かな.