  |
はてなキーワード:中間言語とは
HTMLコンパイラとは、一般的な「コンパイラ」の概念とは少し異なり、HTML文書や要素に対して新しい文法や振る舞いをブラウザに伝え、拡張するための仕組みを指すことが多いです。例えば、AngularJSのHTMLコンパイラは、開発者が定義したカスタム要素や属性（ディレクティブ）を解釈して、動作を紐づける役割を持ちます。これにより、標準のHTMLにはない独自の文法や機能をブラウザ上で実現できます。
一方、一般的な「コンパイラ」は、人間が書いたプログラムコードをコンピュータが理解可能な機械語や中間言語に翻訳するソフトウェアや処理のことです。この処理を「コンパイル」といい、プログラミング言語で書かれたソースコードを一括で変換し、実行可能な形式にします。コンパイラと対比されるのが「インタプリタ」で、こちらはソースコードを逐次読み解いて実行する方式です。
まとめると、「HTMLコンパイラ」はHTMLの静的な宣言文法を拡張し、新たな振る舞いを実現するものであり、主にフロントエンドフレームワーク（例：AngularJS）で用いられます。一方、「コンパイラ」はプログラムコード全般を実行可能な形式に変換する処理・ソフトウェアです。
https://ja.taiwebs.com/windows/download-html-compiler-2548.html
フロントエンドフレームワークで、新しいHTML要素や属性を作成するために用いる。
そのフレームワークがHTML文書の解析時にカスタムディレクティブやテンプレートを解釈し、動的な振る舞いを紐付ける。
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
絵師という言葉は最近できた言葉ではなく律令制にもある外来語が入ってくるまで使われた伝統的な言葉が1990年代から再度使われ始めただけ
そんな事より絵をかくことと音楽を作る事を同列に考えた場合、作曲家が考えた音楽は楽譜をとおして一般の演奏家が演奏するというのは紀元前より行われていた
しかし描かれた絵を再現する方法というのは生成AIが出てくるまでなかったのだ
音楽では作曲家と演奏家が別の能力であり演奏できるからといって作曲できる訳ではなく、多くの人が作曲家が作った曲を楽譜をよんで演奏しているだけである
絵は絵師が描いた絵を模倣するための中間言語が存在せず演奏家にあたる人がいなかったのだが生成AIが中間言語の役目を果たしプロンプトエンジニアが演奏家の役目となったのだ
開発したのがOpenAI Inc.なので勘違いしているのだろう。
ChatGPTは文字通りGenerative Pre-trained Transformerでしかない。
OpenAI社は人工知能の完成を目指している会社ではあるのだが、ChatGPTは副産物というか、素材というか。
神経細胞、シナプスの挙動を貧弱なコンピューターでどう再現するか。
こういうアプローチだった。
これと袂を分けて、入出力が人間っぽかったら良くね？
商業的な利用もそっちのほうがよくね？
先々人工知能エンジンの脳再現精度が上がったとしても入出力は自然言語で行わなければならない。
そのためには言語モデルを先に構築しておくのは無駄にはならない。
コアの人工知能エンジンは中間言語で入出力を行うが、外側HMIの部分をChatGPTに担わすようなイメージではなかろうか。
人の指示→ChatoGPTで中間言語にコンパイル→コアAI→中間言語でChatGPT→人が認知できる出力
このようなモデルならばコアAIは本質的人工知能の開発に注力できる、分離できる。
従来のAI研究はここ一緒くたにやとうとしてたのも停滞の原因と見抜いたのだろう。
営利企業である以上は稼げるプロダクトでなければ資金調達はできない、利益にならない
言語モデルの段階でも中間処理がそこそこできてればそれっぽいプロダクトにはなる。
商業的な使い道もある。
今後AIエンジンの開発は続くだろうが、現時点では知能とは程遠い完成度でしかない。
入出力がそれっぽいので知能っぽく見えるが、古典的な人工知能の定義から言えばおおよそ別物。
俺も気に入って使ってる、プログラム食わせたらあっさりバグも見つけやがった。すげぇと思う。
が、これは知能ではない。
なんか世間では、すげぇ物ができちゃった、世界が変わる、大革新、みたいな熱狂と不安と禁忌があるけどさ。
いやいや、そんな大層なものではありませんｗ
まぁこの辺のOpenAI社のマーケティング、演出は秀逸ではある。
ChatGPTの指示かな？ｗｗｗ
https://www.publickey1.jp/blog/22/net_7.html
中間言語なおかげで、コメントや変数名は残らないが普通に読めるレベルでC#コードに戻せるのがよかったのに、ネイティブだとそういうのも難しくなりそう
そのおかげで助かったこともあったし、ソースコードが見づらくなるネイティブ化はあんまりしてほしくないなーってところ
クライアントからこのソフトと連携してとexeを渡されたものの、仕様通りに動いてなくエラーログも出ない
もうサポートしてないバージョンらしく、ベンダーに聞いたりサポートしてもらうのも無理そう
C#で作られたものだったので、とりあえずソースコードを見たら原因がわかってどうにか対処できた
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
まずは【お前自身が機械翻訳に駆逐されろ】"iwatani"の翻訳した記事が上がっていた。
＜GoogleのAI翻訳ツールは独自の内部的言語を発明したようだ、そうとしか言えない不思議な現象が＞
Zero-Shot Learningは分岐のない翻訳などではない。これは正しくOne-shot Learningの延長線上にあり、
ワンショット学習すらしないで（この場合対応ペアでの事前学習をおこなわず）、新規ペアでの処理を行うっていうことだ。
この語は翻訳に限った話でもない。だからほとんどの訳がおかしい。むしろ機械翻訳の方がマシ（背景を理解していない翻訳者より機械翻訳の方がマシという皮肉な状況）。
（ちなみに実際に脳内でもOne-Shot Learningは繰り返し学習とは別パスなのではという示唆もある）
＜グーグルの翻訳AIが「独自の言語」を生み出したといえる根拠＞
http://wired.jp/2016/11/24/google-ai-language-create/
http://b.hatena.ne.jp/entry/wired.jp/2016/11/24/google-ai-language-create/
これらは古くから考えられてきた「基底となる」文法等を完備した「中間言語」などではない。
論文で触れられている「『Interlingua』な表現形式」は『semantic representations』とされていて、まさに多言語間で共通する「『意味表現』の表現空間」であり、
ツリー状に開かれてもいない。人が想像する構造化された言語などではない。
ただしその空間を共有していて、つまり共通の意味表現を持っていることは論文(arXiv:1611.04558)で実験的に証拠を提示されている。
今までも多対多の翻訳でネットワークを共有することでBLEUを向上できるという論文は出ていたが、今回のは、翻訳に関して言えば、十分普遍化した意味空間を内部的にもったネットワークに新規ペアをぶち込んでも能動的な転移学習すらせずにそれなりの結果が得られる、結果の向上だけでなく未知ペアを処理できるって事である。
そしてその効果は汎用性↑↑、そして最大のメリットはサンプルが少ない言語ペアもやりやすくなるぞ、マイナー言語にも早く適用できるかもって所だ。
One-shot Learning系（小サンプル）とDeep Learning系（巨大サンプル）によるネットワークについて、意味という（我々にも見えない）上位構造の下に配置された構造である「言語」を扱う特別な例では、両方を一つで達成できる可能性が垣間見えた論文なのでもある。
いわゆる頭の中が多動というやつで思考がいつもしっちゃかめっちゃかなのと、
力を抜くと思考がそのままダダ漏れになりそうになったり、早く喋りたくて口が開きかける衝動を必死で抑え込んで、
日本語として成立していない、自分のフィーリングと語感だけで構築された脳内の中間言語を最低限通じる日本語に直しつつ、
状況を見て出したりひっこめたりしながら喋らなければいけないので、日本語で会話するだけでかなり疲れる。
かなり疲れるのだけれど、医者からするとテンポはやや遅いが普通に会話ができているので、ADHDの診断はつくものの、会社員もできてるしイケるイケるって感じらしい。
診断を受ける15年ぐらい前に、中学の社会の授業中に不意に当てられて慌てて立ち上がりながら「アパラチア山脈」と言おうとして、
「アパッチのArmadilloはさんざっぱら白濁したAsparagusの茹で汁で脈絡なくRockYou」(英語部分はネイティブ風)とスラスラ答えて大恥をかいたことを契機に、
自分の異常性に気付いて自分なりに訓練し続けてきたおかげか、人前ではある程度抑え込めるだけマシな部類ではあるのだろうけれど、
表面上抑え込めたからといって普通の人に混じって生きるのが楽なわけでは決してなくてぐぬぬとなる。
歳を重ね、語彙が増えるほどに増している気がする中間言語の奔放さで脳内翻訳家の疲労は年々高まるばかりで、
心身の調子が良い日の方が、逆に思考の回転や衝動性が絶好調で、普通に会話するためのコントロールに苦心するという有様。
普通に喋るための抑圧感があまりに強かったので、先日居酒屋で友人に頼んで試しに中間言語をそのまま垂れ流した会話を少しさせてもらった際に、
どうせ私のクソ雑魚ナメクジなワーキングメモリでは覚えてなどいられないのでスマホで録音してみたが、あとから書きおこしてみたら思っていた以上に意味不明だった。
友人「おうおう、じゃあこっからってことで、はい乾杯おつかれー」
増田「ウィーンプラハ甲冑ぐるぐる モンティパラミッチャーげタンドリーナン(getout turn dreaming now かも) onceon the way」
友人「いやー、トランプさん勝っちゃったねー」
増田「Database バンシャディフォルモントゥ 放射ニカラグア絡まって左から北川 総研証券ドンタコスったらドンタコス」
増田「タンデムマンダム オーデュロイキャベツPrismProxyショートショートでガッテントゥルットゥ」
友人「そういや今度ポケモン出るやんか？」
増田「あんれまあビール さんさんさんさわやかスリザリン 僕らの肩にフリーズドライ 座布団どんぶりムートンブーツでムーンウォーク BoomBoomナチョス Ah」
友人「お前買う？」
増田「金平ごぼうで滅びた信玄Likeカーティス、マヌカハニーは無理筋かなメルシー？」
友人「前のもクリアしてないし俺は今のところ見送りかなあ、でもそのうち買ってしまいそうやけど」
付き合ってくれた友人からは、ところどころなんとなくわからなくもないが友好的な宇宙人って感じで怖い。とのお言葉をいただいた。
自分でも支離滅裂な言葉をスラスラと喋ってるのを聞くとコイツァヤベェやって思う。でも喋るのはとても楽だった。今から年をとってボケるのが怖い。
いちいち随分グニャグニャと喋ってるけど、声に出しているのは頭の中を流れて行ってる思考の中から関連の強そうなものを一応言語としてすくい上げたものだったり、
口を動かしてる間に飛んでいかなかった強い言葉の成分なので、実際の頭の中はもうちょっといろんなイメージが駆け回っている感じ。
普段はここから普通の日本語に変換して喋っているわけだけれど、多分こういったことを言おうとしていただろうという翻訳後はこんな感じになる。
友人「おうおう、じゃあこっからってことで、はい乾杯おつかれー」
増田「ウィーンプラハ甲冑ぐるぐる モンティパラミッチャーげタンドリーナン onceon the way」(うぇーい、どーもどーも、おつかれーい)
友人「いやー、トランプさん勝っちゃったねー」
増田「Database バンシャディフォルモントゥ 放射ニカラグア絡まって左から北川 総研証券ドンタコスったらドンタコス」(マジでなー、ヒラリーはホンマやらかしたな、えらいこっちゃで)
増田「タンデムマンダム オーデュロイキャベツPrismProxyショートショートでガッテントゥルットゥ」(そうなりそうやな、まあ俺にはどっちがいいのかわからないけど)
友人「そういや今度ポケモン出るやんか？」
増田「あんれまあビール さんさんさんさわやかスリザリン 僕らの肩にフリーズドライ 座布団どんぶりムートンブーツでムーンウォーク BoomBoomナチョス Ah」(あーあれ、サンとムーン？)
友人「お前買う？」
増田「金平ごぼうで滅びた信玄Likeカーティス、マヌカハニーは無理筋かなメルシー？」(今んとこビミョー、まあ買うとしたらムーンかな、お前は？)
友人「前のもクリアしてないし俺は今のところ見送りかなあ、でもそのうち買ってしまいそうやけど」
増田「晩酌よりかはキルフェボン、串刺し墓場酒場タタラ場板場ンティス？」(そういや前のもやってたな、ちなみに買うならどっちバージョンよ？)
軽度とされる人の中にはこんな感じの頭の中を抱えながら一般人のふりして暮らしているのもいるよということで。
世の中には同じようなことになっている人がきっといると思うので、そういう人に似た様なのがいるぞと届けばいいなと思う。
---
追記
友人がすごいという件についてちょっとだけ補足。
友人とは取り決めとして、恐らく会話にならないのでしばらく一方的に会話を投げかけてもらうということにしていた。
ただ、ポケモンのくだりあたりはこれまでの付き合いから、こちらの反応や返事の仕方をなんとなく予想ができたみたいで、見返すと割とちゃんとした会話めいたやり取りになってた感じ。
とはいえ「はうあーゆー」と言えば「うんたらかんたら えんでゅー？」とくるから、うんたらかんたらが聞き取れてなくても返すとか、そういう感じのやり取りであって明確に理解ができてるわけではない。
そもそも合間合間で友人は「わっかんねー」としこたま笑い転げていたし、合衆国大統領は時事ネタとしてとりあえず投げてみたけど思った以上に無理そうだったから諦めたとも言っていた。
なんとなくわかる部分については、話し方のトーンとかアクセントとかに加えて、普段から私の傾向として、何かが思い出せない時にかわりに出てくる言葉がかなり音に引っ張られたりするので、
付き合いが長いとその辺りからぼんやりと「なんかマ行多めに言ってるから多分ムーンなんやろなあ」「バって一杯言ってたし疑問形だし、バージョンかなあ」とかそういう感じに想像していたらしい。
今回の件とは関係ないけれど「ヤバイ」の派生だけで10分会話してみようという遊びをして割と不自由なく意思疎通できてしまったり、
「次にお前は○○と言うゲーム(予想がついたらハモる遊び)」で正解を連発してお互いに気持ち悪がったりしたこともあるので、理解度が割と高いのだと思う。
どちらにせよしょうもない実験にも付き合ってくれるし、双方が相手に干渉しすぎないのが分かっていて気楽にいられるので、大変貴重な友人であることには変わりない。
IntelコンパイラにしろVSにしろ有償のものは使いやすいけどね。会社に買わせるか経費で買うものだとは思う。
ただ、使ったことがない人は使うといいと思う。
Intelコンパイラ(VTuneなど含む) Visual Studio Perforceの３つは少なくともお金を出して使いたい。
モチベーションが高いといっても、お金を稼ぐことに対するモチベーションか、プログラムに対するモチベーションかで大きく変わると思う。
大抵は、お金か、名誉だろうから、それならWebプログラミングをやればいいと思う。
これからは、９割のプログラマーは何がしかの中間言語 JavascriptやPHPなどをやることになるだろ。それならツール群はいらん。
