Λ-2D：プログラミング言語としてのドローイングの探究
(media.mit.edu)- λ-2D は、絵そのものをコードとする言語実験であり、テキスト言語では扱いにくい視覚的表現と、プログラムの美的な形の両方を狙っている
- 言語の骨格は ラムダ計算で、決まった実行順序よりも評価に近い構造が、絵を見るときのあり方に似ているという点から出発している
- 手で描きやすく、かつ機械が解釈できるように、グリッドベースの記号とワイヤーを使ってデータフローを表現する
- 純粋なラムダ計算だけでは使い勝手が低いため、数値、数学演算子、フレーム、スライダーのような構文糖とインタラクション要素が追加されている
- 現在の実装は λ-2D プログラムを JavaScript の単一式に変換して実行するが、まだ回路図のように見える限界や、学習・スキャン上の課題が残っている
絵でコーディングする言語実験
- λ-2D は「絵を通じてコーディングできるのか」という問いから出発した非言語的プログラミング言語の実験である
- テキストではない方式の言語には、すでにいくつもの系統がある
- 設計目標は3つに要約される
- プログラムが描かれるという事実を活用し、テキストベースの言語では実現しにくい機能を入れる
- 命令数が少なすぎて単純なプログラムでも難しくなったり、多すぎてミニマルでなくなり、コンピュータビジョン処理が難しくなる状況を避ける
- プログラム自体が視覚的に魅力的で、額に入れて飾りたいと思えるほどのドローイングになるようにする
ラムダ計算とグリッドベースの表現
- λ-2D は、命令型・低レベルの方式ではなく、ラムダ計算を言語の基盤としている
- ラムダ計算は「実行」よりも「評価」に近く、絵を見るときに視線が特定の順序なしに点・線・形・構成をたどるあり方とつながっている
- 初期構造はグリッドベースのシステムである
- ユーザーは複数のグリッドを横切る連続線を描ける
- 各グリッドは最終的に有限の記号集合のいずれかとして解釈される
- 人にとっては描きやすく、コンピュータにとってはパースしやすい妥協案である
関数記号とワイヤーによるデータフロー
- ラムダ計算の基本命令は2つだけである
- 関数適用
- 関数定義
- λ-2D は、関数適用をカップ形の記号で、関数定義をギリシャ文字 λ で表現する
- 基本的なラムダ計算と同様、関数は常に1つの引数を受け取り、1つの出力を生成する
- 複数の引数を扱うには、複数の関数をつなぐ**カリー化（currying）**の方式を使う
- 記号間のワイヤーは、データが流れる経路の役割を果たす
- この段階の言語は技術的にはチューリング完全だが、実際の使用は非常に煩雑なため、数値や数学演算子のような追加記号が入っている
- これらの追加記号は構文糖である
- 望むなら Church numeral のような純粋なラムダ計算構造だけを使うこともできる
フレーム、ドローイングデータ、スライダー
- λ-2D は、Scratch でスプライトを同じエディタ内で描いてそのまま使う体験を、より自然に拡張しようとしている
- フレームは、キャンバスの特定領域をワイヤーで囲み、左上に表示記号を置く方式である
- 領域内の落書きはデータとして使える
- 数学関数の形を直接スケッチし、アニメーションなどに活用できる
- 方程式を直接求める別の段階なしに、形をデータとして扱う
- ランタイムにドラッグできるスライダーも導入されている
- プログラムをパラメータ方式で制御する用途である
- 将来的には他の GUI 要素も検討されている
エディタと 5×5 記号
- 初期アイデアは、点が打たれたノートに手描きしたサンプルプログラムから始まった
- 紙上のプログラムをスキャンするコンピュータビジョン部分が準備できていなかったため、まずデジタルでプログラムを描ける簡単なエディタを作った
- 各記号は 5×5 ピクセルで作られており、グリッドキャンバスに配置しやすい
- ユーザーは鉛筆ツールのように自由な手描きもできる
- 一時的な手段として始まったエディタは、次第に多機能なエディタに近づいている
純粋関数型言語における出力の問題
- λ-2D は純粋関数型で状態を持たないため、一般的な
print文を実装するのは難しい - 出力は状態変更であり、特定の順序で出力されることを期待するには、式の評価順序も仮定しなければならない
- 解決策は「出力」を関数型として再定義することだ
- 空のキャンバスを関数に渡す
- テキストや望みの落書きのように見えるようピクセルが変化した新しいキャンバスを受け取る
- 文字列や文字ではなく、キャンバスとピクセルを中心に据えた言語として設計されている
JavaScript 変換と実行の可視化
- 基本パーサは、λ-2D プログラム全体を等価な JavaScript 式に変換する
- 結果の JavaScript は括弧が非常に多い単一の巨大な式で、非効率ではあるが動作する
- 現在のパーサは JavaScript を出力し、ブラウザの JavaScript エンジンが実行を担うため、実際の実行過程を可視化するのは難しい
- 代わりに、パース過程は容易に可視化でき、ツリーウォークインタプリタがプログラム実行時に通る経路に似て見える可能性がある
- パースアニメーションに記号ごとの音を付ければ、プログラム実行を歌のように「聴く」ことができる
- 結果は、8ビット時代の奇妙なコンピュータゲームのような音に近い
- オンラインデモの
Menu > Program > Animated Runで確認できる
残された限界と次のステップ
- λ-2D はもともと、ペンと紙でプログラムを描き、拡張現実でインタラクションのフィードバックを受け取る、より大きな研究の一部として始まった
- プロジェクトが次第に面白くなり、独立したプロジェクトになった
- 初期目標を完全には満たしていない
- プログラムがドローイングというより、回路図のように見える傾向がある
- 一般の人が学びやすいかどうか確信しにくい
- コンピュータビジョンシステムが誤りなくスキャンするのも容易ではない可能性がある
- λ-2D をさらに洗練させたうえで、ドローイングを計算として扱うシステムに統合できる他のプログラミング言語も設計する計画である
- λ-2D のベータ版はオンラインで試すことができ、パーサとエディタのソースコードは近く GitHub で公開される予定である
1件のコメント
Hacker Newsのコメント
こういうのが好きなら、オートメーションプロジェクトエンジニアの仕事も面白い、少なくとも親しみやすく感じるかもしれない。
機能ブロック図（FBD）はかなり似ていて、機能ブロック同士が線で接続され、演算順序はブロックの並びで定義される。ブロック自体はエンジンの組み込み関数のようなものでも、合成ブロックでもあり得る。図は制御周期ごとに1回実行され、通常はジャンプブロックがない限り、入力の変更有無に関係なく各ブロックが各制御周期でちょうど1回実行される。
醸造所から石油化学プラントまでの制御ロジックがこういう形で実装されている。FBDベースの制御システムのUI側で働いているので、こういうものを毎日見ている。
BitGrid[1]に似ているけれど同じではない。FPGAを極端に単純化したようなもので、ビットが格子の上を並列に行進する様子を想像している。
このアイデアは非常に実用的、つまり大衆向けペタフロップス級になるかもしれないし、そうでないかもしれないが、結局のところASICでDFF 1個がどれだけエネルギーを食うかにかかっている。長いこと探している数値は、静的電力と1ビットをロードするエネルギー量だ。
プログラミングモデルも問題だ。誰も格子の上に論理を直接配置したがらず、みんなできるだけ早く抽象化したがる。その部分をやり切るほどの集中力が自分にはない。
これを調べていてフォン・ノイマン型セル・オートマトン[2]とNobiliセル・オートマトン[3]を見つけたのだが、何十年も似たようなアイデアに関心を持っていたのに初めて見た。コンピュータサイエンスのこの分野は発見可能性が低すぎて歯がゆい。
どちらも同じばかげた前提を共有している。FSAの集合が無限サイズのセル空間を定義し、すべてのFSAは同じ状態遷移関数またはルール集合を持つ。まさにその「単純化」ひとつのせいで、コードゴルフの領域に追いやられているように感じる。
[1] https://github.com/mikewarot/Bitgrid
[2] https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton
[3] https://en.wikipedia.org/wiki/Nobili_cellular_automata
もしBitGridのアイデアを引き継いで試してみたい人がいたらありがたい。
「技術的にはこの時点で言語はチューリング完全だが、使うのが極めて苦痛で、自分の設計ルール #2 に違反している」という部分で、自分のLambda Diagrams[1]はステップ1で止まった。
そのページの下部には、自分が知っている他のグラフィカルなラムダ計算記法へのリンクが全部あり、今これも追加した。
[1] https://tromp.github.io/cl/diagrams.html
これでブラウザに「自分には全部ギリシャ語だ！」と言わせる言語を作った、と主張できるわけで、かなり見事な成果だと思う。
高解像度ディスプレイが登場した90年代には、そういうものはすでに置いていかれていた。
https://worrydream.com/AlligatorEggs/
こういうことはLabVIEWでもやられてきたし、どこまで進めるのが難しいかも分かる。音声／音楽生成プログラムでも行われていて、Max [max]がその元祖のようなものだ。
何かを作ることはできるが、すぐに散らかってしまう。見栄えがいいかと言われると、そうは思わない。
[max] https://en.wikipedia.org/wiki/Max_(software)
複雑な信号フローは、静的なテキストブロックよりも視覚的な配置、特にリアルタイムの数値がアニメーション表示される図のほうがずっと追いやすい。
最近のMax/MSPには
mcもあり、複数の同一信号について個別の線やノードを作らずに済むマルチチャネル接続を提供しているし、~genやJavaScriptでテキストベースのプログラミングノードも使える。こうした「ブロックプログラミング言語」は、ブラックボックス化による抽象化や、箱の中に箱を作るやり方によって有望に見える。実装が悪いのか、使いこなせないのか、それともパラダイム自体がうまくいかないのか気になる。
考慮すべき点は、こういうものはたいていプログラミングや抽象化を知らない人たちが使うということだ。プログラミングが得意な人なら散らかったものを作らずに済むかもしれないが、そうなると普通にコードを書けばよいので微妙だ。
LabVIEWがひどいという点には同意する。この問題だけでなく、アップデートがすべてを壊すし、ライセンスもそうだし、とにかく厄介だ。
プロのLabVIEW開発者たちの小さなコミュニティがあり、総じて非常に読みやすく質の高いコードを書いていた。多くの人にとって馴染みのあるやり方とは違ったが、良かった。
ただ、自分は数年前にその世界を離れた。何ができようと、LabVIEWはいずれ死ぬという兆候が明らかだったからだ。
約10年前にペトリネットを初めて知って以来、グラフィカルな形式仕様に関心を持っていた
恐ろしい数学記法や言語ではなくグラフィカルな表現があれば、エンジニアは形式手法をもっと活用しやすくなるはずだとずっと感じていた。残念ながら、他のエンジニアにペトリネットを見せるたびに、ほぼ即座に興味を失ってしまった
University of Yorkで博士課程をやめる前には、RoboChartとRoboSim[1]というものを扱っていたが、実際にはこちらのほうがより取っつきやすいかもしれない。ただし、ロボティクスの意味論にかなり縛られている。個人プロジェクトとしては、RoboSimをネットワークやサーバーの世界でもう少し役立つように適応・拡張しようとしてきた
[1] https://robostar.cs.york.ac.uk/robotool/
これは本当に気に入った。特にJavaScriptで実装されている点がさらに良い
純粋主義者たちはベッドの上でも墓の中でも身をよじるだろうが、少なくとも可視化やオーディオの後続段階は明らかにやりやすくなったはずだ。ビジュアルは最高で、次の段階は既存プログラムの高レベル構造を何らかの形でこの形式に翻訳することのように見える。Dijkstraのアルゴリズムや人工ニューラルネットワークの誤差逆伝播アルゴリズムを壁に飾るために金を払う変わり者はかなりいそうだ
面白かったのは、この言語があまりにも純粋関数型で完全に状態を持たないため、
print文を実装できないという話だ。出力は状態を変える行為であり、特定の順序で出力されることを期待するのは、式がある順序で評価されると仮定することになるからだこれは単に「命令型ではない」という話ではないのか？ それでも、状態をどうエンコードするのかは気になる。変数、たとえばアイコン+色を導入して、個々の文を一軸または二軸に沿って整列できるのかもしれない
「非言語的プログラミング言語の領域は未開拓ではない」
2文目から攻撃的な三重否定で始まっている
1987年のWireworldを思い出した。もちろんWikipediaの記事もある [1]
Wireworldで実装された8ビットカウンタを見たことがあるが、かなりすごかった。ただ、これはもう少し簡潔に見える
[1]: https://en.wikipedia.org/wiki/Wireworld
ただし今はプレイしづらい。Webページ[1]とSteam版がFlashに依存していて、サードパーティのFlash再実装をいじる必要があるからだ
それでも、半導体の動作実装はWireworldよりはるかに優れていると思う
[1] https://www.zachtronics.com/kohctpyktop-engineer-of-the-peop...
オンラインデモへの直接リンク: https://l-2d.glitch.me/
私が見つけた、ほかの非常にビジュアル寄りなプログラミング環境/言語。線でノードをつなぐタイプの他のビジュアルプログラミングとは異なる
別の分類もできるかもしれないが、何と呼べばいいのかは分からない
Piet https://www.dangermouse.net/esoteric/piet.html
Turnstyle https://jaspervdj.be/turnstyle/ https://github.com/jaspervdj/turnstyle
Markovjunior https://github.com/mxgmn/MarkovJunior
Cellpond https://cellpond.cool/ https://github.com/TodePond/CellPond https://www.youtube.com/watch?v=xvlsJ3FqNYU
Imagegram https://zaratustra.itch.io/imagegram
Color Code http://colorcode.bananabanana.me/ https://www.youtube.com/watch?v=5M5hy9xsqKc Color Code 2 http://colorcode2.bananabanana.me/ https://www.youtube.com/watch?v=tTvvX4sjZWw Splaty Code http://splatycode.bananabanana.me/ https://www.youtube.com/watch?v=gd_e85lAKOs (Muril Polese制作 https://github.com/murilopolese/ http://gallery.bananabanana.me/)
Alchemy Online https://maxbittker.github.io/alchemy-online/ https://github.com/MaxBittker/alchemy-online