ビスケットのあれこれ

ビジュアル言語ビスケット(Viscuit)に関するあれこれを書いてゆきます.

コンピュータの車輪ってなんだ.それはプログラミング言語.

2013-01-08 15:13:29 | 1

そういえば,車輪はいろんな用途に使われて,それに応じてすごい工夫がなされている.決して汎用の車輪なんかない.最初は木の車輪だったかもしれないけれど,自家用車,トラック,ジェット機など全然違うように発展してきた.車輪という機構そのものは昔発明されたものだけれど,それを実際に使うための工夫は現在でも常に行われているわけだ.

では,コンピュータでの車輪に匹敵するくらいの発明と言えばなんだろうか.それはその人によって感じ方が違うのだろうけれど,僕は「プログラミング言語」という考え方だと思っている.機械を直接動かす低レベルの命令ではなくて,人間が指令する高度なレベルの命令で動かすということ.もし,プログラミング言語が無ければ,今のようなコンピュータの発展があったのだろうか.

以下,Wikipediaからで申し訳ないが,一気に発明されたというよりは,少しずつ色々な人によって発明が積み重なってきたようだ.

最初は,ドナルド・ギリースの卒業研究の紙テープの上でのアセンブリ言語.紙テープに打ち込まれた文字列A100Fを解釈して機械語の数値に変換するという仕事をコンピュータにやらせる.ところが,指導教官のフォン・ノイマンはその開発を中止するように言ったという逸話があるようだが,フォンノイマンでさえも,プログラミング言語という大発明の未来は見えていなかったということであろう.当時はこれを自動プログラミングと呼んだそうだ.なかなかいい言い方かもしれない.

初めての高級言語FORTRANの場合は,ハンドアセンブルよりも高速に動作することが求められていた.プログラミングの手間よりも計算の高速性の方が優先されていた.そこで最初からコンパイラの最適化が求められた.最適化するコンパイラをアセンブラで作るというのもすごい話だね.

コンパイラをアセンブラから直接作るのではなくて,アセンブラよりは高級だけれど,コンパイラを動かすだけの最低限の機能を持った言語を中間に置くという方法も発明された.コンパイラ記述用言語.そんな言語を何段も重ねて,より高級なプログラミング言語が実際に動くようにする.そうやると,複雑な最適化もある程度高級な言語で作れるようになるから楽だろう.

こうしてみると,「記号を解釈する機械」があって,その解釈の仕方を別の記号で記述する,ということが実にすごい発明だったと言えないだろうか.

で,僕が普段から嘆いているのは,最近,新しいプログラミング言語が全然発明されないということだ.重箱の隅をつっつくようなんじゃなくて,もっと奇抜なものが欲しい.プログラミング言語の発明の度合いはこの10年くらい落ちまくっているのではないだろうか.最近面白かったのはEgisonだけど,そんなようなのが100個くらい発明されて欲しい.

Viscuitの前身の言語がVISPATCHというのだけれど,実はまったく子ども向けではない.文章で説明しても非常にわかりにくいものなので,そのうちYouTubeで説明しなきゃ.この図は自己拡張可能な図形エディタのプログラムをVISPATCHで記述したもので.ちなみにこれは僕の96年の研究.これでさきがけから研究費をどっさりもらいました.


もっと車輪の再発明をしよう

2013-01-07 11:33:11 | 1

以前,若い人と話をしていたら何かを躊躇するような発言があって,聞いてみたら「それは車輪の再発明になっちゃう」ということを言っていた.どうやら,最近の若い人たちの間では車輪の再発明を極端に怖がるような流れになっているようだ.

車輪の再発明はなぜいけないのか.Wikipediaによるとライブラリがあるのにそれを使わないと互換性が無くなるから,といったことが書いてあったがこれは,車輪の再発明なんかではない.そもそも車輪というすごい発明に対してライブラリなんていう誰でも思いつくものと比較するのは車輪に対して失礼だ.ライブラリを活用しないでオリジナルのライブラリを作っちゃうとソフトウェアのメンテナンスが大変だという現象は,そういう名前を付けて止めるようにすべきだ.車輪などといったすごい発明を借りるべきではない.

確かにソフトウェア工学的にはライブラリの再利用をしないのはよくないことだけど,ちょっと検索したら似たようなライブラリが山ほど見つかるではないか.手が よく動く人だったら,そんな沢山見つかったライブラリを慎重に調査するよりは,自分で1から作っちゃった方が早いってこともある.他人が作ったライブラリ なんて自分の用途にぴったりということはあまりなくて,どこか改造しなきゃ使えないとかになっていて.そんなとき改造なんかしちゃったら,ライブラリの バージョンが上がったとき大変になっちゃうし.ちょっと日を置いてコンパイルしようと思ったらライブラリの仕様が変わってひどい目にあったとか.だから再利用をしないのは一概に悪いこととは言えないと思う.

僕はソフトウェアでは車輪に匹敵するくらいのすごい発明にはまだ至っていないと思っている.まだ車輪の一歩か二歩くらい手前のレベルだ.乗り物にとって車輪はかけがえのないものだけれど,そういうソフトウェアはまだない.雨後の筍状態.こんなときはみんなでマイ車輪を作るべきなんだ.

本当に車輪に匹敵するくらいのすごい発明の再発明をしたとしよう.それは逆にすごいことで.だってすごい発明者と同じレベルだってことでしょ.タイミングがちょっと遅かっただけで.

再発明は特に学生にはいい訓練になる.常に新規性しか求められなければ,時代がすすむにつれて重箱の隅をつっつくようなことしか残ってない.そうすると,研究者や発明者にとって理想的な訓練になりにくい.それより,面白い発見がたくさん詰まっているような筋のよい発明なんかは,答えを隠して,発明者と同じような条件で発明の訓練をしてみるのがよい.いろんな困難を乗り越えるスキルが身に着くと思う.

第一,今の世の中にあるものだって,そんなに直線的に効率よく発明されてきたものではない.山のような無駄な発明があって,しかもいいものだけが淘汰されるわけでもなく,いろんな理由で今の世の中になっている.無駄な発明の一人に名を連ねるのはまったく恥ずかしいことではない.

ソフトウェアは車輪程すごい発明はまだないから,そうやって再発明をあえてやってみると,もしかしたら先人がやったことよりも良いものができる可能性がある.それは先人の仕事をくまなく調べて重箱の隅でよいものを見つけるのではなくて,何も知らないで,作っちゃったとき.後で,先人の仕事を知ってがっかりするし,重箱の隅じゃないから論文にも書きにくいのだけれど.でも本当に同じ人が作ったわけじゃないから,どこかが違うわけだ.

僕はそんな目にばかりあってきたが,訓練の結果,その差分を見つけてそこを論文のストーリにするというスキルは身につけた.他人のそういうやつも,そこからよい点を見つけ出してあげることができる.未踏ユースのPMの仕事はそこが生きている.ときどき学生が研究の相談に来るが,再発明を指摘してケチョンケチョンにするというよりは,その人が一番最初になぜそれをやりたいと思ったのかを聞き出して,逆に勇気を与えて送りだしている.

だから怖がらずに再発明に挑戦して欲しいのだ.そうしないと,本当の発明になんて手が届かないのだよ.