いものやま。

雑多な知識の寄せ集め

お正月なのでいろいろ出かけてみた。

お正月ということで、初日の出を見に行ったり、一般参賀に行ってみたりした。

初日の出@大洗

初日の出は去年に引き続き、大洗で。

2016年から毎年行っているから、なんだかんだで4年目w
(2017年のときの様子はブログに書いてないけど、深夜の23時半にロードで出発して、超寒い中100km弱走るという地獄のような行程だった・・・)

年越し

基本的には去年と同じで、年越しそばを食べてから5LINKSを使って輪行し、コートホテル水戸へ。

f:id:yamaimo0625:20190105154656p:plain

ここはやっぱり優秀。
安いし、必要なものは一通り揃ってるし。

ジルベスターで年越しして、そのあと、去年よりは少しゆったりと5時まで仮眠。
まぁ、去年に引き続き、全然眠れなかったんだけど(^^;

それにしても、今年のジルベスターのアイーダによる年越しには、苦笑したw
演奏早くない?と心配しながら見てたけど、案の定15秒くらい余って、最後めちゃくちゃ長いロングトーンで誤魔化すというねw

出発

5時に起きたら、ちゃちゃっと軽く朝食を食べて、シャワーを食べて、チェックアウト。
5LINKの輪行状態を解除し、5時50分頃に大洗に向けて出発。

f:id:yamaimo0625:20190105155855p:plain

出るのが予定よりも遅くなってしまったので、若干焦りながら走っていたのだけど、無事6時半頃に大洗に到着。
日の出の予定が6時49分だったので、割とギリギリ(^^;

f:id:yamaimo0625:20190105160520p:plain

初日の出

そして、いつもの場所に移動して、初日の出を待機。
今年も雲がかかっちゃってる感じだったけど、なんとか切れ間から初日の出を拝むことが出来た。

f:id:yamaimo0625:20190105160535p:plain

潮騒の湯

そのあとは、いつも通り潮騒の湯へ。

f:id:yamaimo0625:20190105160652p:plain

途中、秋山殿を見つけることが出来て、テンション上がるw
「ひゃっほぉおお!」www

f:id:yamaimo0625:20190105160758p:plain

磯前神社

温泉に入ったら朝食を食べて、磯前神社へ初詣。

ここで、途中、秋山殿の立て看があるはずの年宝菓子店さんに寄ったのだけど、秋山殿がいない・・・

f:id:yamaimo0625:20190105161103p:plain

なんか「舞台めぐり」のQRコードはあったのだけど、やっぱり立て看を見たかったなぁ・・・

まぁ、何はともあれ、磯前神社へ到着。
そして、この行列である。

f:id:yamaimo0625:20190105161630p:plain

f:id:yamaimo0625:20190105161650p:plain

まぁ、去年もそうだったし、ね。
本を読みながら待ち、1時間くらいで参拝できた。

ガルパン喫茶@マリンタワー

初詣のあとは、これまで何度か行こうと思いつつ行きはぐっていた、マリンタワーにあるガルパン喫茶へ。

マリンタワーの2階にあるということで、低いところなのかな、と思っていたら、普通に高いところなのね。
展望フロアのすぐ下のフロアで、ビックリした。

入ってみると、ガルパン要素でいろいろ装飾されたお店になっていて、机やイスは学校にあるようなヤツw
メニューをパラパラと眺めて、るるぶにも載っていたサンダースのハンバーガーに、聖グロリアーナのダージリンのついたセットを注文してみた。

f:id:yamaimo0625:20190105162412p:plain

ハンバーガーは・・・うん、まぁ、普通w
ナイフとフォークがついてたけど、そんな上品な食べ方は知らないので普通にがっついて、汁でけっこう手が汚れた(^^;
ダージリンの方は量もタップリで、ちょっとビックリ。

ちなみに、他にもいろいろ料理があって、サバの味噌煮定食なんかも。
なんか普通すぎるのでやめてしまったけど、大洗なので地味に美味しそう・・・
あと、カレイのフライが乗ったカレーとかもちょっと興味深かった。

田んぼアート

そのあとはお土産を少し買って、大洗駅から輪行で帰宅。

で、その途中でぼぅっと田んぼを眺めてたら、突然「とっかん!」の文字が!
さらに、いろんな田んぼアートがあったり。

f:id:yamaimo0625:20190105163710p:plain

すごいな、大洗・・・

一般参賀

一夜明けて、1月2日。
平成最後の一般参賀ということで、行ってみた。

混むだろうと思ったので、早めに出ようと思っていたのだけど、何だかんだで遅くなってしまった。
電車で移動し、東京駅に着いたのが12時半頃。
軽く昼食をとってから、皇居へ向かった。

で、着いてみたら、想像以上の行列・・・
まさかこんなに混んでいるとは・・・

f:id:yamaimo0625:20190105164638p:plain

思わず「コミケ5日目」とツイートしたけど、この風景は昔コミケで東駐車場に作っていた待機列を連想したw

で、並んだはいいものの、それからいっこうに列は動かず。
13時半予定のお出ましの時間はあっという間に過ぎ、さらには最後のお出ましの14時20分になっても列は動かず・・・

列が動き出したのが、14時半近く。
これはダメかなぁ、と思ったのだけど、陛下のご意向で、お出ましの回数が増やされたみたい。

ゾロゾロと行列で進み、広場?に入ってみると、こんな感じ:

f:id:yamaimo0625:20190105171835p:plain

まさにギュウギュウ詰めw

そこから後ろの方の僅かな空間を押し合いへし合いで進み、下手するとこのまま出口まで押し出されるんじゃないか、という感じだったのだけど、なんとか良さげな場所に陣取ることが出来た。

そして、両陛下、ならびに皇族の方々がお出まし。

f:id:yamaimo0625:20190105172222p:plain

陛下が「年頭に当たり、我が国と世界の人々の安寧と幸せを祈ります」と述べられ、日本だけではなく、世界の人々のことも気にかけられていて、素晴らしい人だなと思ったり。
平成は無事戦争もなく終わりそうだけど、次の時代も平和が続いていくといいな、と思った。
もちろん、そのためには、「憲法9条を守れ」というお題目を何も考えずに唱えているだけではダメで、しっかりと歴史を反省し、積極的に平和を維持するための行動をとっていかないといけないわけだけど。

ちなみに、この後さらに1回お出ましを増やされたとか。
合計15万人強が訪れたとのことで、冬コミ1日目の参加者が約17万人だったことを考えると、ホントにコミケ並みw

神田明神

一般参賀を終えた後は、東京駅に戻り、そこから秋葉原へ。
そして、神田明神に行ってみた。

f:id:yamaimo0625:20190105174304p:plain

実は、神田明神に行ったのは初めて。
こんなところにあるんだねw

そして、思った以上に立派な神社でビックリした。
普通に参拝客も多く、また行列に並ぶことに(^^;

行列に並んでいたら、なんか獅子舞とかもやってた。

f:id:yamaimo0625:20190105174804p:plain

そして、けっこう待ったあとにやっと参拝。

f:id:yamaimo0625:20190105174845p:plain

そのあとは、境内を少し眺めたり、御朱印をもらったり。

それにしても、いろいろ飾られてるのねw

f:id:yamaimo0625:20190105174959p:plain

f:id:yamaimo0625:20190105175017p:plain

純子ちゃん、やーらしかw
ゾンビランドサガ、ぜひとも二期やってほしいなw

今日はここまで!

新年の挨拶と今年やっていきたいこと。(2019年)

あけましておめでとうございます!
今年もよろしくお願いします!

f:id:yamaimo0625:20190103114845p:plain
初日の出@大洗 with 5LINKS and

ということで、今年やっていきたいことのリストアップ。

体調管理

去年の振り返りでも書いた通り、体調を整えるのがまずは急務だったりする。

もう体がボロボロで(^^;

具体的には、以下のことをやっていくつもり:

  • ジムに通って、体力の回復
  • 整体に通って、体の歪みの矯正
  • 規則正しく寝て起きる

ジムには去年の10月から行っているのだけど、それなりに泳いでも筋肉や関節は痛くならない程度には、やっと回復してきている感じ。
ただ、まだまだ泳げる距離が伸びていないので、伸ばしていきたいな、と。

ネットで調べたら、TIスイムなるものがあるらしく、これがかなり魅力的だった。

「魚のように泳ぐ」というのをコンセプトとしていて、効率よく、楽に長距離泳げるようになることを目指している。
この泳ぎを身につけていきたいな、と。
そして、クロールで500m、平泳ぎで1kmは泳げるようになりたい。

で、体力を回復しつつ、体重を減らして行きたいな、と。

技術

技術に関しては、去年に引き続き、データフロー指向に関して調べて、アウトプットを出していきたい。

Lucid本の翻訳、pLucidのコードリーティングとリファクタリングは引き続き行っていく予定。
まぁ、何はともあれ、体力を回復して、そのための時間を作らないとだけど。

そして、出来れば何かお試しで言語作ってみたいなぁ。

あとは、転職も考えて、他の技術もちょこちょこ勉強していきたい感じ。
特に、先に繋がるように、Armに関しては一度がっつり勉強したかったり。

他、『現れる存在』の関係で制御理論についてもホントは勉強していきたいんだけど、さすがにそこまでは無理かな。

今日はここまで!

ブログの今年一年を振り返ってみた。(2018年)

毎年恒例、ブログの1年の振り返り。

全体

まずは全体的なところから。

更新頻度

去年にも増して酷かったので、もはやなんとも・・・
これに関しては、あとで別項で。

内容

肝心の内容に関してはというと、以下のような感じ:

  • 技術
    • pLucidの紹介
    • Lucid本の翻訳(途中)
    • Karabiner-Elements
  • ゲーム
    • トリックテイキングゲーム関連
  • 自転車
    • お花見ライド
  • 哲学
    • 読んだ本の紹介
  • その他

うーん、少ない(^^;
昔のブログで書いた記事の紹介とかもやらなかったからなぁ・・・

アクセス数

当然、アクセス数もだいぶ落ちてる。
以下のような感じ:

ユーザー セッション
1 7675 9066
2 5832 7243
3 7257 8521
4 8086 9519
5 7677 9406
6 7240 8688
7 7173 8676
8 6860 8213
9 6550 7507
10 6538 7560
11 5897 7050
12 5418 6522

(※12月は12/29まで)

まぁ、緩やかな減少で済んでいるだけ、まだマシとも言えるけど。

今年の目標の振り返り

次に、今年の目標の振り返り。

更新頻度を上げることと、コンパイラと実行環境周りに関してアウトプットを出していく、というのを目標としていたわけだけど、更新頻度に関してはダメダメ。
ゲームとアニメに割く時間はだいぶ減らしたんだけどね。
一方、コンパイラと実行環境周りに関しては、データフロー言語であるLucidの紹介と、その本の翻訳を少しだけ出来た。
実装のpLucidのコードリーティングとリファクタリングに関しても、ちょっとだけ実施できた感じ。
まぁ、なかなかまとまった時間をとれなくて、進捗にすると20%程度くらいだけど。

人気の記事

人気があった記事に関しては、去年と同じ感じ。
まぁ、更新してないからねぇ・・・

今年書いた記事で上位に入っていたのは、以下の通り:

封印されたカードの考察がけっこう読まれていたのは、嬉しいw
あと、Karabiner-Elementsの記事もけっこう役に立ててるのかな?

一方、確認してみると、Lucid関係の記事はほとんど読まれてない・・・
割と書くの大変なんだけどなぁ・・・
まぁ、「忘れ去られた言語」なので、仕方ないとも言えるけど。

体調とか仕事の話

さて、後回しにしていた更新頻度に関する話について。

前述の通り、ゲームとアニメに割く時間というのはだいぶ減らしたのだけど、なかなか更新する時間と気力が足りなかった。
原因は、今年はやたらと体調を崩していたのと、仕事が忙しかったり燃え上がったりしていたから。

体調に関しては、去年の記事にも書いた通り、去年の9月に自転車で筑波山に行ってから低空飛行の状態が続いていて、さらには今年1月に風邪を引いてなかなか治らなかったり(おそらくインフルだった)、3月〜4月頃はずっと鼻水とくしゃみが止まらなくて死にそうになってたり(おそらく花粉症・・・けど、そう認識していなかったので、何の対策もしてなかった)。
花粉症だったのに何も対策無しにお花見ライドするとか、完全に自殺行為だった・・・(ライド後に鼻と喉が死んでいたのは、おそらくこれが原因)

極め付けは、8月末に朝起きたら、左足首がめっちゃ痛くて、歩けなくなるというね。
特に足を痛めるようなことはやってなかったので、何だこれと思いながら杖をついて病院に行ったんだけど、「おそらく痛風でしょう」と・・・
えぇぇ・・・
尿酸値自体はそこまで高くはなかったんだけど、中性脂肪コレステロールの値が高く、お医者さん曰く、これらの数値が高いと尿酸値も高まることがあるようで、状況証拠的に痛風でしょう、と。

そんな感じで、割と体がボロボロ・・・
自転車にも乗れていなかったので、体力もめちゃくちゃ落ちてしまっていて、悪循環・・・

これはアカンと、10月からジムに行って泳いだりするようにしているんだけど、いや、体力の落ち方にビックリした。
小さい頃から水泳をやっていたので、泳ぎには自信があって、平泳ぎならいくらでも泳げたんだけど、泳いでいると泳ぎの負荷に筋肉と関節が耐えられなくて、痛くなってくるというね(^^;
疲れも抜け切らなくて、仕事に遅れて行ったりが恒常化してしまったり。

一方、仕事の方も、とあるプロジェクトでリーダーをやっていたんだけど、名ばかりリーダーというか、ボスの力が強いので、プロジェクトをコントロールするのがほとんど出来ず、スコープが膨れ上がってしまって、結果、炎上。
この詳細や反省については別途書きたいと思っているんだけど、それはともかく、前述の通り、体力が落ちている状態で炎上したので、その火消しで無茶をしているうちに、反動で完全にダウン・・・
そして、戦線離脱という有様になった。
いや、ホントに酷かった・・・

とりあえず一つ言えることは、自分の舵は他人にとらせるな、ということ。
他人が責任を取るならいざ知らず、自分が責任を取らされる状態なのに自分では舵をきれないという状態になってしまうと、ニッチもサッチも行かなくなる。
就活のグループディスカッションで、このあたりは一度経験して反省してるんだけどねぇ。

まぁ、そんなこんなで、体力的に完全にダウンしてて、仕事もちょっと燃え上がり、挽回するためにジムに通い始めたりなどで、ブログにかける時間をほとんど確保できていなかった、というのが、更新頻度が落ちていた一番の原因。
何をするにもまずは体が資本なので、体力を回復させて、更新頻度を上げられるようにしていきたいと思う。

今年出会えた素敵な作品たち

そんな感じで、体調と仕事に関しては酷い状態だったわけだけれど、一方で、今年は素晴らしい作品や本に出会えた年でもあった。
ブログで紹介できてないのが残念だけど。

まず、何と言っても『リズと青い鳥』。
これが本当に素晴らしかった。

これほど繊細な作品がこれまでにあっただろうか、と思わされる作品で、本当に素晴らしいの一言。
静かな空間の中で、一音一音を拾いながら、そして、一挙手一投足を見つめながら、見守りながら、観ていく作品となっている。
なので、これは生活音が溢れる中ではなく、劇場で観たいと思わされる作品で、思わず10回近く劇場に足を運んでしまったw
ここまでリピートした作品は初めてw
このブログでも紹介記事を書こうとしてたんだけど、なんというか、尊すぎて、言語化するのを諦めた(^^;

アニメも、観る本数はだいぶ減らしてたけど、いいアニメがけっこうあった。

まずは『ゆるキャン△』。

ゆるキャン△ 1 [Blu-ray]

ゆるキャン△ 1 [Blu-ray]

30分があっという間に感じられる、とてもいい作品。
思わずマンガも電子書籍で全部買ってしまったw

そして、何と言っても『ゾンビランドサガ 』。

いやー、初めは設定がぶっ飛んだただのイロモノアニメかと思ったけど、ギャグあり、感動ありで、ゾンビ設定をうまく活かしていてとても素晴らしかった。
ドラ鳥めっちゃ行きたいw

他にも、『からかい上手の高木さん』『citrus』『ガンゲイル・オンライン』『ゴブリンスレイヤー 』『SSSS.GRIDMAN』とかもいい作品だったなぁ。

citrus』はマンガがキレイな最終回を迎えていたのが印象的。

citrus (10) 特装版 (百合姫コミックス)

citrus (10) 特装版 (百合姫コミックス)

特装版の付録の小冊子、とてもよかったw

哲学(?)の本では、ブログでも紹介したけど、やはり『現れる存在』がとてもよかった。

この本を読んで、人工知能に関して新しい展望が見えたと個人的には思ってる。
統計でも最適化でもない、制御という観点からの学習理論の構築というのが出来るんじゃないかな、と。
まだ基本的な理論も作れていないし、試すにも至れていないけど。

あと、以下の本はいろいろと考えさせられた:

マインドセット「やればできる! 」の研究

マインドセット「やればできる! 」の研究

やってのける~意志力を使わずに自分を動かす~

やってのける~意志力を使わずに自分を動かす~

これらの本は、数年前に紹介してもらった本なんだけど、なんだかんだで読んでいなかった。
ただ、前述の仕事でいろいろダウンしていた時に改善できないものかと読んで、すごく感銘を受けた。
「しなやかなマインドセット」ーーなるほど、という感じ。

ただ、そこから立ち直るにはやっぱり体力が必要で、何はともあれ体力を戻すのが先かな、という状態。
それに、改善しようにも、舵を握れていない状態だと、改善したくてもそのための行動をとることが出来ないので、心が死ぬんよね。。。

この本もあとでブログでちゃんと紹介したいな。

それと、次のような本も読んだり:

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

正直なところ、自社の製品を自信を持っていいと言えるかというと・・・
思ったよりも市場で評価されてるというのは今年分かって嬉しかったんだけど、やはり自分自身がいいと思えないものを世の中に出してしまっているというのは、心に引っ掛かりがある。
仕事だから、と割り切れれば楽なんだけどね。

ただ、自分のやりたいことがやれる、作りたいものが作れる会社があるのかというと、うーん、という感じ。
データフロー言語や人工知能に関していろいろやりたいわけだけど、Lucidの記事の需要のなさも省みると、ね。
需要を作り出してビジネスになるまで持っていけないと、なかなか。


まぁ、そんなこんなで、体調を崩したりもしたけど、いい作品や本にも出会えたし、実り多い一年でもあったかな、と。
今年の経験を活かして、いろいろいい方向へ変えていけたらいいなと思う。

今日はここまで!
良いお年を!

2018年に初めて遊んだゲーム、ベスト3。

2018年に初めて遊んだゲームで、特に気に入ったものを選んでみた。

これまでのは、以下から:

ただ、あらかじめ書いておくと、今年は去年にも増してゲームを遊べていなくて、これから挙げる3つも、「今年遊んだ中では」という感じがちょっと拭えない・・・
なので、去年までに比べると、オススメの熱が低めかも。

第3位「カマリ」

f:id:yamaimo0625:20181230161049p:plain

去年2位にした「アノウ」の作者である与左衛門さんの新作トリックテイキングゲーム。
詳細は以下から:

かまり」とは忍びの斥候のことで、プレイヤーは「かまり」となって、城奥深くまで忍び込むことを目指す。

具体的には、「城下」「二の丸」「本丸」「天守」「奥の間」の5つの戦場が用意されていて、プレイヤーはそのどれか1カ所で戦うことになる。
最初に手札が3枚配られ、戦いは城下から順に始まっていき、プレイヤーはその戦場で戦うか、それとも、その戦場は見送って次の戦場に進むかを選ぶことになる。
進めば進むほど高得点が期待できるのだけど、その分競争率が高くなるので、自分の手札の強さと相談して、どこまで進んでいくのか決めることになる。
これがなんとも悩ましくていい。

また、このゲームは対応人数の多さも魅力的。
最大10人で遊べるトリテというのは、かなり珍しいと思う。
そして、大人数で遊んだ方が楽しいw

ディールに参加するか、それとも降りるかを選択するゲームとして、自分の知っているものだと「ルー」や「Ushter」があるけど、それらはいずれも降りたらそこで終わりで、次のディールは新しく手札が配り直されれる。
けど、この「カマリ」は、降りた(見送った)場合、その手札のまま次の戦場に進む、というのが独特で、非常に面白い。
そして、これが謎の駆け引きを生んだりw
この面白さは、実際に遊んで体験してみてほしいなぁ。

第2位「111」

f:id:yamaimo0625:20181230161214p:plain

すごく気楽に遊べる、麻雀みたいなカードゲーム。
コンプレットを知っていれば、コンプレットのカードゲーム版と思ってもいいかも。
ただ、個人的にはコンプレットよりも111の方が好き。

ルールは簡単で、2〜111までの数字が書かれたカードがあり、各自に12枚ずつ手札として配られる。
このとき、手札の並び順を入れ替えてはダメ。
というのも、このゲームの目的が、手札の並び順を昇順もしくは降順に揃える、というものだから。
そして、各自の手番では、中央の場にある3枚のカードから1枚を選んで取ってきて、手札の任意の位置に追加し、追加したその両隣のいずれかのカード1枚を中央の場に戻す。
これを繰り返していくことで、誰かの手札が昇順もしくは降順に揃ったらラウンド終了で、得点計算。
これを何ラウンドか繰り返して、誰かが60点を超えたらゲーム終了。
ホントこれだけ。

今年の1月に遊んだのが初めてだったけど、たぶん仲間内で今年一番遊んだゲームだと思う。
なんというか、爆発的な面白さがあるというわけではないんだけど、ルールも簡単だし、なんか黙々と遊んでいられるのがいい。
「何して遊ぼっか?」「んー、じゃあ、とりあえず111やる?」みたいな。

ランやセットを作るのではないので、厳密にはラミー系とは呼べないのだろうけど、プレイ感はラミー系そのものと言っていいと思う。(※麻雀もラミー系のゲーム)
麻雀は役を覚えたり得点計算が大変だったりするけど、このゲームはそういった大変さはないので、麻雀に変わるゲームとして、定番になっていくといいなぁ。

第1位「ピココ」

f:id:yamaimo0625:20181230161233p:plain

見た目がキレイな変態トリックテイキングゲーム
以上!

・・・という冗談はさておき、うん、でもやっぱり「変態」という言葉が一番似合ってるんじゃないかな、と思うゲームw

何トリックとれるかを予想するトリックテイキングゲーム、という意味では、オーソドックスとも言えるのだけど、まず、自分の手札は見えない
もうこの時点で変態。
さらには、自分の左隣のプレイヤーの手札をプレイする
うん、うん、そうだね、自分の手札は見えないんだから、隣のプレイヤーの手札をプレイすればいいよね・・・って、そんな簡単に納得できるかいっwww
もう「ド変態」としかいいようがないw

そして、何トリックとるのかを「全員分」予想する、っていうのが、また凄い。
何それ、神さまにでもなれっていうのかよ・・・
「戦いとは常に二手三手先を読んで行うものだ」「見える、私にも見えるぞ!」的な?
いや、カッコつけるのはいいけど、あんた、一番肝心な自分自身が見えてませんよ?

ーーいや、でももしかしたら、トリックテイキングの入門にいいゲームなのかも・・・?

トリックテイキングでよくあるのが、「間違えてフォローし忘れたらどうするの?」というのがあるけど、このゲームなら他のプレイヤーも手札が見えているので、フォローし忘れというのは起こりえない。
また、何トリック取れるかを予想するのはけっこう難しいけど、このゲームだと全員が全員分の予想をするので、他人の予想を参考にすることが出来たりする。
それに、見えてないのは自分の手札だけなので、見えている情報が多く、実は予想しやすかったり・・・?

・・・なんていうのは、まぁ戯言で。
当たり前だけど、みんながみんな同じ予想をしていたら、得点に差が出ない。
なので、このゲームで勝とうと思ったら、みんなの予想を裏切るような動きをして、かつ、自分だけがうまいこと予想を当てるような立ち振る舞いをしないといけない。
うん、難しすぎるw
やっぱり変態だw

ただ、そんな変態なトリックテイキングだからこそ、プレイするとやっぱり楽しいw
予想を狂わせようとする動きがあったり、あるいは単にプレイミスをしたりで、ゲームの流れが思わぬ方向にいったりするので、ワイワイ楽しめる感じになってる。
それに、クジャクコンポーネントもとてもいいしねw

番外編

ボードゲームに関しては以上なんだけど、最近、TRPG熱がちょっと上がっていたり。
ニコニコとかでいくつかリプレイ動画を見たんだけど、面白いね。

これとか、最高に面白かったw

天誅天誅www

仲間内でも、ゴールデンウィークに「ソード・ワールド2.0」を初めて遊んでゴブリン退治したり、「The FIFTEEN」を遊んでみたり。
アニメの「ゴブリンスレイヤー」が楽しかったので、今度出る「ゴブリンスレイヤーTRPG」もやってみたいw
オンセとかも出来るといいんだけどなぁw

今日はここまで!

トランプゲーム大全

トランプゲーム大全

111カードゲーム 完全日本語版

111カードゲーム 完全日本語版

コンプレット 日本語版

コンプレット 日本語版

ピココ 日本語版

ピココ 日本語版

The FIFTEEN

The FIFTEEN

『RubyでつくるRuby ゼロから学びなおすプログラミング言語入門』を読んでみた。

前から気になってた『RubyでつくるRuby』をこの前の技術書展5で購入して読んだので、その感想とか。

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

結論から言うと、「残念な本だったなぁ」というのが正直な感想。

自分が読む前に期待していたのは、わざわざRubyを対象の言語として選んできているくらいなのだから、「Rubyっぽさ」にちゃんと触れ、その「Rubyっぽさ」を活かして構文解析や抽象構文木の評価を実装していく、という内容。

ただ、読んでみたら、

となっていて、拍子抜け。

抽象構文木の評価も、クラスを使ってダックタイピング的に「うひょ〜、同じメソッド呼び出しでも、ポリモーフィズムでちゃんとあるべき処理が実行されるぜ! これぞオブジェクト指向! case文? そんなのいらん!」ってなってればカッコよかったんだけど、配列を使ったプリミティブな構造になってて、case文で条件分岐して、といった具合で、「えぇぇ・・・」と。
そんなのはHaskellにでもやらせとけと。

まぁ、そうなっているのは理由があって、この本で実現するRubyインタプリタは極々小さなサブセットになっていて、四則演算、変数、分岐、関数、配列、ハッシュくらいしかサポートしていないから。
ここでいう配列やハッシュも、メソッド呼び出しとかは一切サポートされてないので、ホントにプリミティブな機能しか用意されてない。
なので、RubyRubyっぽいところがゴッソリ落とされている感じ。
でも、それってRubyでやる必要あるの・・・?

そんな内容なので、この本はRubyの入門書としては使い物にならないので注意。
当然、構文解析も筆者の用意したgemの関数をポンと叩くだけなので、インタプリタ作成の入門書とかにも当然ならない。
RubyRubyをつくる、というネタ自体は非常に面白いと思うのだけど、ホントそういう趣味本として読むならともかく、実用性はまったくなし。
まぁ、そう言う本、自分は嫌いではないけど(^^;

にしても、せめて構文解析の部分はちゃんと書いて欲しかったなぁ・・・
もちろん、そこが一番難しいところで、書くのも大変なのは分かるんだけど、上記の通り、正直入門書にはまったくならない本なんだから、せめて趣味本としてちゃんと知的好奇心を満たしてくれている内容にして欲しかった。

ぶっちゃけた話、「Rubyプログラムを実行できるRubyプログラム」を書くだけなら、以下でいいわけだから:

eval File.read $*.shift

多分これが一番短いと思います。(23文字)

ちなみに、ちゃんとブートストラップもするし、(当たり前だけど)Rubyの機能もフルサポートしてるw

「いやいや、そんなん構文解析も評価も全部親のRubyインタプリタに丸投げしてるだけやん」って言われそうだけど、本書だって組み込み関数や配列やハッシュの実装は親のRubyインタプリタに丸投げだし(これ自体はまぁ仕方ない)、構文解析も筆者の作ったgemに丸投げでブラックボックスなわけだから、丸投げの度合いが違うだけとも言える。
例えば、それこそ筆者の作ったgemで本書の最後のプログラムを一つの関数として提供すれば、関数呼び出し1つポンとやってオシマイ、となるわけだし。

で、上記のワンライナーRubyインタプリタはおかしい、インタプリタの説明に全然なってない、と思うのなら、やっぱり構文解析の部分をマルッと省略してしまっている本書も、同様の批判がされるべきなんじゃないかな、と思う。
どうせこんな趣味本を買う初心者なんかいないんだから(偏見)、マニアックな方向に寄せて、ちゃんと書いて欲しかったなぁ。

今日はここまで!

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

「Lucid, the Dataflow Programming Language」を翻訳してみた。(その6)

ちょっと間が空いてしまったけど、前回の続き。

1.8 Lucidーーバランスのとれた言語

Lucidでは、応用数学の他の分野で見られるような、静的と動的の間の調和のプログラミングを復元しようとしている。

Lucidは実際には非手続き型言語だが、決して純粋に静的な計算の視点に基づくものではない。
Lucid文はただの等式だが、これらの文と代入文の間の類似点は、単なる表面的なものであったり、構文的なものであったりしない。
節(クロージャ)の変数は、時間とともに変化する値を持つと考えることが出来る。
ユーザによって定義された関数は、実際、無限の一連のデータ間の対応を示していて、さらに実際フィルターと考えることが出来る。
sqroot(avg(square(a)))というLucidの式と、対応するUNIXのパイプ

square < a | avg | sqroot

の類似点は、構文が示すよりもずっと深い。
Lucidの時間的な演算は、プログラマに反復やデータフローの計算(フィルタや「配管」)を直接的かつ自然な方法で実現できるようにする。

Lucidプログラマは、プログラムの出力(意味)は正確に指定するが、どう計算が実行されるべきかは指し示したりしない。
プログラマには、演算について考えることができ、演算を実行する特定の順序、データフローの速度、バッファの容量、プロトコルなどの詳細について心配する必要がない。
この「暗黙的な」アプローチは、実装にもより自由度を与える。
Lucidによってプログラマは不要なシーケンスの指定を避けることができ、これは計算を並行して行うのにずっとよいスコープを与える。

特にLucidは、他の「データフロー言語」に比べて1つ大きな利点がある。
それは、プログラマはデータフロー(さらに言えば単一のデータフローパラダイム)に全体としては制限されず、他の演算コンセプトで考えることも出来ることである。
特に、プログラマは、ある文を反復アルゴリズムの指定として理解することが出来る。
これにより、プログラマは、変数を、計算の過程で繰り返し修正された値が保存された(記憶された)ものとして考えることが出来る。
例えば、以下の等式

i = 1 fby i + 1;
f = 1 fby f * i;

は、データフローネットワークを指定するものとして理解することは確かに出来る。
しかし、このケースでは、データフローとしてみるのは、やや不自然である。
上記のような等式は、ifの両方を1に初期化し、これらの値を繰り返し更新する反復としてみると、はるかに簡単に理解できる。
反復の各ステップで、iの新しい値はiの古い値に1を加算したものであり、fの新しい値はfの古い値とiの古い値を掛けたものである。

もちろん、反復はデータフローではなく、データフロー言語には存在しないだろう、という反論がされるだろう。
私たちは、前提には同意するが、結論には同意しない。
データフロープログラマは、他の「モード」の計算は利用できないべきなのだろうか?
「純粋な」データフローで、すべてが削減されるべきなのだろうか?
データフローは、反復などの他の形式の計算で補完されたときに、最も効果的である。
これは概念レベルだけでなく物理的にも正しい。
私たちは、データフローネットワークが本来的に間違っているものではないと分かっていて、それは、何らかの反復アルゴリズムに従って入力を処理する、メモリを持ったフィルタを持っている(例のプログラムのsqrootフィルタは、この視点でのケースである)
一方、実際には、マシンが「純粋な」データフローを通じてすべてを行うことがより簡単になるかもしれない。
重要な点は、Lucidはプログラマにも実装にもデータフローか反復かの選択を強制しないことである。
実際、プログラマからの視点からの計算(私たちはそれを「仮想実装」と呼ぶことがある)は、実際の実装と大きく異なる可能性がある。
実際の実装では、データフローをまったく使用しない場合すらある。
(実際、反復とパイプラインのデータフローしか使用しないのでは実装できない多くの有用なLucidプログラムが存在する)

それにもかかわらず、Lucidは依然として「データフロー言語」である。
なぜなら、

  1. Lucidプログラムの大部分は、パイプラインデータフローモデルで計算を書くことが出来、そして、そのモデルで読んで理解することが出来る。
  2. パイプラインまたは他の形式のデータフローを使用できるので、これらのプログラムを効果的に実装することが出来る。

からである。

Lucidのアプローチは、他のデータフロー言語とは異なり、

  1. Lucidは厳密に非手続き型言語(実際、関数型)であり、静的で記述的な意味論的を持つ。
  2. しかし同時に、プログラマはデータフローの意味で操作を考えることが出来る。
  3. しかし、プログラマは、少なくとも詳細については、実際の実装を理解する必要がない。
  4. 他の形式の操作(すなわち、パイプラインデータフロー以外の操作)も、プログラマおよび実装者は同様に利用可能である。

Lucidのアプローチは、最終的に効率と有効性(単純性と一般性)の両方を達成する可能性を提供する。
プログラマは、計算が実行される途中で、何らかの制御(「影響力」と言った方がいいかもしれない)を持っている。
プログラムは非効率である必要はない。
同時に、操作の面については指し示すのみで指定はしないので、プログラマはグロテスクな計算全体の詳細を計画するという手間を免れる。
したがって、プログラマは、命令型プログラマが自分のマシンを制御するために必要とするすべてのレバー、ハンドル、スイッチといった余分な「汚い」機能を必要としない。
それゆえ、言語は比較的単純なままでいられる。

もちろん、多くの人々は私たちのアプローチに疑念を抱いている。
彼らは、それはあまりに都合が良すぎて、真実ではないと感じている。

命令型言語の問題の根本的な原因は、マシンに対する矛盾した態度であることはすでに見てきた。
マシンから離れたいと思うと同時に、マシンに近づきたいと思う欲望がある。
これは、プログラマや言語設計者が直面する永遠のジレンマであり、すべての言語やシステムで発生する一般的な現象だと多くの人は考えている。
彼らのうちの何人か(主にカウボーイ達)は、Lucidはマシンに十分に接近せず、ポインタ変数やエラー終了、あるいはデータフローネットワークの実行時再配線を許さないので、あまりに単純で数学的であり、失敗するだろうと考えている。
他の人たち(神秘主義者達の何人か)は、逆の理由からLucidは失敗する運命にあると思っている。
彼らはLucidがデータフローに基づいているので汚れていると考えてて、(マシンがフォン・ノイマン・マシンであるかどうかにかかわらず)マシンに近すぎると思っている。
彼らは、私たちが原則を裏切り、操作的な考えを強調して「カウボーイ」になったんだと感じている。
Lucidの文は本物の等式で、Lucidの関数や変数は本物の関数である事実にもかかわらず、Lucidは「関数型」ではないと言っている。

言うまでもないが、私たちはこれらの意見には同意しない。
高レベルであることと効率的であることは同時には満たせないということを命令型言語が見出したというのは、確かに正しい。
しかし、私たちはこれに同意しない。
というのも、このジレンマは、きれいな理想主義と汚い実践との間に、恒久的で悲劇的だが避けられない格差があるという一つの例に過ぎないからである。
私たちは、より簡単な説明があると感じている。

プログラミングに関する多くの著作では、プログラマの仕事は、与えられたマシンに何かをさせることであると思われている。
そして、言語は、マシンが何を実行すべきなのかを人間が伝える手段であると思われている。
この描画がまさに誤解を招いている。
マシンはただ与えられるものではなく、プログラマを喜ばせるために存在しているわけでもない。
言語は、プログラマが任意の欲望をコンピュータに伝えるためのツールではない。
マシンは問題を解決するために存在しているのである。
例えば、飛行機の飛行をシミュレートしたり、製油所を制御したり、ガスの請求書を計算したり、といった具合だ。
この文脈におけるプログラマの役割は、マシンに問題を伝えることであり、プログラミング言語はそのためのツールとなる。
プログラマがマシンから離れたいという理由は、問題に近づくためである。
フォン・ノイマン・マシンの問題は、問題から離れすぎていることである。
それらは、やらなければならない仕事に適していない。

多くのアプリケーションでは、大規模な並列性(ほとんどの種類の数値解析)やネットワークを流れるデータ(ほとんどの形式の会計)を使用する計算がかなり自然に示唆されている。
フォン・ノイマン・マシン(あるいはむしろ、そのようなマシンからなるシステム)は、どちらの計算にも適していなくて、そのギャップを埋める必要があるのは、過負荷な言語を使用する貧弱なプログラマである。
プログラマが計算をどのように実行するかを単に指示するだけでは不十分であり、最適化を実現するための詳細を残しておかなければならない。
必要とされる計算の種類と提供される計算の種類との間の距離が、大きすぎる。
プログラマは、計算の詳細を自分自身で担当し、人間の知能をこのタスクに適用する必要がある。
そして、言語設計者は、問題指向の機能とマシン指向の機能の両方を提供する必要がある。
問題とマシンがあまりにもマッチしていないので、出来上がった言語が不幸な妥協となるのは驚くことではない。
命令型言語の設計者は、ハードウェアの問題をソフトウェアによって解決するという不可能をやろうとしていることになる。
ソフトウェアの危機は、本当はハードウェアの危機なのである!

新たな言語は新しいマシンを伴わない限り、危機を解決することは出来ない。
正式なデータフローマシンがあれば、マシンと多くのアプリケーションの間のギャップは大幅に狭くなる。
したがって、これらのアプリケーションの場合、データフローに基づく言語は、マシンが非効率的に使用されていても、マシンから遠く離れずに問題に近づくことが出来る。
プログラマは、計算を指定する負担から解放され、代わりに計算を指示するだけでいい。
これにより、言語は手続き的ではなくなり、余分な、汚れた機能を持たないことが可能になる。

したがって、私たちの見解は、新しい言語と新しい機械を一緒に開発しなければならないということになる。
これは、有名な日本の「第5世代」プロジェクトの見解である。
内田俊一(1982、p.1)の言葉では、

しかし今日のコンピュータシステムは、最初の世代以来、あらゆる種類の改良がなされているが、依然フォン・ノイマンの計算モデルに基づいている。
本質的に、起こったのは、ソフトウェアシステムが新しく洗練されたアプリケーションに対応するように拡張されたことである。
現在のコンピュータで使用されているソフトウェアシステムは、大きく複雑になりすぎていて、生産性、信頼性、および保守性を維持できなくなっている。
また、従来のアーキテクチャに基づくハードウェアシステムも、これらの複雑なソフトウェアシステムをサポートするための計算能力およびメモリ空間の改善の点で限界に近づいている。

日本のプロジェクトは、PROLOGという言語と論理的な演繹としての計算の考え方に大部分が基づいている。 PROLOGを使用するプログラマは、必要なデータを生成するための正確なレシピを供給する必要がない。
代わりに、必要なデータに関する論理的な主張の集まりを提示する。
PROLOGの実装は、要件を満たすデータを自動的に検索する。
検索は、プログラマによって与えられた主張の論理的な結果を実際に調査することになる。
例えば、PROLOGプログラマ

path(Coventry, Reading, X)

と入力すると(ここではXは変数)、PROLOGの実装は最終的に以下のように答えるだろう。

X = [Coventry, Birmingham, Oxford, Reading]

この答えから、プログラマ

path(Coventry, Reading, [Coventry, Birmingham, Oxford, Reading ])

がプログラム内の他の文の論理的な結果であると結論づけることが出来る。
これらの文(ここには示されていない)は、鉄道網におけるある町から別の町への経路の概念を公理化するかもしれない。
プログラマは、明示的な経路探索アルゴリズムを与える必要はない。
代わりに、プログラムが示しているパスを検索することによって、実装はパスを検出する。
PROLOGでは、計算は制御された演繹の一形式である。

PROLOGはバランスのとれた言語の良い例である。
PROLOGのプログラム(少なくとも「純粋な」PROLOGのプログラム)は、一階論理の主張の集合として静的に理解することが出来る。
同時に、プログラマは、文を、深さ優先検索アルゴリズムを使った書き換え規則として理解することが出来る。
2つのビューは基本的に補完的である。
PROLOGプログラマは、プログラムを合理的に効率的なものにするために、検索戦略を理解する必要があるが、振る舞いのあらゆる面の詳細を知る必要はない。
自分のプログラムの正確さだけに関心を持っているのであれば、静的な文の主張の意味論で十分である。

日本の研究グループはPROLOGの研究について間違いなく賢明な決定を下した。
PROLOGは、日本のグループが念頭に置いている人工知能アプリケーションに適している。
しかし、私たちは、PROLOGが唯一の第5世代のプログラミング言語になることを強く疑っている。
確かに、インテリジェントな知識ベースシステム(IKBS)とAIアプリケーションの重要性は今後ますます高まるだろう。
確かに、PROLOGなどの言語はますます使用されるようになるだろう。
それにもかかわらず、(会計や数値分析のような)より直接的な「日常のよくある」計算も常に実行される。
PROLOGはこの種の問題にはまったく適していない。
たとえば、PROLOGプログラマは独自の関数を定義することはできず、算術演算でさえあまり立派なものではない。
AIおよびIKBSアプリケーション自体には、PROLOGスタイルの検索とバックトラッキングに加えて、十分に考慮された決まり切った(cut-and-dried)計算が多数含まれている。
PROLOGが他の言語や計算形式の助けを借りずにどれくらい自力で行うことができるかはまだ分からない。
日本のグループは確かに推論計算の限界を認識しており、データフローのアーキテクチャと言語(Lucidも含まれている)を調べている。
将来、「推論」プログラミング言語PROLOGなど)やデータフロー言語(Lucidなど)が協力して使用されることもあるだろう。
PROLOGは、エンドユーザーとのインターフェイス(これは非常に単純である)と、より「エキゾチックな」アプリケーションのプログラミングに使用できる。
一方、Lucidは、データフローマシンをプログラムして、より一般的な、舞台裏での計算を実行するために使用されるだろう。

もちろん、PROLOGとLucidはどちらもフォン・ノイマン・マシンで実装できる。
PROLOGはLucidよりも簡単に実装できる)
ちょっとした作業で、Lucidの合理的なサブセットを受け入れる、許容できる効率的な最適化コンパイラを作成することが出来る。
多くのアプリケーションでは、効率の程度は十分であり、あるいは少なくとも、非効率性はクリーンな非手続き型言語を使用する利点によって補われる。
しかし、システムプログラミングのような他のアプリケーションでは、非手続き型言語はCと競合することはできないと言うのは公平である。
というのは、非手続き型言語は単純に(フォン・ノイマン)マシンには十分に近づけないからである。
同様に、どんな命令型言語も(たとえデーフローマシンで実行されていたとしても)データフローマシン上で実行されるデータフロー言語と競合することは出来ない。

「丘の上のばか」は半分しか行けていない。
つまり、彼らは他のものを誠実に採用することなく、不適切な形の計算を拒否した。
彼らは、下にある谷に退廃的なフォン・ノイマンのアプローチの汚物と腐敗を見ているが、まだ山を越えてはいない。
彼らはまだ新しい時代のコンピューティングの預言者たちにコミットしていない。
彼らはまだ山の上で待ったままで、まだ反対側の豊かな地に降りる準備が出来ていない。

1.9 LucidーーThe Dataflow Programming Language?

この本のタイトルは意図的に曖昧にした。
「Lucid, the dataflow programming language」というフレーズは、「Lucid、(他の多くのものと同様の)データフロープログラミング言語」を意味する可能性がある。
しかし、「Lucidは、唯一のデータフロープログラミング言語」を意味することも出来る。
ある意味では、両方の読みが適切であると感じているので、私たちは曖昧な形でタイトルに残した。

読者は今、Lucid自体がデータフロー(プログラミング)言語とみなされる根拠を理解する必要がある。
明確ではないのは、データフロー言語と考えられる理由である。

実際にはすでにかなりの数のデータフロー言語が存在している。
「データフロー言語」という用語は、プログラマがデータフロー計算を指定するプログラムを書くことができる言語を意味する場合、これらの言語を以下のように分類することが可能である。

1. FORTRANなどの従来の命令型言語

実際には、命令型のプログラムをコンパイルしてデータフローマシン上で実行することは可能である。
最も単純なコンパイルアルゴリズムは、データフローアーキテクチャによって提供される並列性を利用しない。
より洗練された技法では、プログラムを解析して隠れた並列性(隠された、というのは、つまり言語の逐次的性質によって)を検出することが必要となるが、この技法がどれほど成功するかはまだ分からない。
命令型のプログラムを書くのに費やされた膨大な努力を考えれば、試してみる価値は確かにある。
しかし、長期的な見通しは、FORTRANと会社が徐々に段階的に廃止され、適切なデータフロー言語に置き換えられることでなければならない。

2. ADAのような拡張命令型言語

同時に動作する2つ以上の計算をプログラマが設定できるように、従来の命令型言語に機能を加えることは可能である。
これらの新機能は、通信プロセス(CSP)、コルーチン(Kahn-McQueen)、フィルタとパイプライン(UNIX)などのさまざまな運用上のアイデアに基づいている。
確かに、これらの言語はデータフローアーキテクチャを利用することが出来る。
それらの多くは、Lucidに近く、プログラマはデータフローの観点から操作を考えることが意図され、奨励されている。
残念なことに、拡張された言語は、すでに十分に悪い通常の命令型言語よりもさらに複雑になる傾向がある。
また、この新機能は、データフローのアプローチとは全く相容れない、一般的な中央データストアの概念に基づいていることもある。
より直接的にデータフローに基づくものであっても、依然として奇妙で、複雑で、使用するのが難しい場合がある。
私たちは、これらの「リッチすぎる」言語が未来の波を表しているとは信じられない。
並列処理を強制する機能を追加するのではなく、不必要な逐次性をプログラマに指定させるような(または少なくとも推奨するような)機能(代入文など)を削除する必要がある。

3. 制限された命令型言語、例えば、IDのような単一代入言語

代入文の使用に関する特定の制限により、実装がプログラム内で並列性を見つけて利用することがずっと容易になることは、長い間知られていた。
制約があってもプログラムを書くのは難しくなく、単一代入プログラミングは非常に厳密な構造化プログラミングのようなものである。
もし、成功を(a)重要なプログラムを努力なしに正しく書くことが可能であり、(b)最大限に引き出された洗練された前処理とプログラムの分析なしにデータフローアーキテクチャーの優れたメリットを得られることとするならば、単一代入言語は最初に実際に成功したデータフロー言語である。
それにもかかわらず、単一代入言語が未来の波であるとは考えにくい。
代入文は、フォン・ノイマンの計算方法による二日酔いである。
なぜそれを制限するだけで済ますのだろうか?
完全に排除してみてはどうだろうか?

4. SASL、FGL、または、Lispkitなどの汎用関数型プログラミング言語

代入が禁止されているこれらの言語は、LISPが近代化されれサニタイズされたバージョンである。
リストは通常、主なデータ構造である。
これらの言語は、特に無限リストが許可されている場合、データフロー言語として正常に使用できる。
これらの無限リストが(よく彼らがそうするように)履歴の表現に使われる場合、これらの言語でのプログラミングはLucidでのプログラミングと非常によく似ている。
これらの言語の問題は、私たちが見ているように、まだあまりにも一般的なことである。
リストは履歴として使用する必要はなく、はるかに複雑な構造を形成することが出来る。
リストの要素は任意のオブジェクトにすることが出来、関数は任意のオブジェクトに適用(および生成)することが出来る。
プログラマはこの一般性のために重い代償を払うことになるというのが私たちの考えである。
一般的なLISPライクな言語は実装するのがはるかに難しく、特定の技法(タグ付きの要求解釈など)は適用されない。
一般性はプログラマだけでなく実装者にも影響する。
Lucidのプログラマは、xとyを時間と共に変化する値と考えることができ、それらの(変化する)合計をx + yとして書くことが出来る。
しかし、LISPプログラマは、xとyが本当に無限のオブジェクトを表し、以下のようなものを書く必要があることを強制的に思い出させる。

componentsum(x, y)
where
    componentsum(x, y) = 
        cons(car(x) + car(y), componentsum(cdr(x), cdr(y)))
end

もちろん、(a)書かれたプログラムの種類に制限を課すことは出来るし(b)プログラムを前処理するか、+のようなシンボルの意味を拡張して、リストの要素ごとの合計を含めることも出来る。
これは私たちのリストの最後のカテゴリに私たちを連れて行くだろう。

5. 特別な目的のデータフロー関数型言語、すなわちLucid

したがって、Lucidは、単一代入およびLISPのような関数型言語を通じて、従来の言語からのデータフロー言語への進化を予測する試みとして見ることが出来る。
私たちは、この進化の面で最も進んでいるのが、データフロー言語であると主張している。
確かに、それが唯一のデータフロー言語であるとは主張していない。
また、他のデータフロー言語を必ずしも「失敗」とみなすことも望ましくない。
しかし、私たちは、Lucidが古いフォン・ノイマン形式の計算を最も拒否し、その代わりにデータフローを採用している、1つのデータフロー言語であると感じている。
Lucidは未来のデータフロー言語である。


ということで、これで1章はおしまい。

読んでて、唐突に日本の研究の話が出てきて驚いたw
それも、第五世代コンピュータの話とかw

第五世代コンピュータのプロジェクトはよく失敗だったと言われるし、自分もそう思ってたんだけど、自分の場合、シグマプロジェクトと混同してたというのがあった。

シグマプロジェクトはもうどうしようもない失敗プロジェクトだったわけだけど、第五世代コンピュータというのは、シグマプロジェクトとはまた別のプロジェクト。
第五世代コンピュータというのは、「述語論理による推論を高速実行する並列推論マシンとそのオペレーティングシステムを構築する」というものだったらしい。(引用元:wikipedia
これによって、高速なエキスパートシステムを作り上げ、人工知能を実現させよう、と。

結局、期待された人工知能は出来上がらず、また、ここで作られた技術もその後使われることがなかったので、失敗プロジェクトと見做されているんだけど、ただ、調べてみると、なんか違う感じ。

元より、人工知能を作ろうというところまでは言っていなくて、スコープとしてあったのは「マシンとOSの構築」という部分。
そして、実際にマシン(PIM)も作られているし、OS(PIMOS)も構築され、そのための言語(KL1)も作られている。
そういう意味で、当初のスコープはちゃんと達成されていたっぽい。

また、その研究成果は第五世代コンピュータの研究開発成果でPDFで見ることが出来るんだけど、意外と興味深い・・・

何かの拍子で再評価されたりすることもあるかもしれない。
実際、Lucidーーというか、データフロー言語に自分は興味を持ってるわけだしね。

それにしても、Lucidは自身を「未来のデータフロー言語だ」と言ってるわけだけど、現状は推して知るべし。。。
未来の言語どころか、忘れ去られて、誰も知らないような言語になってしまっている。
そういう意味で、Lucidの試みは失敗だったと言えるかもしれない。

けど、その問題意識は、非常に今の状態にマッチしていたり。
ある意味、「早すぎた」というか。
なので、温故知新、改めて評価される日が来たりするのかもしれない。

今日はここまで!

「Lucid, the Dataflow Programming Language」を翻訳してみた。(その5)

前回の続き。

1.6 Honest, Folks, We Was Just Funnin’

この数ページで、プログラミング言語に取り組んでいるほぼすべてのコンピュータ科学者を致命的に怒らせただろう。
今や、怒れるカウボーイ達、ウィザード達、伝道師達、技術者達、よろず屋達(Handymen、修正主義者達のこと)のリンチ暴動が集まっている。
彼らは瞬間的に紛争を忘れ、私たちを通りの向こうにある古い狩猟用の木に引きずり出すという決意に結束している。

読者はおそらく私たちほとんど同情していないだろう。
結局のところ、ソフトウェア危機を解決しようとするほとんどすべての試みを無駄に却下しただけではないか?
真面目な研究者を半狂乱なマンガのキャラクターとして描写して、傷害に侮辱を加えていなかったか?

実際には、私たちの風刺は、ターゲットに見えるかもしれない少数の人々にしか向けられてない。
例えば、プログラムの検証や意味論を扱うほとんどの人は、かなり賢明である。
彼らは、自分の研究が重要だと考えているが、既存の言語の新しい意味論による記述がソフトウェア危機を解決しようとしているという幻想のもとにはいない。
彼らは実際にウィザードと呼ばれるに値するほどではない。

同じように、ほとんどが単なる死人であるような人々によってプログラムが構築されることを、ほとんどのプログラマ・ソフトウェアエンジニアはよく知っている。
彼らは、専門的な機械に近いプログラミングが、ソフトウェア開発の問題に対する普遍的な救済策ではないことを知っている。
賢い人でさえ、あまりにも多くの巧みさが殺すことができることを知っている。
これらの人々は真のカウボーイではない。

同様に、ほとんどの技術者達は、良い環境が悪い言語に対する救済策ではないことを知っている。
多くの伝道師達は、良い方法論では本当に悪いシステムを克服できないことを知っている。

私たちの批判は、彼らが取り組んでいる特定の問題がソフトウェア危機の根底にあると確信している、小規模少数派に対してのものである。
たとえば真のウィザードは、正式なツールがないことが命令型言語の問題のすべての原因になっていると確信している。
同じように、実際の技術者は、現実の問題は適切なプログラミング環境がないことであると確信している。

彼らは解決策を持っていると確信しているが、みな間違っている。
彼らは、使用されているマシンの基本設計に問題があるとしていないため、間違っている。
代わりに、彼らは問題がマシンの使用方法にあると考えている。
彼らは問題を技術的なものとして見ていない。
多くのアプローチは非常に異なり、あまり共通性がないが、1つ共通な点がある。
すなわち、彼らはソフトによる解決(ソフトウェア、数学、方法論など)をハードの問題に提案している。

ある研究者グループは、私たちのブラックリストからはっきりと抜け落ちている。
私たちは、新しい種類のマシンを設計する人々については、何も悪いことを言っていない。
もちろん、私たちは彼らを、はんだこてでソフトウェアの危機を解決することができると思っている狂信者、修理士と風刺することも出来た。
結局のところ、彼らは、カウボーイや伝道師と同じように、彼らの仕事が将来の鍵であると確信している。

違いは、彼らは正しいということだ。
ソフトウェア危機全体の根底にある問題は、実際にはマシンアーキテクチャの問題である。
私たちは提案された個々の新しいアーキテクチャがその仕事に縛られなければならないと言っているわけではない。
しかし、全体としては、ハードウェアの研究者が解決策につながる唯一の道に従っている。
主題の半分である「ソフト」のコンピュータ科学者(意味論者、方法論者、言語設計者)には、選択肢がある。

一つは、彼らは自分のスキルとエネルギーを、古い逐次型・命令型アプローチを少しでも長くしてみようと努力することに専心することが出来る。
この選択をするのは、カウボーイ、ウィザード、伝道師、技術者、よろず屋である。

もう1つの選択肢は、新しいマシンや計算形式の模索を試みることである。
この選択は、新しい世代のコンピュータに適した新しい種類の意味論、方法論、言語などを発見するのに、技術とエネルギーを捧げることを意味している。
この道を歩む人たちは未来を選んでおり、彼らの努力が無益でもばかげてもいないことが示されるだろう。

もちろん、第3の可能性もある。
それは、問題は無視して、特定の計算形式からは独立した意味論、方法論、検証システムなどを開発しようとすることである。
これは可能であり、命令型言語の検証は、非手続き型言語にも容易に適用できる。
しかしながら、研究者は問題を永遠に避けることは出来ない。
そのような、立場を明らかにしていないと自身では思っている人々は、(計算が本質的に逐次的であるという確信など)無意識の偏見の犠牲者であることが多い。
生涯の仕事としている主題のリスクについての、根本的な論争を避けようとする研究者は、無関係であることを最後に証明する。

1.7 非手続き型言語

命令型のプログラマや言語設計者が、マシンとの愛憎関係を持つことは明らかである。
一方では、彼らはマシンから離れたがり、抽象的で高レベルで構造化されていて数学的で問題指向でありたいと思っている。
同時に、彼らはマシンに近づき、計算の詳細を制御し、プログラムをできるだけ効率的にするという圧倒的な衝動を持っている。
もちろん、プログラマがマシンに近づくことを可能にする機能と修繕は、すべてのトラブルを引き起こすものである。
これらは、未熟者が悲しみ、ウィザードが分析に困り、伝道師は悪と告発し、よろず屋は永遠に修復している機能である。

命令型言語の問題は、多くの人々にマシンとの関係の「愛」の側面を再考させている。
彼らは、プログラミング言語の最も基本的な原則、すなわち計算や動的な活動を指定することが意図されているため、本質的に動的であるということを拒否しようとしている。

PASCALのような言語の本質的に動的な2つの機能は、代入と制御フローである。
当然のことながら、多くの人がそれらを排除しないべきかのか、疑問に思った。
この急進的な解決策は、最も重い制御フロー、すなわち、goto文が不名誉に引退することを余儀なくされた後、信頼性を得た。

代入も制御フローも、本当には必須ではないことは古くから知られており、純粋に静的で数学的な言語でプログラムを書くことは可能である。
約50年前、チャーチは計算可能な数値関数を(関数を定義するための非常に簡単な形式である)ラムダ計算で表現できることを示した。
後でクリーネ(Kleene)は、同じことが、再帰的な関数定義である「構造」だけの単純な言語でも言えることを示した。
発明された最初の高レベル言語の1つはLISPであり、その「純粋なコア」には代入も制御フローもなく、確かにLISPはチャーチとクリーネの仕事の一部に基づいていた。

手続き型言語(すなわち、代入や制御フローのない言語)は、多くの点で命令型言語よりはるかに優れているという一般的な合意がある。
手続き型言語は、参照透過(referentially transparent)であり、プログラムに現れる式の値は、部分式の値だけに依存し、これらの部分式が評価される順序には依存しない。
特に、関数(または「関数手続き」)は、実際には単語の通常の意味での関数を表している。
関数によって返される値は引数の値によって決定され、関数が「呼び出される」「時間」から独立している。
つまり、数学記号(+など)は、従来の数学とまったく同じように使用される。
非手続き型プログラマによって使用される表記法は、プログラマによって使用のために修正された、従来の数学の表記法である。

ウィザード達はもちろん、非手続き型言語を喜んで受け入れている。
なぜなら、従来の数学の手法を使用してプログラムを推論することができるからである。
非数学的な表記の数学的な意味を作るために全く新しい形式を開発する必要がない。
たとえば、等式の置換の法則が成り立つ。
すなわち、関数 f(x, y) x - 2 * yという式で定義されている場合、 f(A, B)という式は A - 2 * Bに置き換えることが出来る。
(少なくとも本書で考慮されている)非手続き型言語の意味論は、非常に簡単に仕様化することが出来る。
式の意味は、指定された関数または演算を部分式の意味に適用した結果であり、再帰的定義の意味はその最小不動点(least fixed point)である。

伝道師達もまた、恍惚としている。
ISWIMのような言語ではgoto文はなく、forループすらない。
副作用もなく、例えば式 f(x) - f(x)の値は、整数を含むとして、計算が終わるのならば、常に0である。
参照透過性は明らかにトップダウンアプローチをより簡単にし、関数定義とwhere節は優れた構造化ツールとなっている。

それにもかかわらず、非手続き型言語は、常に(特にカウボーイ達によって)、致命的な欠陥があるとみなされてきたーーすなわち、それらは(おそらく)本来的に非効率的である、と。
この(非難された)非効率性の根本的な原因は、反復の欠如である。
手続き型言語は純粋に定義的なものなので、変数の値は、少なくとも定義が有効なプログラムの範囲内では変更できない。
ダイクストラDijkstra、1965、p.215)は、以下のように言っている:

その優雅さにもかかわらず、深刻な反論がそのようなプログラミング言語(代入や制御フローがないもの)にはされるだろう。
スタック内の情報は、入れ子にされた存続時間を持つオブジェクトとして表示され、そして、その存続期間全体にわたって一定の値であるだろう。
そして、既存の名前付きオブジェクトの値は、別の値で置き換えられる。
結果として、新しく形成された結果を格納する唯一の方法は、スタック上に置くことであるが、スタック上に置かれた値を知るすべはなく、興味がないにも関わらず、スタック上の値の寿命は長くなる。
まとめると、それはエレガントだが不十分である。

※(訳注)おそらく、ループを再帰で実現することについて言及していて、その場合、スタックが深く掘られていくことになるが、その古い値は(ループでは)もう不要になっていて、しかも現在の関数から参照することも出来ないにも関わらず、ずっと生き続けてしまうということを指摘している。
なお、末尾再帰であれば(処理系の実装が賢ければ)そのようにスタックが掘られることはないが、その場合、メモリ上の値の置き換えは発生している。
(末尾再帰は、本質的にはループで必要なスタックを引数として表現し、gotoによるラベルジャンプでループを実現しているのと同じ)

ダイクストラの判断は、より古い従来の非手続き型言語(主にLISP)の経験によって確かに確認された。
多くのアプリケーションでは、LISPはきわめて適していますが、他の人にとっては、特に懐古的であるため、LISPによる解決は許容できないほど遅い。
実際、LISPの開発者は、性能を向上させるが参照透明性を破壊するいくつかの「不純な」機能(実際の反復のためのプログラムを含む)をすぐに追加した。

しかし、最近、研究者は非効率性の問題に対する可能な解決策を発見した。
ダイクストラによって強調された弱点は本質的な弱点ではなく、特定の種類の非手続き型言語を実装する特定の方法の弱点である。
ダイクストラの批判には、暗黙のうちに2つの仮定がある。
最初の前提は、プログラムが従来のALGOLランタイムスタックアプローチを使用してフォン・ノイマン・マシンで実行されることである。
2番目の前提は、基本データオブジェクト(関数の引数)が有限集合であり、スタックに積み上げられる「マシン・ワード」の集合であるということである。
関数の引数が無限のオブジェクト(例えば、すべての素数のリスト)であることを可能にする新しい非手続き言語が登場している。
これらの新しい言語は依然として立派であり、数学的であるーー数学者は何百年もの間、無限オブジェクトを扱ってきている。
それにもかかわらず、新しい言語は新しいプログラミングスタイル、(リダクションマシン、遅延評価、データフローといった)新しい実装方法を許可し、ダイクストラによって言及された、反復を再帰とする問題を避け、一つのプログラムで多くのプロセッサが評価の協力を行える。
手続き型言語は、ある日、効率性と優雅さにおいてFORTRANと競合するかもしれない。

反復の代わりに再帰的定義のみを使用して、効率的にプログラムすることは可能かもしれない。
しかし、この奨励的な開発により、一部は完全に反復を放棄するようになった。
彼らは非手続き型言語が反復を持つことができないということを無神論的に受け入れている。
実際、非手続き型プログラミングは本質的に操作や動的な考慮事項から独立していると、彼らは原則をより一般的に拡張している。
彼らは、この「ダイナミズム」の欠如がプラスの美徳であると考えている。
彼らは、動的・操作の考えがプログラミング言語のすべての問題の源泉であると思っている。
プログラミングに対するこの神秘的で先見的なアプローチは、私たちが「丘の上のばか」と呼んでいるものを表している。
すなわち、プログラマは、単なる計算のやり方の詳細について言語と心に負担をかけてはならず、代わりに、静的で永遠な数学的対象について考えて、ただ計算の喧騒から離れて、丘の上に座っていなければならない、と。
もちろん、プログラムは実装されて、さらに効率的である必要があるが、(「神秘主義者達」によれば)それはエンジニアの、言い換えれば単なる商人の、関心事である。
プログラマは、この見解によれば、プログラムがどのように実行されるべきかについて何も知る必要はなく、数学的な観点からだけ理解するべきである、と。

神秘主義者達は、現在の「関数型プログラミング(functional programming)」コミュニティで特に強く象徴されている。
1つの特に極端な宗派は、関数はクリーンで高レベルであり、プログラマーの注目に値するが、その引数(卑しいデータオブジェクト)は汚れていて、低レベルであり、避けられるべきだと信じている。
ただのデータオブジェクトは、この宗派の支持者にとって、言い表せないほどありふれたものであり、彼らはそれを話すことさえ失望させると考えている。
したがって、その言語にはこれらのオブジェクトに名前がなく、変数と式は関数のみを表すことが出来る。
いくつかのデータフロー言語もこのカテゴリにいる。
これらの言語では、データフローは純粋に実装手法であり、非手続き型プログラマの洗練された感性を害するだけの操作概念である。

この理念に対する支持者は、実際の(「純粋な」)数学は本質的に静的オブジェクトを扱い、変化と動的活動は数学的精神とは異なるということを自明として、自身らを正当化している。
クリストファー・ストレイチー(Christopher Strachey)(1971、p.77)は、かつて次のように言っている:

...プログラミングにおける命令(またはコマンド)の使用は、変数を導入し、数学は一般に、この意味での変数の存在ーーすなわち、ある期間にわたって変化する値ーーを認識しない。
従来、数学は静的な状況だけを扱っている。
 オブジェクトの極限へのアプローチに関係する計算でさえ、一連の固定値の観点から対象を扱う。
 ...一方、プログラミングでは、プロセスの性質上、時間によって変化する変数を扱う。
プログラムは本質的に変更のスケジュールである。

(ストレイチーは、偶然にも、神秘的な視点を擁護していなく、むしろ、彼は代入文の理解に必要な新しい動的な数学を開発するウィザードを奨励していた)

しかし、数学が本質的に静的だというのは本当に正しいのだろうか?
数学者が時間とともに変化する値を決して扱っていなかったというのは本当に正しいのだろうか?
真実と違うことがあってはならない!
微積分が最初に開発されたとき、それはまさに操作の基礎にあった。
ニュートンは、時間と共に変化する流入量を導入した。
のちに、当然のことながら、微積分は、極限(または、より最近では、無限小という概念)の概念を用いて形式化された。
それにもかかわらず、微積分は本質的に量の変化、実際は滑らかに変化する量の研究である。
数学の基本原則は常に、量の概念を継続的に一般化することによって、静的な方法で動的を研究することだった。
例えば、昔「持ち去り」という動的だった概念は、負の数で公式化され、同じように「区分け」は有理数を使って形式化された。
数学は、常に様々な形の変化を研究してきている。

物理学者とエンジニアが、「極限への物体のアプローチ」に関連して、ストレイチーの計算の定義を受け入れるのは、非常に困難である。
実際に微分方程式を使用する人は、通常、速度、加速度、密度などのまさに操作上の概念を使用する。
動的な思考が「低レベル」であるとか、または混乱を生み出すということは、彼らには決して起こらない。
動的視点と静的視点との間に真の矛盾は見られない。
代わりに、彼らは反対であるが補完的で調和のとれた2つのアプローチを見ている。
数学が動的な状況をモデリングしている(または指し示している)とき、動的に考えないことがあるだろうか?
そうしないのは、なんとも愚かである!

神秘主義者達は基本的な問題(フォン・ノイマンアーキテクチャの不適当性)を認めているが、それを無視して問題を解決したいと思っている。
神秘主義者達は、彼らのプログラムがどのように実行されているか知りたくないし、少なくとも、プログラマが知るべきではないと思っている。
彼らの言語の意味論は、操作の考えを参照することなく与えることが出来るので、問題全体を自身の手で洗うことが出来ると考えている。
彼らはエンジニアに「ここに言語の意味論があり、それを実装し、望む関数を使用することが出来るので、フォン・ノイマンアーキテクチャに縛られてはならない」と言う。
神秘主義者達は、言語の設計はマシンに完全に依存しないと考えている!


ということで、本質的にはマシン・アーキテクチャの問題だ、というのが、筆者たちの主張。
フォン・ノイマンアーキテクチャに代わってデータフロー・アーキテクチャを考え、その上で動くプログラムを表現するためのプログラミング言語を考え、その数学的な意味論を、履歴を持った変数・関数で構成しようとしている、といった感じか。

それにしても、長い(^^;
興味深い議論ではあるんだけどね。
次でやっと1章が終わる予定。

今日はここまで!