非言語型プログラミング言語
非言語型プログラミング、とでもいうべきものになにか可能性はないだろうかと一年以上考えています。
非言語型プログラミングとは、言語的ではないプログラミングです。そのまんまか、というか意味が分からない。
このあたりの話はスノウクラッシュ的な話でもあるのですが、SF小説にもなかなか出てこないのがプログラミングの話題。
- 作者: ニール スティーヴンスン
- 出版社/メーカー: 早川書房
- 発売日: 2001/04
- メディア: 文庫
きっと小説家がプログラムを書く事が少ないのでしょうが、それでもルーディ・ラッカーみたいな数学者兼プログラマ兼小説家みたいな人もいるので、作者が解らないというよりは読者がわからないからないのかもしれません。
- 作者: ルーディ ラッカー
- 出版社/メーカー: 早川書房
- 発売日: 1998/10
- メディア: 文庫
僕が映画、マトリックスで最も驚いたのは、パンフレットにあった「オーストラリアのデザイナーが"日本人のプログラマは縦書きでコードを書くに違いない"という思い込みから、マトリックスは縦書きでカタカナ混じりの文字がキーデザインとして多用されることになった」という下りで、まずそんな発想がネイティブ縦書き文化人間には全くなかった訳で。そもそも最近、縦書きの文章ってあまり読んでない。
森鴎外や福沢諭吉が欧米に遅れをとるまいと、日本のローマ字教育と横書き文化を普及させたおかげで、コンピュータもなんとなく使えているわけですが、エジケンのLingrなんか、最近イランで大流行中らしく、もう読めやしない言語。しかも右から書くタイプの言語でチャットされているわけです。日本人がシリコンバレーに行って、アメリカ人にコードを書かせてイランで大流行。ワールドワイド過ぎる。
そうなると、プログラム言語って凄くて、phpもC++も世界共通なわけですよ。
みんな左から書くし。
ほんと、こればっかりは明治の頃の人たちに感謝しなくてはなりません。
横書きって凄い。
いつの間にか読み方の左右も入れ替わっていて、益々良い感じです。
ところがやっぱり当たり前ですけど、プログラミング言語はプログラマのためのものなわけです。
プログラマ以外は使えない。
けれども、例えば足し算をしたいとか、なにかの平均を出したいとかというときに、プログラムを書く人はいまはあまり居ません。
エクセルを使う人も居ます。エクセルの=SUM(A1:A10)とかももう立派な非言語プログラミング環境だと思う訳です。
プログラムとそうでないものの境目が、特に最近、僕の中で非常に曖昧になってきています。
僕が若い頃は、C言語のような、「自己記述可能」な言語、それこそOSとか作れる勢いのやつが本当のプログラミング言語で、SEDやAWKなんかはCPUの動きとかけ離れた内容を書くので「プログラム言語とは呼べない」と思っていました。そのために「スクリプト言語」という言葉があるわけで。
しかしここ数年、たとえばJavaScriptだとか、ActionScriptだとか(まあこの二つはどちらも同じECMAScriptですが)、PHPだとかPerlだとかRubyだとかいった、いわゆる軽量言語が主流になってきています。
僕にしてみれば驚くべき変化。もう激変といっても差し支えない変化で、「こんなOSも記述できないような言語でなにをするというのだ」と思っていたのですが、実際にWebアプリケーション主体の受注開発ばかりやってみると、「そもそもOSが記述できる必要がどこにあるのだ」という考えにいつのまにか変わっていました。
PHPもPerlもRubyも、僕が昔書いていたようなポリゴンをリアルタイムでゴリゴリ動かすようなプログラムを書くのには全く不適切ですが、Webアプリケーションみたいなものを書くにはこれ以上便利なものはないのではないかというくらいに便利です。
僕のなかにあった、頑な「プログラム言語とスクリプト言語の境界線」が緩やかに崩壊したとき、「そもそもプログラミングってもっと幅広いものなのではないだろうか」と考えるようになりました。
コンピュータを使う事そのものが、殆どプログラムなのではないか。
そこで、プログラムという行為を僕の中で再定義することにして、たとえばこう考える事にしました。
◇プログラムとは、コンピュータに指示して特定の作業を自動化することである。
こうすると、たとえばエクセルの表も、Googleの検索クエリーも、プログラムなのだと言う事が出来ます。
Googleの検索クエリーって、もう誰でもつかるんですけど、そもそも誰でも使えるということ自体が、凄い。
そのうえ、それでもなおgoogleで目的の情報にたどり着くにはテクニックが必要です。
「とは検索」とか、「ダブルクオーテーション付き検索」とかは必須テクニックですが、Googleは他にもいくつかいろいろな検索オプションがあって、使いこなすともっと便利なことがあるのかもしれません。
「なにを検索するか」ということは案外重要なことなのですが、実は特定の単語を検索するとき、知りたいことは限られています。
例えば「布留川英一」を検索するとき、彼の著作を知りたいのか、彼のWebページを知りたいのか、彼の人となりを知りたいのか、彼に言及しているものを知りたいのか、というように目的によって本当に必要なページは変わります。
Googleのような一元的なランキングでは、それをうまく伝える事は非常に難しいわけです。
たとえば「布留川英一 本」と検索するのがいいのか、「布留川英一 著」と検索するのがいいのか、ということです。
さらにいえば、本を買いたいのか、その本の評判を知りたいのかといったことによってもまた順位が変わります。
僕はコンサルタントなので、自分の関わったプロジェクトやサービスが世間にどう認知されているか、ということを随時追跡しています。
僕にとっては例えばうちの社員である布留川英一の新刊の評判を検索したりしたいというのは良くやる事です。
こういうときに役立つのはtechnoratiのようなブログ検索ですが、ブログ検索だと最近つとにスパムブログが目立つようになってきました。
スパムブログとそうでないブログを見分けるのはかなり高度な人工知能がないと難しく、今後改良していかなければならないところだと思います。
また、ブログ検索でブログを見つけても、それが良い印象なのか悪い印象なのか即座に調べるのは難しいのです。
そういう事態に対応するために、試しに海外サーバに作ったのがfeelfind.net。
これはtwitterやjaiku、はてなハイクなどのミニブログを検索してほぼリアルタイムになにかの感想や評判を引き出す事が出来ます。いまはサーバを移転したばかりなのでデータが殆どクロールされていませんが、毎日10万以上の書き込みを記録しているので、思わぬ発見があります。
たとえばmacbookについての反応を知りたかったらこんな結果になります。
実は、どういうやり方で検索キーワードを選ぶと目的とする情報にたどり着くか、ということはかなり高度なノウハウになります。
しかし、例えばそういうノウハウは、僕らのような本職の技術者よりもむしろ実践で鍛えられたOLさん達の方が詳しかったりするのです。
たとえば典型的なWebプログラマはエクセルのマクロを殆ど知らないのではないかと思います。
そういう人があるとき、ピボットテーブルという機能があるということを知り、驚愕したりするのです。
ちょっと詳しいOLの人たちはアクセスやファイルメーカーを縦横無尽に使いこなします。
クエリーの書き方なんか、僕らより上手いんじゃないかと思う事があります。
例えば、何年か前、ある大きなイベントで投票集計の仕事を請け負った事があるのですが、なんと表彰式直前にプログラマのミスで間違った統計結果を表示していたことが解りました。
その投票集計は、グランプリの決定に必要な情報であるため、これがデタラメだと大変困ります。
とはいえあと30分しかない、ということになりました。
いまから投票集計をしなおすプログラムを書いて、その妥当性を検証するとすると、かなり厳しいのではないかと思いました。
かろうじて生データを別に保存しておいたので、集計し直す事は論理的には出来るのですが、なにしろ時間がありません。新たに集計プログラムを作っても、そのプログラム自体がバグってないかどうか、誰にも確認できません。会社にはその新人一人だけ。
当時は僕含めて数人しか居ない会社だったので、クライアントも、「適当でいいよ」という依頼だったのですが、そりゃいくらなんでも適当すぎる。
とはいえ僕はクルマで移動中で、当時はEモバイルなんかなかったですから、船橋あたりで渋滞に捕まっている状態ではとてもコードなんか書けない。電話の向こうの新人プログラマは半泣き。
その時に、総務の女性が横から出てきて「なあんだ、そんなの簡単よ」と、ホイホイっとアクセスに生データを読み込ませてものの数分で再集計を済ませたのです。「そんなことってあるのか」と思った訳です。
そのときは「神業だ」と思った訳ですが、今の定義で改めて考えると、それは彼女がプログラムをしていたということに他ならない訳で、彼女の使っている言語がたまたま「アクセス」だったということなのだろうな、というわけです。
で、アクセスですけど、これのクエリー画面とか、本当に非言語型プログラミングの最たるもので、なにしろデータベースのフィールドを画面上でつないだりして作る訳ですよ。
こういうのを昔「ビジュアルプログラミング」と呼んだりして、そういえば小野さんとかエジケンとかはもともとそういう商品を作って売る人だったわけですが、データスパイダーって凄いナイスネーミングだな。と今更ながらに思う訳です。
データスパイダーとかアステリアとかの画面って、本当にプログラムみたいになっていて、なにかの出力をなにかの入力に繋ぐとデータフローが出来てプログラムができるんですけど、これって言語に依存しないわけです。QuartzComposerもそうですね。
そういう、言語に依存しないけど便利、みたいなものの知識って凄く重要で、たとえば最近はYahoo pipesとかはまさにそうですが、知識というよりも知恵かな。データの集め方と集計の仕方の知恵。
ただ問題は、パイプつなぎ型のプログラムだと、結局プログラマに近いロジックの人しかプログラムできないということです。
あと、意外と面倒。
簡単なようで面倒なんですよね。
QuartzComposerでプログラム書こうとすると解りますけど、まず部品探すところで迷子になります。
さらに、どの部品をどのように繋ぐと何が出来るのか、全く予想できない。
電子ブロックみたいなものですね。
結局マニュアル通りに繋ぐしかない、みたいな。
マニュアル通りにつないだあとのバリエーションで多様性が出にくいというのも問題です。
シンセサイザーとかもまさにそうなんですけど、この手の奴って何でも出来そうで何も出来ないのが多いんですよ。
QuartzComposerはけっこういろいろ出来る方ですが、実際のところ「これは何に使うんだ」というものが多いですし、部品も「これが欲しい」というのが無かったりするので、結局RSSを読んでくるスクリーンセーバー作って終わり、みたいなことになりがち。
ある意味で、Dashcodeはプログラマ寄りでしたけど、LeopardのWebclipは本当に凄い。だってページを切りとるだけだもん。それでもけっこう便利に使える訳です。これがまさに非言語的ということかな。
で、非言語的なのにプログラミング"言語"と付けたのは、たとえばExcelにしろアクセスにしろ、Webclipにしろ、言語というよりも環境なんですよね。
言語というのは交換可能なものだから、要するに、そこから横に広がっていくような方向性が欲しいわけです。
まあたとえばブログで「おれのWebclip術」みたいなのを公開すると間接的にノウハウを交換できますが、なんていうか、それがちゃんとモジュールとして機能してどこかをクリックすると自分のdashboardにインストールされるとか、そのくらいの交換性は欲しい。
yahoo pipesなんかがまさしく見事なのはそういうところですね。
じゃあ結局yahoo pipesなんじゃん、と言われてしまうとそれまでですが、もうひとつの問題はyahoo pipesがパイプ式であるということです。
データフローを表現するには確かにパイプ式は便利。
しかし、データフローでものごとを考えることができるのはかなりコンピュータを解っている人です。
電子回路に逆戻りした感じがするんですよね。パイプって。言語の良さがない。
言語って一次元のものじゃないですか。
見え方は二次元であっても。
だからC言語のようにセミコロンでつなぐととにかく一行になるっていうのは解りやすいんです。
一次元であることは極めて重要で、頭から読んでいくと必ず処理の全貌を追う事が出来ます。それがもう保証されている。
パイプ型は近いものはあるんですけど、そもそもデータフローを中心に考えると、興味対象というか、データの発生源がひとつしかないことはまずなくて、複数のスタート地点があり、しかも途中で複数のプロセスに分岐するんです。そうするとどこがどうなっているのやら解んなく夏てしまう。
むかし、中嶋謙互さんが「並列プログラミングを理解するには通常のプログラミングとは異なるセンスが必要」と言っていたけど、まさにこれは並列プログラミング的な感じ。
関数型言語のコードを読むのが非常に疲れるのと一緒で、処理の流れを一次元で追えないのはいいところであり、わるいところでもあるのかもしれません。
その意味ではgoogleの検索クエリーは素晴らしい。短いし、一次元的です。
でもこの世界ってまだまだ発展する可能性があると思うんですよね。
非言語型プログラミング言語、または環境って、要するにコンピュータと人間との究極のインターフェースになっていくわけですから、ユーザーエクスペリエンスとサービスデザインのコンサルタントとしては、日々考えていかなければならないテーマなのです。
2008-01-24 02:47
nice!(1)
コメント(0)
トラックバック(0)
コメント 0