  |
はてなキーワード: Lispとは
あるところに、おじいさんとおばあさんが住んでいました（むかしむかしの話）
おばあさんが川でせんたくをしていると（ちなみにおじいさんは山へ芝刈りに行った）、大きな桃が流れてきました（ドンブラコ、ドンブラコって感じで）
おばあさんは大きな桃をひろいあげて、家に持ち帰りました（家で食べるつもりだった）
そして、おじいさんとおばあさんが桃を切ってみると、なんと中から赤ちゃん（元気の良い男の）が飛び出してきました。
「これはきっと、神さまがくださったにちがいない」
おじいさんとおばあさんは大喜びです（おじいさんとおばあさんには子どもがいなかった）
おじいさんとおばあさんは（桃から生まれた男の子なので）桃太郎と名付けました。
＿＿
たとえば野球とかのスポーツをするとき、そういったものだけやっても身につくわけ無いのは誰でもわかるでしょう。でも、アスリートとしてのトレーニングをしていてある程度技術があれば、そういうものをやったことで大きく能力を向上させられる。
IT"技術"だって一緒。そういったものが活用できるには、当人が日々トレーニングを続けていて基礎技術能力を持っている必要がある。
こういった基礎自体にかける人は、勉強という視点ではなく、技術習得という視点で考えてみる必要がある。
少なくとも、自己啓発本とかビジネス書とかをたくさん流し読みする様なやりかたは、技術習得とは真逆にあることは確実だから。あのことも知ってるこの人も知ってる、でも自分では何もできない、ってのになるだけ。
技術とは一つのことを何度も視点を変えながら繰り返すような事が必要で、まずはそういった繰り返しこそが技術が磨く手段であることを認識して、同じことをやって無意味とは思わないようなマインドを持てるようにする必要がある。
FizzBuzz, Brainfuck、LISP、scribble、lifegame、echoサーバ、などなど、そういったシンプルでも濃い技術要素を扱うプログラムを少なくとも１つは自分の中で習熟するのだ。そして、次々出てくる様々な新しい技術を適用しながらこの同じものを何度も書くことで、体に覚えさせている。
これはスポーツで言えば実戦形式での練習の積み重ねである。アプリケーションを作るのはスポーツで言う試合のようなもので、基礎がないのにただ試合に参加ばかりしたところでうまくなどならない。
結局やるにはやると思います
ライブラリが少なくて不安という気持ちがあるんですけど、これは単にライブラリが無ければ自分で作る、という覚悟がないだけなので、本当にやりたかったら自分でライブラリ作ると思うんですよね
それに実際調べたらHTMLパーサもDBドライバもlispのライブラリにあったし(笑)
プログラミングパラダイムには自分がそれに合わせていくのので問題ないと思います。その辺は最初からそれの感覚を身につけるつもりでした。具体的にそれが何かも分かってませんが
どうしてもやりたいなら好きにしなよとしか言えない。
増田もSQLは使うんだろ？あれは関数型パラダイムともいえる。SQL得意じゃないならlispも向いてないかもしれないぞ？
元々phpから入ってruby on railsの流行に乗って趣味でrubyやってて一度プログラミングから離れてた
最近本の整理しててハッカーと画家を読んでハマって全く読みこなせかったポール・グレアムのon lispを手にとった
本当になんとなくの気持ちからlispを極めたいという気持ちになった
全く読みこなせかったのが悔しかったのもあるし、読みこなせなかったながらPGの今まで書いた記事を読めば読むほどこのlispというものがとてつもないものなんじゃないかと思うようになったのもある
lispについての概略を知れば知るほど自分の中の厨二をくすぐられる
・60年前のITの速度感で言えば古代のプログラミング言語なのに最新のプログラミング言語はlispの真似をしてるだけで追いついてない
・マクロとCLOSという機能がありそれを使いこなすと強力過ぎて他のプログラミング言語には戻ってこれないらしい
・しかもそのマクロという機能は他のプログラミング言語には絶対に真似できないらしい
・その真似できない理由が()を多様するプログラミングの文法に由来するから
・()を多用するがために他のプログラミング言語の学習者からするとかなり難しく見えるらしい
・マクロというのはプログラムを作るためのプログラムらしい。元々AIがプログラムを作ることを想定してたとか
こんな俺たち(?)の厨二心をくすぐるプログラミング言語ってあるか？絶対に無い
lispを使いこなして他のプログラマが1ヶ月で作るものを1日で作るとかマンガか何かみたいなことがしたい！絶対したい！！
で、俺が今やってることと言えばプログラミング言語というものが何をできるか調査するためにrubyで色々作っているところ
HTMLパーサーとかDBドライバをlispで作るためにrubyのパーサーとかドライバのコードを読んでると、自分が一体何をしてるのか分からなくなる
もちろんそれですぐに飯が食えるようになるのはrubyだ。給料もそれなりに良い。lispの求人を見たことは今まで一度もない
だけどこれもなんとなく遠回りでナンセンスな感じがしてる
直接lispを学ぶのが良いのか、急がば回れでrubyを熟練するのが先か、どうなんだろうか
プログラマーの皆さん教えてください
その１、休暇
しかもその10日から夏冬の大型休暇の歯抜けを捻出しないといけないとかあり得んでしょ。
大企業だとちゃんと９連休が有給の外で設定されてんのにだよ。何じゃそりゃ。
その２、ツール
誰かはLTだったり、課長が2009使ってたり、共通PCに2007のmechanical入ってたり、
新人は最新版使ってたり。そんで新人が最新機能を使いこなして作業短縮すると
一番古いのに合わせるわけだからモジュール化が一切進んでない。１図面に何でも収めちゃう。馬鹿か。
LT以前の知識しかないからマクロ＝LISP。それLTじゃ動かねえんだけど。一体何を考えているのか。
まぁよくありそうな話なので割愛
英語がつらい。
やっぱり辛い。
たぶん幼稚園の英語でなんかやってたみたい+中高6年間+浪人自体の英語特訓+大学の英語+趣味や業務での英語学習.....ずっとやってきたけどつらい。
英語を読むのが辛い。俺は理系なんだが、文法の問題とか、すごく得意で、毎回高得点を取れるので、英文法はできると思うんだが、単語が覚えられない。いや、中学高校の単語帳に乗ってるようなものは覚えてるよ。けど、英語でさ、技術系の論文読むときに、わけわからない単語が出てくるんだわ。そのさ、その時に辞書引くじゃん? 今は、んでさ、調べている間に、読んでた内容がすっとんじゃうわけ。
もっとつらいのは、知ってる単語、その文の主語とか文法は分かるんだけど、その一文の意味がさっぱり分からない時があって、それもつらい。その時ってのは、その文自体が、なんか特別な言い回しだったりするわけ。まんま、なんか流行ってる言い回しなら調べたら解決する場合があるから、良いけど、ちょっと捻ってるのわからない。どうすりゃいいんだ。
もっとつらいのは、英語の聞くときだ。本当にわからない。いろんな方法を試したんだけど、ほんとうにダメ。無理。ほら、TEDやら5分のニュースあるだろ?あれ、僕全然持たないんよ。その最初は、頭の中で、英語の文をつくる感じになるじゃん? そして、日本語にすんの。なんというか、英語の音=>英文=>日本文=>意味みたいな流れをずっとやってるわけじゃん? あれできるやつどうやってんの? 大分負荷が高いよね? 1分ぐらいで頭が沸騰するんだよ。
いや、もうだめ。英語。ほんとダメ。同僚はすごくできるのに。いくら、日本語で書かれた難しい技術が理解できたってダメだと思うんだけど、もうね、ダメだと思う。
「型システム入門」「分散システム」「On Lisp」「ガウディ本」「メイヤーのオブジェクト指向入門本」....いろいろ日本語の本であるならば、全然読めるんだよ。けど、英語が読めねぇんだよ。
なんで、こんなに英語がダメダメでも、いろんなライブラリ使えてきたかって、実装を読めば分かるじゃん。英語のドキュメントは読めないけど、コードを読めば、どう動くか分かるじゃん。だから、なんとなってるけど、限界を感じてきたんだよ。なぜかって、仕様なのかバグなのか分からないんだよ.......だから、英語の仕様読むしかないんだけど.....本当につらい。
プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか？
ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミングの本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。
そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。
最近になって、プログラミングの義務教育必修化の話題とか、コピペプログラマーの話題とかを目にするたびに、かつて自分がプログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。
だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。
ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生のときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ（文章を入力する専用マシン）が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分も小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気屋からはワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分はパソコンという存在に興味を抱くようになったのでした。
とはいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニーも独自にパソコンを作っているぞとか、そういう情報がパソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品の一種であり、ラジカセとかテレビと同列の存在でした。
なんでこんな話がプログラミングにつながるかというと、ひょっとして自分がプログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコンを電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。
ラジカセなら、CDだのテープだのを入れて再生ポタンを押せば、そのハードウェアの機能を物理的に体感できます。それに対してパソコンは、プログラミングをちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログの商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為とハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。
もし自分のスタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。
ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。
プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICのインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書や雑誌のコードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的に自分で目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して（まだインターネット検索は使い物にならなかった）適当にコードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。
この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思います。ちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚。プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンとサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります。
自分はバカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。
そんなこんなで、自分はまともにプログラミングを経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事でパソコンを日々使うようになってから徐々に変わっていきました。
具体的には、パソコンが、自分の中で「カタログの商品」から「武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。
武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上の課題を打開しました。それなりに計算機科学の教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。
結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間が必要だったことになります。自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子どもも少なくないんだろうなあ。それは不憫だなあ。
かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときにたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います。
オチがないので、このへんで。
全部説明せなならんのかとちょっとガックリ来てる。「待ってた」じゃねーよ。
違うって。区別する必要あるんだよ。あくまでも主体はエイベックスってことは認識しておかないと話が進まない。
前も書いたように、プリリズのアニメで最初から製作委員会に入ってるし、主題歌以外の楽曲もエイベックスから発売してる。エイベックスサイドから見れば、出資比率の違いはあっても、WUGもプリリズも、自分でお金を出して自分で売るIPだという点は全く同じ。
というのは、一体何を見て言ってるのかと言わざるを得ない。
プリリズが始まった時に主題歌と主演を担当していたのはLISPだった。
もちろん、LISPも81とエイベックスのプロジェクトである。そこだけ見ればWUGもi☆Risと同類であるが、決定的な違いがあった。
LISPは「有り物を集めて作ったユニット」で、まあ傍から見てても本気で売るためには色々問題点があったのは見て取れた。
いやもしかしたらLISPは素晴らしいユニットだったと信じている人も世界にはいるかもしれないが、オーロラドリームの放送開始2ヶ月でユニット活動停止発表とか、普通だったら「正気かよ！」と全力ツッコミ入るレベル。
なのに当時の玄人筋の間の空気感は「まあそりゃそうだよな」の方が多数だったと記憶している。
こっから先は単なる憶測だが、当然、エイベックスの中の人としては
「やはりアイドル声優ユニットを本気でやるには、ミュージックレインのように大規模公募型オーディションを開催してユニット活動を前提に新人を集めるしかない」
そういうわけでまだオーロラドリーム放送中の2012年2月からアニソン・ヴォーカルオーディションが始まります。
といってもアニメ2期ディアマイフューチャーには絶対に間に合わない。
エイベックス的には座組から抜けるわけにも行かないので、まあ実写パートとか韓国資本参入とかいろいろありました（遠い目）。
2012年7月にひっそりとi☆Risが結成されるわけですが、まあ大昔の代アニ全盛期みたいな荒っぽい時代だったら、ゴリ押しで素人のままアニメに出していったんでしょうけど、そんなのが通る時代でもないのでみなさん81の養成所での演技訓練が本業です。
…というわけにも行かないので、いろいろなラジオ局とかレコード会社とかの暇なプロデューサーがよくやるメソッド
「養成所を卒業したばかりの新人や養成所在籍中の子を適当に見繕ってアイドル声優ユニットというていで活動させる」
も発動。
演技力も歌唱力もまだまだ発展途上な子ばかりだし、プロモーション予算もそんなにあるわけじゃないから、ゲリラ的な活動しかできないのもよくあることです。
それらのユニットは9割方、何かのまぐれ当たりを期待する低予算低労力の数打ちゃ当たるプロジェクトだけど、今回は違う。
初期投資が大きいので、いずれ訓練が終わったら、エイベックスが金出してるアニメを使ってガッツリ売り出す気満々であるわけです。
2013年4月にアニメ3期レインボーライブ開始。ここでようやくまず一人だけ、芹沢優が出演。本当は全員出したかったのかもしれないが、時期尚早との判断だったんでしょう。
そういうわけでTRFとコラボったり、赤尾…じゃなくて三重野瞳が山ほど歌詞を書いてるうちに1年終了。
この間、6人全員が一応声優デビューして場数も踏んで、そしてたぶん音楽面のレッスンも順調だったんでしょう。
念のために3ヶ月の準備期間を用意して茜屋日海夏にみんなを馴らしてから（いや逆か）、満を持して2014年7月から主演i☆Ris、主題歌i☆Risなアニメが始まったわけです。
アニメを作るのに必要な時間の長さを考えれば、ほぼ全作業がプリパラと同時並行で進んでいると言っても過言ではない。
要するに元増田が「WUGの成功を見てi☆Risも同じ売り方にした」的な物言いは確かに間違いなのだが、無関係というのも間違い。
実際には単に「同時期に、同じレコード会社がお金を出し、両方とも同じような売り方をしている」でしかない。
あえて違いを指摘するとすれば、WUGの方が中の人とキャラのシンクロ度が高くて演じやすい分、デビューまでの期間を短縮できた程度の差である。
---
1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。
プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社に就職した。
会社に入ると、まずC#の研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。
研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、これが全く意味不明で、何のために有るかがわからないクラスが大量にあった。名詞の王国だと思った。前任者に、何故このクラスは、この単位で分割されているのか聞くと、「単一責任の原則だよ」とか「hogeパターン使うと、後から機能追加しやすいじゃん」というような回答をもらった。納得は出来なかったが、プルリクも承認されて、このツールがデプロイされていたので、社内的にも、このコードは、クソコードと言われる物では無いはずだと思ったので、自分もプログラムを書き続けていれば、こんな感じの設計に慣れてくるんだろうと思った。モヤモヤは残っていたものの、仕事はしなければいけないので、前任者のコードに習うように、クラスを追加したりして、機能を追加した。プルリクを出すと、設計には何も言われずに、タイポや、テストコードを注意されただけだった。指摘された点を修正すると承認された。振られた仕事は完遂した。が、結局最後まで、モヤモヤは消えなかった。むしろ、モヤモヤモヤモヤになった。
次に振られた仕事は、内製ツールを設計から自分で行い作成する仕事だった。言語はGoだった。Goで書いてと言われた時は、以前からの自分のモヤモヤはオブジェクト指向のせいで、モヤモヤしているんじゃないかとも思っていたので、喜んで！という感じであった。が、Goを触ってみると、結局、Goも継承の無いオブジェクト指向言語やないかと思った。Goの標準ライブラリのinterface名もHogerみたいな感じに接尾辞に-erを持ってくることが慣習らしく、この命名だと、interfaceを満たす構造体自身が-erになるので、正にオブジェクトだなぁと思った。巷での「Goはオブジェクト指向ではない」というのに期待していたのだが、自分にとっては、とてもオブジェクトしていました。
Goに対する印象は良くなくなったが、ツールの設計をしないといけなかったので、Goの構造体をC#のクラスに見立て、前回の前任者のコードのように、単一責任も持つ構造体に(無駄に)分けて、プログラムを書いて、プルリクを出した。自分でクソなコードだと思いながら。だけれどもレビューでは、「errorのチェック忘れ」「標準ライブラリにこの機能ある」「こんな風に書ける」といった感じだった。こんなコードで良いんかよと思ったが、良いらしい。ワケワカメだった。
ここらで、プログラムを書く仕事は、無理だと悟った。現実世界は、自分が自然だと思う方法と違う方法で、プログラミングをすることを強要してくる。
ちなみに、仕事ではC#とGoを書いていましたが、オブジェクト指向と仲良くなるためにSqueak(Smalltalk)で、オレオレ言語を作ってみたりもしましたが、何が嬉しくて、オブジェクト同士のメッセージパッシングでプログラムを作るのかわかりませんでした。
Clojureは、気持ち良くプログラムを書いていても、Javaが顔を出すところでフラストレーションが溜まってしまって、つらくなりました。
Common Lispは、自分が触った言語の中でも、秀でて良いと思いました。プログラマを辞めても、プログラム書く必要に迫られたらCommon Lispで書こうと思うくらいにです。Land of Lispが楽しいです。あと、CLOSの総称関数の考え方が大好きです。
最後に、この投稿は、一種の決別の表明です。いつまでも、自分に向いていなかったことに、時間を掛けてしまっている自分との決別です。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
東大基礎科学科卒。過去250～340年間世界の大数学者達が解こうとして解けなかった、世界史的数学難問4つを解き、現在ロシア科学アカデミー数学の部で審査中。マスターした11ヶ国語を駆使したプロの通訳・翻訳家。矛盾だらけの現代物理学を初め、全科学（自然、社会、人文科学）の主だった物を体系的に批判し各々に別体系を提起。各種受験生(医学部、難関大学入試、数学オリンピック、社会人大学院入試、IT関連資格)支援。
■経 歴
2002年 （至現在）セント・クレメンツ国際大学 物理学教授
2001年 英国系セント・クレメンツ大学で数理物理学の博士号取得
2002年 ロシア科学アカデミー・スミルンフ物理学派論文審査員となる
1999年 英国系ウィットフィールド大学でコンピュータ科学人工知能の博士号取得
1991年 （～1993年）University of California、 Irvine人工知能研究所で確率論批判・学習システムの研究
1988年 （～1991年）世界の認知科学の権威ロージャー・シャンクのCognitive Systemsのデータベース研究所IBSで自然言語処理研究
1986年 （～1988年）欧州先端科学研究プロジェクトESPRITにESPRITディレクターとして仏Telemecanique研究所より参加（生産ラインへの人工知能導入の研究）
1985年 西独ジーメンスのミュンヘン研究所で生産ラインへの人工知能導入の研究
1982年 （～1985年）[仏国]世界一速い列車TGVのメーカーAlsthom社の知能ロボット研究所
1981年 （～1982年）[仏国]グルノーブル大学院、ソルボンヌ大学院で通訳の国家免状取得
1980年 （～1981年）[スペイン]マドリード大学院で言語学履修 西国政府給費留学生
■専門分野
数理物理学Ph.D.、コンピュータ科学人工知能Ph.D.、マスターした11カ国語を駆使したプロの通訳・翻訳家
■講演テーマ
「ビジネスマン、文系卒社員に理工系技術と技術的発明を評価できる眼を」
近年世界の大学でビジネス志向の学生向けに、理系の技術的な事がある程度分かるためのカリキュラム改変が始まっている。しかし申し訳程度であり、また理系の拠って立つ数学物理学の科学理論自体に欠陥が有る事が最近明らかとなっているため、正しい数学と物理学の粋を伝授し、文系でも本物の理系技術評価が出来るように支援する。
「英語を完璧に&現地語（非英語）を或る程度使えるマネジャー急遽創出と、社員の中から各国語通訳をネーティブに肉薄する敏捷性と正確さで急遽育成を支援」
海外のプロジェクトや企業と折衝するとき、英語がネーティブ並みであったり、現地語を自社のディレクター自身がある程度こなせるか、英語、現地語につきネーティブ並みの社員が通訳出来ると先方との話が大きく好転する場合が少なくない。それを本当に実現する教育訓練を私は提供できる。平明に説明し、実体験をしてみたい方がいらっしゃるなら講演会場で手解きをしてみたい。
「発見された言語学理論と外国語訓練方法論を基に、文科省と英会話学校の英語教育訓練方法論の根本的誤りの中枢を詳説」
統語法意味論、文脈意味論、実世界意味論の3レベルで進展するネーティブの母国語習得過程の中、言語能力の真の中枢は解説も無しに親の喋るのを聴いているだけで分かるようになる統語法的意味把握能力で、これは文法用語を全く使っていなくても徹底した文法訓練となっている。ネーティブが敏捷性、精度の点で万全であり、先ず文法的間違いをすることはない理由はここにある。全文法分野について書き換え問題の「即聞即答訓練」を一気に中学生以上の年齢の人に施し、全文法のビビッドな一覧性を習得させるとネーティブに肉薄する敏捷性と精度で外国語を使いこなせるようになることが発見された。
「＜証明された欠陥数学＞ 確率統計と微積分学のビジネス、金融工学、保険業界での使用に対する警告と、それに取って代る新数学体系」
我々物理世界は離散値の世界であることが原因で、物理世界に住む人間の頭脳が考え出した数学の中で連続実数値に基づく確率統計学と微積分学だけが欠陥数学として発現していることが証明された。決して建設的な予測をすることができず、崩壊していく事象に後ろ向きにしか適用できず、せいぜいリスク管理にしか使い道の無い確率統計学をビジネス学の分野では金科玉条の如く信用し積極的やり方で利用しているが、ここに「理論」と現実との間に大きな食い違いが生じている点に警告を発したい。そのためそれに取って代る新数学体系を提起する。全てを分かり易く解説します。
「新エネルギー・エコ向けの発想を大転回した技術的な重要な発明を提起」
20世紀初頭に数理物理学者Henri Poincareは二体問題までは解けるが三体問題(三つの星が互いに重力で引き合いながら運動している時の時々刻々の位置を計算で求める事)以上は微積分学を使って解く事が出来ない事を証明した。これは無限小差分を使う微積分は計算式中で交差する項をほぼ同等とみなして相殺してしまうため、作用反作用の法則(F1*v1=-F2*v2)の取り違い(F1=-F2が作用反作用の法則であると圧倒的多数が信じている)と相俟って、交互に対称な運動しか記述できないため、対称性の有る二体までは記述できても対称性のない三体以上は記述できないためである。この欠陥数学微積分を基に二体までは「エネルギー保存則」を証明したものの三体以上の「エネルギー保存則」は本来的に証明不可能であることが明らかと成った。現に永久磁石がエネルギー保存則を大きく超えることが実証され始めている。それらの実験につき具体的に物理学の素人の方々にも分かりやすく報告したい。
「世界史的体系的誤りに迷い込んだ現代物理学とその使用者への警告とそれに取って代る新物理学」
現代物理学の二本柱、量子力学と相対論の中、量子力学は水素原子の原子核と軌道電子の関係説明を辛うじて試みただけで、水素原子より複雑な原子や分子の構造の説明に実は悉く失敗し、繰り込み・摂動理論はその失敗を隠すため後に持込まれた。軌道電子は光速に比べ無視できぬ速度でクーロン力で原子核に引かれて急カーブしながら等速加速度円運動、大量のエネルギーを消費するが、半永久的に軌道を回る。しかしシュレーディンガーの波動方程式(その波動関数とその共役関数の積は確率)はエネルギー消費に一切言及せず、エネルギー・レベルが一定に保たれるという明らかに矛盾した論を展開する。また確率を持ち込んだからには、エントロピー単調増大法則がここに適用され、水素原子は瞬時に粉々に飛び散らなければならぬ現実に反する二つ目の重大矛盾に遭遇するが、これもシュレーディンガーは見てみぬ振りをする。つまり水素原子の構造の説明にすら量子力学は完全に失敗した。量子力学とは動力学でなく各エネルギー・レベルについての静力学でしかなく、「量子力学」の「力学」なる名前とは裏腹に力を論じられない。論じればエネルギー消費が起こりエネルギーレベル一定論が崩れる。
「現代のフォン・ノイマン型コンピュータ・アーキテクチャーの誤りと、創るべき新コンピュータ・アーキテクチャー」
現代のフォン・ノイマン型コンピュータの計算機モデルが取りも直さずチューリングマシンそのものである。チューリングマシンは決ったパラメータ数の状態間の遷移を静的モデル化したものであるのに対し、歴史的にその直前に発表されたアロンソ・チャーチの計算モデルのラムダ・キャルキュラス(人工知能プラグラミング言語LISPの言語理論でもある)は関数の中に関数が次々に入れ子のように代入されて行き擬パラメータが増えていくダイナミックな仕組みを持つ。この後者は人間が作ったコンピュータを遥かに凌ぎ、宇宙の始原から発生した環境データから関数をf1(t),f2(t),.,fn(t)と次々に学習し入れ子のように代入進化し、次の一ステップの計算には宇宙の始原からの全ての関数f1,f2,...,fnを思い起こし、そのそれぞれの差分を取って掛け合わせる事をしているコンピュータとも言える物理世界とその時間の学習・進化を時系列順に模写するのに持って来いの仕組である。関数と言っても多項式で充分である事を世界の7大数学難問の一つPolynomial=Non-Polynomialの私の証明も交えて平明に解説する。これは日本の国と世界の先進諸国のコンピュータ科学の今後の研究方向を左右する発言となる。
■実 績
【講演実績】
Trinity International University
「コンピュータ科学」 学士号コースの学生に卒業まで全コースを講義
St.-Clements University
「金融工学に必要な数学・物理学」の博士号コースの学生3年間に渡って講義、研究テーマと研究内容、博士論文のアドバイス
St.-Clements University
研究テーマ「コルモゴロフ複雑系の二進ビット・ストリングの下限＝Lower bound for binary bitstring in Kolmogorov complexity」の博士号コースの学生Dr. Bradley Ticeに英語でアドバイス
St.-Clements University
外国語学部のポルトガル語・伊語の通訳・翻訳の学士号コースの学生に教養学部のレベルから全社会科学（経済学、法律学、社会学、経営学）、人文科学（哲学、言語学、心理学、歴史学）、自然科学（数学、物理学、化学、生物学、医学、計算機数学）、エンジニヤリング（Information Technology、ソフトウエア工学、電気工学、電子工学）の各々の学科の全講義を行う。
Госдарственный Университет Санктпетербургской Гражданской Авиации (サンクトペテルブルグ国立航空大学)
物理学学会の論文発表会で幾多の論文の露語によるプリゼンテーション。
【メディア出演】
【執筆】
ti-probabilistic Learning by Manifold Algebraic Geometry, SPIE Proceeding, 1992 Orlando 等 人工知能学会論文
うぜえ。
計算可能性の理論やラムダ計算がLispを産んだように、プログラム意味論や圏論はHaskellを産んだ。
プログラム意味論では変数の型が議論の最小単位で、関数やプログラムはある型の変数を別の型の変数へ変換する変換器として記述される。
だから本質的に、型が無いとプログラムという概念が存在できないことになる。
で、このアカデミックな議論が普段書くコードにどう影響を与えるかというと、実はほとんど影響がない。
もちろん知っていた方がよりエレガントなコードを書けるだろうが、必須ではない。
圏論を知っている必要があるのは、Haskellを設計する人達だけだ。
閉包を意味するほうのクロージャの綴りはclosureなのだが、
それ、JavaScriptに変換されても.NETに行ってもjavaのjが消えないあのLisp方言だ…。
そんな間違いするなんてご苦労じゃー。
まぁ、関数型として専門的に作られているような奴は、大体デフォでカリー化ついてるけど、そいつらも要は裏ではクロージャ的なものを使ってる。
で、それこそJavascriptとかLispみたいな「関数型として、本当に最低限必要なものだけ揃えている」系列の奴等は、プログラマ側がクロージャ駆使して書いてあげる必要がある。
まぁ、関数型ばりばりの奴等ほど、色々至れり尽くせりの構文になっててベースを見せないので、あんまり意識してクロージャ使ってる、って感じにはならないけど、ベースにある所よくよく見ると、クロージャが出てくるって感じか。
http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html
http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html
この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。
Landin "A λ-Calculus Approach" (1966)
We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.
我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式の評価に関する環境から成る。
Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)
A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).
LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用な比喩になる。QUOTEは多孔的または開放的に関数をおおっていて、自由変数は現在の環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。
(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)
Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)
In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.
この問題を解決するためにクロージャという概念を導入する。クロージャはラムダ式とそのラムダ式が引数に適用されるときに使われる環境から成るデータ構造である。
Steele and Sussman "The Art of the Interpreter" (1978)
We say that the procedure is closed in the current environment, and the ＆PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.
この手続きは現在の環境に閉じられている(closed)と言い、それゆえ＆PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。
