_ [言語] Substroke Design Dump前にも書いたような気がするけど、 私は「ビジュアル言語」に対して否定的だ。
ここでいう「ビジュアル言語」とは、 「Microsoft Visual 〜」な言語のことではなくて、 グラフィカルな表現でプログラムを表現しようという試みのこと。 一番成功した(でも、普通の人はやっぱり知らない)のはPrographかなあ。
しかし、もしかしたらこのSubstrokeは意味のある試みかもしれないと思った。
Substrokeは「ビジュアル(画像など目に見えるもの)を操作する言語」だから。
そもそもアルゴリズムという「形のないもの」にむりやり形を与える ビジュアル言語はそれにより想像力を限定してしまうという弱点がある。 また、2次元の表現は1次元の表現よりも高解像度を要求する(ので、一度に視野に入れられる情報量が少ない) のも欠点である。要するにスケールしないのだ。 サンプルでは良くても実用プログラムを書くのは別問題ということ。
しかし、ビジュアルを操作するのであれば、操作するものと表現が一致するわけで、 想像力が限定されるという問題はそもそも発生しない。 むしろ、直接的に操作できるというメリットになる。
とはいえ、ある程度以上複雑な「プログラム」には やはりアルゴリズムやプロセスなど「目に見えない部分」が入り込んでくることは 避けられないわけで、そこをこの「ビジュアル言語」がどう避けるか、 というのは興味がある。
_ [言語] A programming language cannot be better without being unintuitive「プログラムはわかりにくさがあるくらいでなければ良いものではない」という話。 Rubyのモットー(と呼ばれていた)「Principle of Least Surprise」の真逆であるが。
まずは、Scalaのプログラムから。
(0/:l)(_+_)
なんか、私がメールのシグネチャにつけている似顔絵(と呼べるのか)であるところの 「/:|)」に似ているような気もするけど、これは立派なScalaのプログラムである。
これをもって「だからScalaはダメなんだ」という結論を出すのは早急すぎる。 これらは確かにわざわざわかりにくく書いてはあるけど、個別の文法要素は 決して悪いものではない。むしろ、少々びっくりするくらいでないと本当に良い言語ではないのだ。
なぜか。
仮に「Principle of Least Surprise」を完全に満たす言語があったとすると それはどんな言語であるか、ということを考えると、 結局は「慣れ親しんだ言語と同じ」という結論がでる。 つまり、言語による驚きを最小にするためには新しい言語を学ばなければよいのだ。
しかし、実際には新しい何かを達成するために新しい言語は次々と生まれる。 その「新しい何か」を達成する部分は、誰も知らないのでそれを学ぶ人には 目新しく、驚きの源になるに違いない。
驚きもないような言語は学ぶ価値もない。
もっとも、言語設計には「不必要な驚き」とか、「新しすぎて受け入れられない言語」とかも 存在するので、結局はバランスなわけなのだが。
時間に余裕のある人はJef Raskin on "Intuitive Interfaces"も参照のこと。
_ [OSS] McAfee throws some FUD at the GPL - The INQUIRERMcAfeeがGPLに対するFUDを行ったという話。
In its annual report, Windows security software vendor McAfee told its investors that open source software licence terms it vaguely characterised as " ambiguous" might "result in unanticipated obligations regarding our products."
投資家に対する年次報告においてMcAfeeは以下のように報告した。 「オープンソースソフトウェアの曖昧な性質によって、我々のプロダクトに予期しない義務が発生する可能性がある」
"To the extent that we use 'open source' software, we face risks," McAfee stated.
「オープンソースソフトウェアの利用によって、我々はリスクに直面している」
裏は取っていないけど、これが真実であるとしたら、かなりひどい話。 McAfeeに対して不買運動を始めたくなるくらい。もっとも、もともとMcAfee製品なんて使ってないか。
この記事では、McAfeeの真の動機は、 オープンソースソフトウェア(特にLinux)の台頭により、 (McAfeeがビジネス的に依存している)Windowsの没落することに危機感を覚えたのではないかと 推測している。
確かに、Linuxではウィルスなどの危険性はWindowsよりずっとマシだし(ない、とは言わない)、 そうなればMcAfeeのビジネス規模は相当縮小するだろうな。
This work is licensed under a Creative Commons License.
「目に見えるもの」を操作するビジュアルなグラフ表現ということであれば、プロダクション用のコンポジティングソフトや、3Dオブジェクトを操作するものなど、実用になっているものがありますね。プロのコンポジターやモデラーはかなり複雑なものまで作り込みます (コンポジティングだとノードが数十とか。モデリングではパーツ数によって増えるので数百ノードとか)。<br><br>ただ、これらはDAGなので、複雑度は線形に増えるだけで、だからこそ扱えているのかもしれません。cycleを導入したりATNのように再帰を導入した場合にもユーザーが使いこなせるかどうかは不明です。
たとえば、Yahoo!Pipeはビジュアル言語に含まれますか?<br>(条件分岐もループもないから駄目かな…)
一番メジャーなビジュアル言語は、LEGO MindStormのやつでは?言語名は知りません。
自分の見える範囲で一番良く使われているビジュアル言語(?)はLabViewですね。その次はAVSとかOpenDX。
「回路図」はビジュアル言語のうちに入るのかしら?
音楽用途ですがビジュアル言語といえば<br>MAX/MSPは外せないでしょう。
LabVIEWが普及数と実用性でぬきんでているのでは?<br>実験測定・データ処理で頻繁に使われています。<br>「アルゴリズムやプロセスなど『目に見えない部分』」に関してはLabVIEWはあらかじめ主要なアルゴリズムを部品として提供することで対処しています。<br>既知のアルゴリズムを自分で実装し直す意味はないですからね。
あと、複雑で大規模になったときにはサブルーチンを部品化して隠蔽して使うというごく普通の言語でも行う手法で解決してます。<br>オーバーヘッドは近年のCPUリソースからは気にならないです。<br><br>あとビジュアルプログラミングの最大のメリットはデバッグの容易さです。<br>プログラムの進行を可視化して内部の変数や状態遷移を表示させて追跡することが容易で直感的です。<br>私は実験用途に使ってますがデバッグの容易さのために非常に開発速度が速いです。
thorさま<br>>ビジュアルプログラミングの最大のメリットはデバッグの容易さ<br><br>判ってる人が使う分には良いですが、時々データフローを分岐させて個別に処理してから合わせる動作を記述すると、きちんと同期を取らないと動作が不定になり「デバッガでならちゃんと動いてる!」とかいう輩が後を絶たなかったり他にも(ry<br><br>…一見容易に見えてしまうというのはもはや罠としか
>データフローを分岐させて個別に処理してから合わせる動作を記述すると、きちんと同期を取らないと動作が不定になり「デバッガでならちゃんと動いてる!」とかいう輩が後を絶たなかったり<br><br>そーゆー人が入ってくることが想定されるので、開発環境にモデル検査器を統合するとか必須になってくる気が。
>判ってる人が使う分には良いですが、時々データフローを分岐させて個別に処理してから合わせる動作を記述すると、きちんと同期を取らないと動作が不定になり「デバッガでならちゃんと動いてる!」とかいう輩が後を絶たなかったり他にも(ry<br><br>同期はとるのがすごく簡単なんですよ。<br>「シーケンシャルストラクチャ」という「枠を並べたor重ねた図形」<br>がありまして、その枠の中の処理が全て終わらないと次の枠の処理に手をつけないようになってます。なので同期するべきところで適宜枠の区切りを入れるだけで同期完了です。