nikezono.net

原文:Transclusion will never catch on

著者:Mark Baker

—

前提となる参考文献:

Wikipedia 東外大テキスト

—

トランスクルージョンはあるページから他のページへと動的にコンテンツを引用する仕組みだ。 これはカット・アンド・ペーストというよりも、他のページの特定の部分への参照（ポインタ）を用意することに近い。ポインタは実行時に解決されるから、あなたがページをロードするタイミングでコンテンツを引用することになる。トランスクルージョンは、テッド・ネルソンの「ハイパーテキスト」構想の根本的な部分である。ごく限られた分野を除いては、トランスクルージョンはこれまで一度も陽の目を見ることはなかった概念だ。未だに興味深くはあるものの、これからも受け入れられることはないだろう。

Rick Yagodichが面白い記事を投稿していた。On Third Party Transclusionというこの記事では、現行のHTML上でトランスクルージョンを実装する計画の中にある、いくつかの問題について議論している。Rickの分析はとても良いものだったが、私に言わせれば、言及されている以外にも更に２つの問題がある。そしてその問題は、トランスクルージョンの実装計画の失敗を運命づけるものだ。

トランスクルージョンはWebの基本的な自然原理に相反するものだ

David WeinbergerはWebの原理について小さいピースが緩く結合したものと描写した。その通りで、Webが今、うまく動いているのは、何十億もの全てのWebページがゆるく結合しているからだ。この結合がきつくなれば、新しいページを１つ作ることも大変になるし、その結合クラスタに入っていないページは、Webを通して読めないし、そのページからWebの何十億ものページにアクセスすることも出来なくなるだろう（ゆえに大半のページは消滅するだろう）。Webのゆるい結合はWebがうまく動く上ではとても重要なことなのだ。

トランスクルージョンはページとページの間によりタイトな結合を与える。あるページが他のページから引用されている時、２つのページはきつい結合状態にあると言える。このページは、（著者がそれを知っていようと知らなかろうと）更に、トランスクルード元のページがトランスクルードしている他のページたちとも結合していることになる。トランスクルージョンはWebの自然原理に反する。HTTPのプロトコルがよりトランスクルージョンの実装を容易にする方向に進んでいったとしても、現在のWebの原則に反するがゆえに、その生態系を破壊することになるだろう。

「小さいピースの緩い結合」についてもっとフォーマルな言い方がソフトウェアデザインの世界にはある。「密結合と疎結合」だ。これはアダプタブルなソフトウェア設計の現場では本質的な考え方だ（そしてWebベースのソフトウェアアーキテクチャの基本でもある）。自己言及的・自己充足的で、他のモジュールの振る舞いを意識せず、自身の役割に徹したソフトウェアは高いコヒージョンを持つといえる。そうしたソフトウェアの組み合わせからなるシステムが疎結合と呼ばれる。

一般的にこのアーキテクチャはモジュール間のメッセージングによって実装される。開発者は好きなモジュールを好きに書き換えてもいいし、言語レベルで刷新を行ってもいい。ただ、同じフォーマットで同じメッセージを受け取り、同じ振る舞いを行い、同じメッセージを配信すればいいだけだ。この考え方はシステムのロバスト性を高めて、システムへの新たなニーズに対応することを容易にする。

一方トランスクルージョンは、コヒージョンが欠落していて、密結合的なコンテンツを生み出してしまう。コンテンツ・オブジェクトの実装は、内部的に別のコンテンツ・オブジェクトの実装と結びついたものとなる。これぞ密結合だーWebがここまで動いてきた原則とは正反対のものだ。

もちろん、既に現行のシステムの中にトランスクルージョンの影響を見出すことはいくらでもできるーDITA(訳注:Wikipedia参照)のように。DITAはトランスクルージョンの一例といえるだろうが、しかし、DITAは多くの現行の文書システムと同様に、コヒージョンは低く結合度が高いものだ。この傾向が、こういったシステムやプロジェクトのほとんどが壊れやすい原因だ。そしてそれぞれに協調することもできなければ、データの変換も難しくしてしまう原因でもある。 密結合に利点はない。トランスクルージョンの文書の再利用は、実装も理解も密結合的に行えば容易なものだが、そこにWebらしさは無い。(文書システムにおける疎結合の事例としてはWikiやSPFEが挙げられる）。

トランスクルージョンは時代遅れの出版モデルに基づいている

トランスクルージョンのアイデアの背景には、新たな出版物を他の出版物からの「動的な」引用によって創りだそうという意図がある。これは出版物が固有の状態を持つということに依存している:出版物が静的なアドレスを持つ静的オブジェクトであるということだ。これこそWeb的ではない。Webにはあるコンテンツが次のタイミングに同じアドレスを持っている保証はないし、あるアドレスのコンテンツが次のタイミングに同じものである保証もない。メディアとして常に動的なものだ。

紙の出版物では、コピーライトを明記することで著者が著作権をコントロールすることが出来る。しかし、ひとたびコピーされて、製本して販売でもされてしまうと、購入された時点で購入者の資産となってしまう。それをオリジナルの著者が返せということはもうできない。ひとたび出版されてしまえば、それはもうある種公衆に属するものだ。少なくとも、読みやすいものが残っていく。

電子出版はこんなことにはならない。著作がキャッシュされ、コピーされ、あなたのKindleの中にダウンロードされても、著作者は削除することが出来る。あなたはコンテンツの閲覧権を購入したのであり、コンテンツの著作権は著作者に帰属するのだ。

このことが、電子出版の出版物なんて絶対に買わないよ、紙媒体の書籍しか買わない、という誓いにも似た思いを抱いている人を多く産んだものであり、反論の多い考え方であることはわかっている。電子書籍は購入者にとっての基本的権利に踏み込んでしまっていると感じられるというわけだ。だけれども、実際は、この対立関係は、異なるテクノロジーによって生まれたものであれば、異なる関係性を生み出せる、ということを映し出しているにすぎないと考えている。

電子「貸本」のアイデアは内部的には何も間違っていない。図書館と同じだ。レンタルビデオ店もそうだ。じっさい我々が消費したコンテンツをもう一度消費したいと思うことはほとんど無いわけだから、著作権を購入したり永続化した権利を購入するよりも、ワンタイムで利用し消費する権利を購入するほうがずっと経済的だ。

また、これと同じで、非公開文書にできるというアプローチも悪くない。近年EUで制定されている「忘れられる権利」がまさにそうだ。しかし、これは筋違いの例だと思っている。この出版物を無効にするためのものであり、著者についてのものではないからだ。とはいえ、昔出版した何かがいま、自分を辱めるとして、それを取り下げる方法が何も用意されていないというのはナンセンスだ。それはつまり、あなたがカーテンを開けたとして、二度と閉めることが出来ないということだ。私が一端、ある仕事について公開状態にしたいと思った時、また、それらを非公開にしたいと思った時、そう出来ないようにする理由はないだろう？

そう、非公開にするというアプローチは、全ての「参照」と「引用」の構造を破壊する。我々が勝手に、出版物は変更不可能、取り消し不可能だという幻想を持っていたのである。参照や引用といった構造は「忘れられる権利」を否定するに足るものではない。（ちなみに「非公開にする(unpublish)」という言葉はスペルチェックにかけると不明な言葉と指摘される。我々の専門用語としておこう）

同じく重要なのは我々の目に映る出版物を編集し修正する権利だ。これはWebを動かす基本原則の1つであり、読者達の「出版とはなにか」という概念を動かしているものだ。あるURLがポイントするのが、オリジナルが出版されてからずっと変わらない内容を持つコンテンツであることを期待するよりもむしろ、我々は最新バージョンのコンテンツであることを期待するだろう。

こういうユーザの期待は、トランスクルージョンでは答えられないものだ。コンテンツを更新した時、あなたがトランスクルードしたものが明日も同じ実体を参照しているとは限らない。

そう、あなたが丁寧に細心の注意を払って他のページから現在最新の状態にあるページ要素をトランスクルードしたとしても、それはあのチカチカ言う株式相場の表示器をインクルードしているようなものだ。 しかしその特性こそがWebサービスを動かしているものだ。Webサービスが規約に従っていて、特定のクエリに対しての返り値について常に動的でありながらも特定の目的に応じたものであるという信頼がWebサービスの根源にある。アドホックなコンテンツの再利用はトランスクルージョンには出来ない。 ふつうのWebページというものは、将来何が含まれるかも、将来どのアドレスで見れるようになるのかもわからないものだ。

トランスクルージョンは、一般的に受け入れられることは、ないだろう。

Webサービスは、明瞭な仕組みで、明瞭な目的があり、明瞭なフォーマット規約があり、長年に渡り受け入れられてきた。これ以上何かを発明する必要はない。 むしろ、我々はWebサービスのモデルからどのようなアドバンテージを得て、管理して、届けていくことが出来るかについて議論することに目を向けるべきである。

所感:

トランスクルージョンは、今のWebには無い魅力的な機能をたくさん備えていて、それはそれは魅力的なストーリーだと感じていた。完璧なバージョン管理と、完璧なトランスクルードがなされていれば、秩序のある、綺麗なWebを再構築でき、著作のオリジナルは常に参照できる、という感じ方で。

ここでMark Bakerが述べていることはある意味正論だと思う（WebサービスやREST APIのモデルはうまく行っているから）が、トランスクルージョンは、実装自体がそもそも既存のWeb上では成立しない、別種のWebを構築するプロジェクトだから、Webの流儀に反するという主張は少し的外れだ。

じゃあ逆にStream使って加工したい場合はどうするのがいいんでしょう? そう、データを加工するためのStreamを作るんです。このStreamをTransformStreamって言います。 coreのモジュールだけでこのTransformStreamを作ってもいいのですが、ここではgulpなどでお馴染みのthrough2を使います。

2011年の文章を今更超訳。

原文:http://www.niemanlab.org/2011/10/word-clouds-considered-harmful/

著者:JACOB HARRIS

2003年に書かれたウィリアム・ギブスンのSF小説 “Pattern Recognization”の中で、主人公ケイス・ポラードは精神的に異常なキャラクターとして描かれていた。 彼女は「ブランドもの」にアレルギーがあった。衣服のロゴデザインが目に映れば虫唾が走る。ミシュランのタイヤのマスコットキャラクター、ビバンダムを目にした時などは最悪の気分になるような人物だった。

もちろんこれは風刺だけれども、私も Word Cloud を見ていると、同じような気持ちになることがある。 何かを物語るビジュアライゼーションとしてWord Cloudが使われているのを見ると、特に、内臓がキリキリする。

Word Cloudについてご存知ないのであれば、軽く説明をする。 Word Cloudは、ある文章における頻出語を抜き出し、リサイズを行い、曖昧でもいいから単語をごちゃまぜに（アーティスティックに)配置することでその文章における各単語の意味合いや強さを示す手法だ。

この技術は、1990年代に「タグ・クラウド」として初出した(“Tag clouds are the new mullets”に有名な説明がある…そこではWord Cloudは一過性の流行りとして扱われている)。 当初のそれは、ブックマークのキーワードの可視化に使われていた。

近頃では、Wordleというサービスが生まれ、Word Cloudの生成はとても簡単になった。 これは加速するビジュアライゼーションに対するニーズを（安易に）満たしてくれるものとなって、私の内臓を痛めつけることになった。

で、Word Cloudの何がダメだと言いたいのか？ それを理解するには、我々が努力しているデータ・ジャーナリズムについての原則を理解してもらうことが助けになる。 ニューヨーク・タイムズ社では、「ビジュアライゼーションは報道/報告（Reporting)である」として、ニュースの語り口をより効果的にする他のいくつかの重要の要素、原則と共に強く信じられている。いくつか、というのは、以下だ:

データの中にある物語を見出すために、全ての余計な情報を取り除く、物語性・語り口(ナラティブ)

読者が記事のベースとなる知識を理解するためのコンテクスト

我々の出した結論に誤りや欠陥がないか、確度を上げるための調査をすること

装飾性はオマケにすぎないということ

読者から物語を読む能力を失わせるなら、「よくわからないけど何か目新しいビジュアライゼーション」や、「奇妙なインタフェース」を用いることに何の価値もないということ

もちろん、Word Cloudの手法は、こういった要素については全て無視している。

実例がある。6ヶ月前、私は、ニューヨークのハッカー達に対して、我々がいかにしてWikileaks War Logsにおける民間人の死者数をビジュアライゼーションしたかについて講演を行う貴重な機会を得た。 本当は、もっと私の講演は「我々がやったビジュアライゼーションの手法を見てくれ！」といった感じにしたかった。しかし、良いデータ・ジャーナリズムの原則については、それではいくらかしか触れることが出来ない。良いものと悪いものを示す、相反する実例があればベストなのだが、それは何だろうか？Goofus and Gallantのようにわかりやすい例があれば良いのだが・・・。

好例があった。Word Cloudだ。以下の２つは、同じデータセットから生まれたビジュアライゼーションだが、違いは明白だ。

Mapping a Deadly Day in Baghdad from The New York Times

word cloud of titles in the Iraq war logs from Fast Company

言っておくと、Fast Companyを特にあげつらって批判しているわけではなく、ここで指摘することは複数のニュースに見られる傾向だ。 記事を書く記者たちは、取り上げている問題の奥底についての知識に限界があるから、Word Cloudのようなものを安易に使ってしまう。こういう視覚化は、読者からすれば、カップの底に残った茶葉を読んでいるかのようだ。元のデータの意味するところに対して、読者に残されたものは、我々が大事に感じているビジュアライゼーションの原則についてことごとく失敗している虚仮威しの何かでしかない。

まず、手始めに、Word Cloudが扱えるのは雑なテキスト解析の結果のみであるということに注視すべきだ。これは、あるプロテインについて知りたいときに、アミノ酸の含有量しか書かれていないのと同じようなものだ。これにはひどく困惑させられるし、惑わされる。

私は、オバマ政権のティーパーティー運動についてのWord Cloudを作成したことがあるが、上位二件の頻出語は胡散臭いことに「like」と「policy」だった。もちろん、これはしつこく出てくる「don’t」を除外した結果だ。（また、いくつかのストップワード…’a’,’the’などもWord Cloudに対して支配的に振る舞うので、これらも除外だ） フレーズや語幹に基づいたテキスト解析なら、より正確な結論が出せる。 前述したWar LogsにおけるWord Cloudの作成において、”車”と”爆破”が同じサイズで描かれている時、これは「車が爆破した死亡事故がいくつかあった」ことを示すのだろうか、それとも、「車による死と爆破による死が同じ件数あった」ことを示すのだろうか？ あまり使われていない単語同士の比較を行いたいときはどうすれば？ また、文章のテーマを語る重要な単語を取りこぼすこともあるかもしれないー「車両」とか「トラック」とか、もしかしたら「ボンゴ」も、全て同じことを言っているのに、別のカウントになるのだ。

そう、Word Cloudにおける最も重要な問題は、「視覚化の手法としてテキスト解析を行うことが適切であるとは言えないシチュエーションでWord Cloudが使われてしまうこと」にある。「いや、Word Cloudを使えば、単語の意味や使われ方、論点が理解できるじゃないか」と論じる人もいるだろう（これについては代替できる手法があるとここで論じてきた)が、しかし、イラク戦争のように複雑な話題に対して、何かを説明するための資料としてWord Cloudを用いるのは本当に馬鹿げたことだ。彼らが表現しようとしているものを、表現したものから読み取れないじゃないか。 (訳注:Word Cloudは文中での単語の使われ方を連想させるかもしれないが、それが著者の意図したものとなる保証はないし、ある複雑な、横断的なデータセットに対してそれを行うと、著者の意図を表現するメディアにはならない、ということか）

読者はどうだ？Word Cloudは読者にデータの裏にあるコンテクストを示してはくれない。 たとえば、”LN”が”Local National”,”COP”が”Combat Outpost"として使われていたとして、読者はどうやってWord Cloudからそれを読み取ればいい？ 最も面白いデータというのは、得てして、読者がスラスラと読むためにはいくつか説明や翻訳を必要とするものだが、その観点で見てWord Cloudは何もやっていない。

更に言うと、物語性（ナラティブ）はどこにいった？ 我々のビジュアライゼーションでは、あらゆるイラク戦争の記録にまつわるナラティブから、１つを選び出し、データを表現するために用いた。より問題を鮮明にするために。

Word Cloudは、これに反して、そういったナラティブを明らかにするには、ステレオグラムを見るかのように目を細めなければいけない。この時、読者は、「イラク占領」が「たくさんのIED(即製爆弾)」や「爆発」に関係していることはわかる。そこまでだ。誰のためにもならないニュースだ。

Word Cloudが読者を迷わせてしまうかもしれない例をもう一つ挙げると、イラク戦争後の「サージ戦略」(訳注:Wikipedia)における宗教セクト的殺害の驚くべき増加を目の当たりにして、我々は混乱を覚えるだろう。それは「セクト」という単語は、他の多くの記事でも目にするものだからだ。しかし我々はすぐに、我々が今まで知っていた「セクト」という単語はもっと暴力とは関係ない、官僚が使うような意味合いでのものだったと理解するだろう。例えば、軍の新規採用における筆記事項に”The Sect Of Detainees”(訳注:わからない)があるのとは、意味合いが違うのだ。 もちろん、我々がビジュアライジングしたバグダッドでの恐ろしい暴力は、「セクト」という単語に関するものだが、「セクト」という単語はその頃の記事のテキストの中では一度も指し示されていない。だから、もし我々が今の今までWord Cloudを使ってイラク戦争をビジュアライジングしていたならば、我々はセクトと暴力は全く関係がないと考えていたかもしれない。

結論を述べると: 考察の一環(Insight)としてWord Cloudが使われているのを見ると、私は内面的に(Inside)少しずつ死んでいくようだ。まあ、それについてはあなたも理解してくれただろうから、少しはマシな気持ちだ。それでもちょっとだけ、Word Cloudが気になっているようなら、もう用意してあるから安心してくれ。

ヤコブ・ハリスはニューヨーク・タイムズのシニア・ソフトウェア・アーキテクトだ。

—

この記事は、テキスト・ビジュアライゼーションについて調べている時に見つけた。 今の今まで、有効なテキスト・ビジュアライゼーションにお目にかかったことが無い気がするのだが、タグクラウド(Word Cloud)については悪くないと少し思っていた。

しかし、良く考えてみれば、Word Cloudは確かにちょっとアーティスティック過ぎるかもしれない。基本的な仕組みはフォントのリサイズのみで、配置や配色にはあまり気を配らないし、気を配ったところで見る者に与える情報は記事本文のコンテクストを説明してはくれない。インフォグラフィックとしてはいいのかもしれないけど。

IxDA Toronto Talks - Information Visualization: Text Visualization - Beyond the Word Cloud, by Jeff Clark

Word Cloud以外のテキスト可視化手法がよくまとまっている。 しかし、ドキュメントの可視化はなかなか難しい。

文章だけから特徴量を抽出しようとすると、どうしても頻出語や単語の連関を特徴量として扱う以外のアイデアが出てこない。それでは、本文が言いたいストーリーは全く語られないという結末しか待っていない。

The Web Is Dead? A Debate How the Web Wins How Do Native Apps and Web Apps Compare? Two decades after its birth, the World Wide Web is in decline, as simpl

もう３年以上前にWebは死んだと宣言されていたらしく、ブラウザは終わったらしい。少なくとも、そういう議論はこれまでに多く為されてきたらしい。

「ウェブの死」と聞くと、思い至るのは当然「ハイペリオン」だ。

ハイペリオン（下）

一言でネタバレをすると、ハイペリオンは「ウェブが死ぬ」物語だ。

この物語の世界では、ありとあらゆる摩訶不思議、ミステリ、ホラー、ファンタジー、テクノロジーが跳梁跋扈しているのだが、それら全てのフィクサーが「もはや一個人、一クライアントには判別不明なまでに肥大した『Web』の総体」なのである。誰もが情報端末を持っているし、AIやアンドロイドもいて、電脳世界もあって、ジャックインしてサイバースペースを浮遊することも出来るが、依然としてオフィス街はあって、紙文書もあって、PDAには電波が入らないこともある。

テクノロジーが進み続けた結果としてのいびつなまでに肥大した、総ガラパゴスな世界がハイペリオンの世界観だけど、最後にはウェブが死ぬ。

ハイペリオンの世界では、「ウェブ」とその恩恵は以下のようなものがある。

即時通信

瞬間移動

ネット議会

WebをAIとして持つアンドロイド

など。これら全てが、「ワールドワイドウェブ」を前提として動いているが、引用元の記事にように、ブラウザや文書参照としてではなく、アプリケーションのインフラとしてウェブを用いている。そういう意味では、引用元の「Webは死んだ」以後の「ウェブ」を描いている作品だ。

この作品では、Webのインフラストラクチャそのものが瓦解し、全てのアプリケーションが消滅し、Webに寄り添っていた人間は全てハダカになる。情報的に孤立し、社会的に孤立し、物理的に孤立し、精神的にも孤立する。(なぜ瓦解したか、という点はここで重要ではない。「ハイペリオン」では、「AIの反乱」というモチーフが「ウェブ」を破壊するのだが、それは別のテーマであると思う。)

それこそ、あらゆる星々で、あらゆる情況で、ウェブを使いこなすことで「テラフォーミング」を行ってきたわけだから、そのインフラが消えたら、生きていくことはつらいことだ。遠い星々をまたいで家族が暮らしていたりすると、一瞬で家族が絶縁してしまう。

で、この物語では、最後に、ウェブに含まれない人間たちが登場して、「脱ウェブ」の答えを提示する。ウェブを放棄し、外の世界で、独自の進化を遂げ、常に外的環境への適応を繰り返し続けてきた「宇宙の蛮族アウスター」は、「人間そのものが、環境に適応することができれば、ウェブ（テラフォーミング）は必要ない」と言う。彼らは、羽根が生えていたり、毛皮があったり、いろんな形態をしていて、独自に進化した人類だ。

僕が思ったのは、じゃ、あんたらはどうやって適応したの？ということだ。それもテクノロジーの恩恵だという説明が作中ではなされているが、その指向性はハイペリオンの「ウェブ」とどう違うのか。

ユビキタス・コンピューティングの流れ、センサーネットワークの研究は、「あらゆる場所にコンピュータ・センサーを」用意して、「コンテクストアウェアネス」を目指す。人間に何の意識もさせずに、人間のやりたいことを判断し、コンピュータが答えを出す。人間の仕事を削っていく。これは実は「環境を人間に適応させる」やり方で、テラフォーミング的・ハイペリオンにおける「ウェブ」だ（と僕は感じている）。

これに対して、ウェアラブル・コンピュータの時代が今、まさに訪れようとしていて、外骨格をまとうことで人間の情報処理能力をアシストしようという流れがある。メガネとか時計とか電話の形で、コンピュータを身につけて、それらに適切なAppsをインストールすることで、その情況に適応する人間を作る。これは「アウスター的」な気がする。

もちろんこの２つの流れに対立の構図は無い（ウェアラブル・コンピュータのUXはセンサーネットワークによって加速するものだから）と思うけど、全く違う指向性を秘めているという感覚を、「ハイペリオン」から僕はもらった。

だれかが「最近のブラウザは高機能になりすぎて『ページを開く』ということは『リモートのプログラムを実行する』ことと等価になりそうで怖い」と書いていた。まったくだ。利便性とひきかえに新たなセキュリティの脅威が出てくるよね。JavaScriptを切るとなおよいが、それだとテキストブラウザとかわらない。結局w3m/lynx万歳ってことよね。 Ajaxとかはそのうち廃れるかもしれないね。安全性とアクセシビリティがこれから重要になってくるだろう。

いままでサーバサイドのnode.jsとクライアントのjsを通信させるときは、単純なObserverパターンで監視するだけで、 ほとんどGET/POSTメソッドを使ったRESTアーキテクチャ+AJAXと違わないようなAPI設計になってしまっていた。常にコネクションを張りっぱなしにしている優位性は、ajaxリクエストの回数が減っているだけに過ぎなかった。

しかしながら、node.js+socket.io+StreamObjectという考え方(socket.ioのコネクションをstreamとしてnodeで処理する）、そしてクライアントサイドでのこのようなReactive Programmingの概念の適用（たとえばbacon.js)により、サーバ/クライアント間でのReactive Programmingがうまいこと実現すると感じる。

つまり、socket.ioをMongoDBとブラウザとの通信レイヤーとして扱い、ブラウザでの操作によるデータの変更をMongoDBに反映し、反映したことをsocket.ioでsubscriberにpublishする、という形の実装を今まで行っていたが、 socket.ioでのデータ送受信をstreamとして扱い、そのデータ変更をリアルタイムにbacon.jsでwatchし、定期的にデータ変更をMongoDBにキャッシュする、というやり方が、ブラウザとサーバで同じStreamをやりとりする際に効率的だということだ（と考えている）。

このReactive Programmingのメリットは、

http://d.hatena.ne.jp/pokarim/20101226

にもあるように、

関数型プログラミングによるモジュール性、再利用性の向上

キャッシュすることにより多くの変数を使い回せる

非同期処理と分散処理に強い.リアルタイムに値の変更を使い回せる

であると思う。いままで自分が問題だと感じていたような、計算量が増大していくような処理がわりと軽めに書けるような気がする.

コードの臭いという言葉があるように、

Good Partsよりもアンチパターンを、デザインパターンよりもリファクタリングを学ぶことが良いと思う。

セマンティックスをリアルタイムで解釈してくれるプラットフォームを使い、キーストロークを逐次分析させることで、素晴らしい魔法のようなことができるようになるんだよ。