common lispにおいての末尾再帰最適化

ループで実装する練習中ですが
どうやらclispのlinuxの実装は末尾再帰を最適化してくれているようです
同じ処理をループと再帰で実装したけど実行時間が同じだったという観測結果からによるものですが
言語仕様的には多分common lispでは別にする必要ないというか規定されていないだけなんだろうなと
多分schemeの仕様には末尾再帰を最適化するような記述があるんだろうな

苦手意識からか

関数型を意識しすぎていてループでのプログラミング方法が全くおろそかになっていていまさらながらdoを使うのに非常に苦労してしまっているところがとても歯がゆい
とにかく意味もなく関数型、common lispなのに関数型
どこでだれが言ってたか忘れたけどcommon lispは関数型じゃないって言ってたような
lispって関数型の印象が強いけど印象だけで別に関数型じゃないらしい
末尾再帰も最適化されるわけじゃないみたいだし
多分だけど憶測だけどschemeだったら末尾再帰は最適化されることになってるんじゃないかなと、多分ですが
と言うわけでしばらくループで書く練習に取り組もう
まずはdoが満足に使えるようになることを目指そう

乱数生成のシード

(setq *random-state* (make-random-state t))

を設定すると、起動するごとにrandom関数のシードを設定できる

多分いわゆる現在時刻とかをシードに設定しているのだと思う
指定しない場合、randomは一定の値を返す

ソフトウェアの開発プロセスにおける大切な概念の一つ

トップダウン、ボトムアップの思考法
トップダウンに関しては関わるプロジェクトの規模に依存するが、だいたい中規模のプロジェクトになった辺りから特にトップダウンでの能力が問われるのではないかと
逆にボトムアップは関わるプロジェクトの規模に応じないでまんべんなく必要とされる能力だと思う
プロジェクトが小さいうちはボトムアップのみで対応可能なものが多い、トップダウンは必要とされない、出る幕がない
しかし規模が大きくなるにしたがってトップダウンの能力が問われるのでは
一般的に技術者と呼ばれる人はボトムアップからの流れは得意な人が多いのではないかと
どちらが重要というのではなく両方必要
ただしどちらが得意かは人それぞれ
両方の特徴を最適に活かすことができれば素晴らしいものが作れると思う

練習方法としては、先ずボトムアップでやってみてからの結果を眺めて結果こういう形になるようにトップダウンを行えばいいんだなとかやる方法か
何回も何回もボトムアップでやってみて結局出来上がった形からトップダウンの姿を眺めておいて、それを糧にトップダウンから始めた場合のゴールを体感しておくことか

個人的にはボトムアップは苦手
トップダウンが良い
ボトムアップが苦手というか実際の手続きを作る作業が苦手

規模が大きい場合、あるいは将来的に向かう方向が決まっていて段階的にリリースしていく場合トップダウンで事前に準備しておくことが不可欠ではないかと
でもそんなことないかな、今の段階でリリース予定でも本当にリリースするまでその機能が必要とされるかどうかはわからないからね
そのために無駄な準備をしておくこと自体不毛、特に自分は決定権がないプロジェクトの場合はモロ当てはまりそうだな

あとボトムアップで作るならコンパイラが必須のような
コンパイラ使ってリファクタリングしまくってやらないとね
そうしないと作業が遅々として進まないから
コンパイラって言うか静的型付けと言いたいのだ
しかしcommon lispは動的型付けなんだよな
例えばhaskellなんかだとボトムアップに向いてるんだよな
javascriptだとさリファクタリングしにくいったらありゃしないよね
関数に引数追加、変更したりしてもjavascriptだと例えば引数渡されてなかったらどうこうするって記述になるのかな
haskellとかだと関数のプロトタイプ変更してもさ、コンパイルエラーの箇所を変更すればいいからね、楽だよね

二項演算子って言うもの自体

この世には不要な概念、余分としか言いようがないよな
大体さ、「二」項演算子って言うのがムカつく
コンピュータサイエンス的には「n」項演算子って言う方が絶対しっくりくるはずだ

google app engine on linux

開発環境をダウンロード

Pythonインストール

開発環境解凍

パスを通す

開発環境を解凍した場所にプロジェクトフォルダを設置--a

開発環境を解凍した場所でdev_appserver.py [.yamlがあるフォルダ名--a]

common lispのfとgの違い

次の関数fとgの違い

(defun f()
  (let ((i 0))
    (lambda()
      (prog1
 i
 (format t "lazy call ~A~%" i)
       (incf i)))))

(let ((i 0))
  (defun g()
    (lambda()
      (prog1
 i
 (format t "lazy call ~A~%" i)
       (incf i)))))

(let ((a (f))
      (b (f)))
  (dotimes (i 10)
    (format t "~A ~A ~A~%" (funcall a) (funcall b) (funcall b))))

(let ((a (g))
      (b (g)))
  (dotimes (i 10)
    (format t "~A ~A ~A~%" (funcall a) (funcall b) (funcall b))))

fを呼び出すと、呼び出すたびにlet iが実行されて新しいiが生成されるってことなんだろうな
そんでfの中のlambdaは都度生成されたiを参照するようになるということなんだろうな
多分そんな理解でいいんじゃないかなと思います

あと、common lispでできるか不明だけどマルチスレッドの場合prog1で囲った部分を排他できるとなお吉ではないかなと思います

問題のスモールステップ意味論、ビッグステップ意味論

に関してです
スタックを消費してもいいから計算をなるべく簡約したい場合はビッグステップ意味論が適している
スタックの消費がやばい場合はスモールステップ意味論が適している
と言う認識でいいのだろうか
で、具体的にどちらがどんな場面に向いているかと言うことなんだよな
普通にビッグステップ意味論だけでまかなえそうなんだけど無理なのかな
スタック、と言うかramが少ない昔のコンピュータはスモールステップ意味論の方が向いているような気がするけどfortranなんかだとスモールステップ意味論で構築されているのだろうか、あとcobolとか
でもlispは絶対ビッグステップ意味論でやっている感じがするな
あの簡約のしかたは完全にlispの流儀に沿っている気がするので

dvorakの代替案

と、言うわけでdvorakもqwertyもどっちもイマイチってことになったので最適な案を考えてみたいと思います
って言うか「qwerty vs. dvorak」って言う対決の図式がそもそもおかしい、別にどっちも最適じゃないと思うので
ですが、とりあえず前提条件としてqwertyのレイアウトを元に新たなキー配置を考えてみたいと思います
新たなキー配置をゼロから考えられる状況じゃないので、現在qwertyがこれだけ優勢な状況にある事実を真摯に受け止めてそこから最適なキー配置を考えたいと思います

・一段目はそのままにする(記号も含めて)
・記号はそのままにする([];',./)
・アルファベットのみ置き換える
・置き換える際、できるだけqwertyと合わせる(q、zあたりはそのままにする)
dvorakの失敗はこれらの点にあると思うのですよ
あまりにも理想を追求しすぎたと思う
まあ、当時の状況では仕方がないことかもしれないけどdvorakさんはqwertyの趨勢を読み間違えてしまったからではないかと思う

[qwerty配列]
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./

[dvorak配列]
'<>pyfgcrl/=\
aoeuidhtns-
;qjkxbmwvz

[qwerty-dvorak配列]
qwdrfjyklp[]
aoeuihtns;'
zxcvbgm,./

技術の寿命について

ソフトウェアの世界に身を置いて「数」十年経過したと言えるレベルには達していませんが数十年達しようとしている今、感じることが多くなったこととして、ソフトウェアの寿命は意外と長いということがあります
「寿命」と言う用語について説明を補足しておくと、想定より長い期間有用であり続けてくれて大変助かりました、とは逆に、意外とコイツ長い事使わないといけないなって言う意味での寿命ということです
仕事していて良く思うのですけど、「コノクソプログラムをまだメンテナンスしていかないといけないのか」とか「2015年にもなってまだこんなもん使っているとは2005年の頃には思いもよらなかった」ってなるんですよ
ソフトウェアって実物が無いだけに変更、入れ替えが簡単みたいな触れ込みが大学の授業とかであったような記憶がうっすらあるんですけど、あれ絶対ウソだな
実物が無いソフトウェアなんかより実物があるハードウェアの方が絶対入れ替わり早いと思うな
携帯電話とかそうなんですけど、数世代前の機種って異常に古臭く感じますよね
初代iモードとかj-skyとか謳っていた機種の古臭さと言ったらわかってもらえますか
ハードウェアってものすごい勢いで入れ替わってると思うもの
まるで、若者の代謝のよう、その点、ソフトウェアって完全にオジイの代謝っていうくらい全然入れ替わらないですね、代謝が悪すぎる
だからと言ってソフトウェアの代謝を高めるためにどうすればいいかと言われてもまあ困るんですけど
と、言うわけですがこれからは、ソフトウェアの選別時において寿命は意外と長いぞと思って臨もうと思います

プログラミングコンテストについて思うこと

いまさら言うまでもないけど、プログラミングコンテストはあくまでもプログラミングコンテストドメインに特化した能力だよな
問題解いていて面白いと言えば面白いのだけどね
まあ、でもその辺りのしょぼい二流、三流プログラマで成り立っているいわゆる「システム開発」「アプリケーション開発」とか募集している会社だったらプログラミングコンテストで良い成績を残せる、と言わないまでも正解を提出できるレベルだったら間違いなく有用なことに違いはないと思うけど、やっぱり採用ツールとして見るとプログラマを募集している職業の求人ツールとしてみるとどうなのかな
会社が、自分の会社にあった問題を掲載して、その問題に対する姿勢で会社として雇っていいかどうか判断しないとダメだよな
でもfizzbuzz程度も満足に書けない人達で成り立っている会社だったら別にどんな問題でも解答できたら即採用候補ってことでもいいかもしれないけどね
就職先を探すために利用するの諦めようかな
なんか仕事探す良い方法ないかね
なんとかナビとか普通の求人サイトに載っているような求人なんてどうせイマイチな会社ばっかりだからあんなもんで仕事探したくないんだよな

たまには豆知識

'aは(quote a)の代わり
リードマクロで実現されている

quoteと言う関数の存在が普通の人にとっては、先ずよくわからない点だろうな

こいつの素晴らしさと言ったらないのだけど

lispの沢山ある良いところの一つ、だったらこんなんで良くね？って感じであっさりとスゴイ斬新な機能を実現しているところだね

へんな名前の関数

nconcはなぜこんな変な名前になったのだろうか
appendの非破壊版とはとても思えない命名
先頭の「n」で破壊版関数を表現して、多分そのあとにはconcatenateが続いていると思うのだけど、concatenateとappendって英語的には大体同じような意味なのかな
素人目にはnappendで良かったような気がするけど
しかし、このあたりもマクロを利用すればなんの障害もなく覆い隠せるからlispはすごいな

common lispに対する偏見

S式が苦手
ポーランド記法が受け入れ難い
見かけがとっつきにくい
って言うか括弧が多いよね
なんか変だよね

マクロの威力を活用できていない(高階関数が利用できれば十分なレベルでしか利用できていない)

確かに括弧にもいろいろな意味があるので一概に()で対応するのは微妙かもしれませんね[]{}も利用できるならそれに越したことないかも
別にソースコードの表記上[]{}が利用できるだけで()と同等に扱われるで問題ないのではないかなと思います

オブジェクトのアクセサの表記は大賛成ってかこれがないからCLOS使いたくないかな

関数名と変数名の名前空間が分かれているのは好意的だけどな
しかしfuncallは勘弁って感じなんだよね

括弧は補助記号との認識が強いから受け入れられないのか

condは括弧が多いから鬱陶しい
少し括弧を減らすことはできないかね
って言うかいまの括弧が最適なのか、これ以上は無理なのか

setfとsetqの違い

一言でいうとsetfはsetqの一般化
setfの第一引数がシンボルならsetqにそのまま展開されるだけ
第一引数が式なら対応する式へ展開される

lispの括弧の扱いについて

って言うか、演算子の優先順位とかブロックとかでどっちにしても括弧が必要になるから別に最初から括弧だらけのLispでいいんじゃね
と思いますが、こう思うようになったら重症なんだろうな

だってさ例えば

ある変数が10 < a < 15の範囲にあるかどうか判定する場合とかだと

if ((a < 15) && (10 < a)){

文ブロック

}

else {

}

ってなコードになる訳でさだったら

(if (and (< a 15) (< 10 a)))

って言うのでも別に全然違いがないと言うかそう大きな違いが無いと思うのだけど

lispと言えばとにかく括弧と言う印象をもたれがちですけど、この括弧の扱いが逆にマクロとかで生きてくるんだけどな

逆に括弧で成り立っているからこその良い側面があるのだけど

と言い出したら「ああ、こいつはいわゆるlisperだから相手にすると大変なことになるからかかわらないでおこうと」と思われるのだろうな

キーボード配列QWERTYの謎

dvorakさんが意外とインチキ系だったって言うのが一番の収穫かな
二番目はqwertyの市場原理で良い物が市場を独占できるわけじゃないって理論も別に正しくなかったってところかな
結局どんな配列が効率的なのかよくわかんない
って言うかなんでこの配列になっちゃったかは結局キーボード入力とはまったく関係ない筋道だったと言うか、コンピュータのキーボードを微妙に関係ないタイプライターをもとにしちゃったのが不幸の始まりなんだろうな
入力装置のことをあまく見た結果なんだと思う
あと、石田晴久氏なんかも都市伝説の流布に一役買っていたって言うのが以外でした
得られた教訓としては一次ソースをあたれってことだよね

linux mintでgnuplotを利用する

apt-getでインストールしてターミナルからgnuplotで起動すると

Terminal type set to 'unknown'

と表示されてgnuplotが正しく動きませんでした

解決策は追加でgnuplot-x11をインストールしました

sudo apt-get install gnuplot-x11

無事実行できるようになりました
やっぱり数値データだけ見てても面白くないね
視覚化されるってやっぱり重要だな
なんだかんだ言ってもcuiには限界がある
guiの限界の高さは伊達じゃないな

積んである本について

減らしましょう

アンダースタンディングコンピュテーション
プログラミング言語C++
人工知能の基礎
関数型プログラミング珠玉のアルゴリズム
On Lisp
LET OVER LAMBDA
数学で織りなすカードマジックのからくり
Vim scriptテクニックバイブル
リファクタリング新装版
コンピュータ囲碁
すごいErlangゆかいに学ぼう！
エリック・エヴァンスのドメイン駆動設計
入門データ構造とアルゴリズム
プログラミング言語AWK
 Haskellによる並列・並行プログラミング
ピープルウェア
アルゴリズムパズル
コンパスと定規の幾何学
抽象によるソフトウェア設計
関数プログラミングの楽しみ
Real World Haskell
Erlangプログラミング
ヘネシー＆パターソンコンピュータアーキテクチャ
シューティングゲームアルゴリズムマニアックス
型システム入門
ユークリッド原論

pc買い替え

ASUS
B85M-G
core-i3 4160
intel ssd 530 series 120GB
システムメモリ4Gx1

マイナビやっぱりスゲーや

ソフトウェア業界特集
最新用語集
http://job.mynavi.jp/conts/2016/tok/p/189/

「最新用語集」と謳っちゃってるところが味わい深くさせるポイントですよね
個人的に気に入った用語をいくつかピックアップします
この辺りのセンスでその人の特徴が掴めそうですが
感覚的には一発当ててから業界から消え去った有名人と言ったところでしょうか
「あの人は今」的な

シンクライアント
いつの時代の用語だよ

オフシェア
しばらく聞かない用語だな

グリッドコンピューティング
たしかに聞いた覚えがある

このページの一番の見どころはJava、C言語、C++、COBOL、FORTRUNが連続で登場するページ最下部ですね
ここは非常に味わい深い箇所ですね
フォートランなんてスーパーコンピュータで使われているって断言しちゃってる始末ですし
このページの内容って二十年くらい使いまわされてる内容とかも混ざってそうなんだけど
コボルとフォートランなんて名前がでてくるだけでも十分笑いが取れる、出オチの域に達しておられますからね
C++の説明も、オブジェクト指向って言うよりもジェネリックプログラミングの方が全然有用だと思うのだけどまったく触れられていない始末です
スゲーな、さすが天下のマイナビ様だな
マイナビから募集するとこんな最新用語を把握されている方達と接触できるのか
まあでも今の管理職辺りにはウケそうな用語をあえて狙って掲載してるのかもしれないけどね
しかしスゲーな

新卒学生だとこの手の情報を真に受けちゃう人っているんじゃないの
って言うか今時の大学でプログラミングってやっぱりいまだにフォートランやってるのかな
今だったらJava教えてるところとかありそうだけど
やっぱりなんだかんだ言ってもC言語が本命なのかもね

こういう就職斡旋業者って結局この程度だと思うとこういうサイトを利用して仕事探そうなんて気が失せるよね
逆にマイナビに掲載していないことを強みにできるのかも
あるいは、掲載依頼する企業側も閲覧する側もこの程度のレベルでお互い釣り合いが取れて均衡が保たれていることは丸く収まっていいことなんだろうな
結局こういうサイトから応募して就職できた人が今度は採用する側になってっていう繰り返しが行われるんだろうな

アンダースタンディングコンピュテーションの感想の続き4

なんとか読み進めています
内容は個人的にはなかなか面白いし、興味深い分野ではあるのだけどこれが実際どう活かせるかよくわかんないよな
あと、そのへんのアプリケーションエンジニアにとってこのような内容が必要なのかと言われるといわゆる「プログラマ」には不要、とまでは言わないけどこんなことやっててもあんまり意味無いような気がするので需要は大変少なそうですね

コンパイラ作ったりする人たちにはとっても有益な、必須な内容だと思うのだけど別に誰かが作ったOSで、誰かが作った開発環境で、誰かが作ったライブラリで誰かが作ったソースをコピペで作業している人にはまったく不要な内容なんだよな
この本の内容を理解して実務に取り入れられるような会社や仕事ってどこにあるんだろうね
webでmvcとか必要な場合とかこんなことが役に立ちそうなんだけど
というかこの本の内容の知識がないとまともなmvcとか作れなさそうなんだけど
あるいはphpとかで適当なmvc作る程度だったら別にどうでもいいのかもしれないけどね

でも、今どきプログラムとか業務で行っている会社だったら自社DSLとか構築していると思うのでやる気になればどの会社でも活かせるって言えば活かせるか

あとはやっぱり結局人間次第ってか

挫折した本について

http://shop.ohmsha.co.jp/shopdetail/000000004066/
久しぶりに挫折した本
とにかく難しい
何が書いてあるかさっぱり意味不明
と言うとちょっと言い過ぎですけどまあ難しいな
挫折した

と言うことで挫折記念にいままで挫折した本の紹介
コンピュータプログラミングの概念・技法・モデル
http://www.shoeisha.co.jp/book/detail/9784798113463

On Lisp
LET OVER LAMBDA
コンパスと定規の幾何学
実用Common Lisp

アンダースタンディングコンピュテーションの感想の続き3

表示的意味論が意味不明
全く意味がわからん
頭の切り替えが全然ついていかない

スモールステップ意味論の感想としては、まず思ったのがなんでこんな回りくどい方法をするんだと思った
再帰的に処理すれば、いちいち式の簡約とかどうでもよくて、特にwhileループなんてなんじゃこりゃの見本みたいでしたけど、解説を読んでよくわかった
スタックを消費しないで実行しようと思うとスモールステップ意味論が最適なんだなと

逆にビッグステップ意味論は馴染み深いと言うか、好みにあっていると思った
やっぱり再帰的に物事を処理するっていうのは直感的にわかりやすいんじゃないかな
しかし、このように理解できるのも関数型言語のOCaml、Haskellで再帰脳を鍛えた賜物かもしれないしね
関数型を訓練する以前だったらビッグステップ意味論の方が理解できなかったかもしれない
でも簡約と言われれば直感的に再帰で処理したくなるような気がするけど
ビッグステップ意味論を実装するときは、まあそうだろうなと納得して実装できた気がします

で、締めの部分で登場したパーサについてですけど、このあたりのパーサとは無縁のCommon Lispっていうのの素晴らしさ、演算子の優先順位的な話もちらっとありましたがこの辺りに対するLispの優位性って本当に素晴らしい
この辺りのことでどうこうしなくていいS式こそ人類の至宝と言ってもいいのではないでしょうか

ポール・グレハムの気持ちが

微かに、僅かに、微塵ほど、分かる気がする
defunとかdefmacroとかの理解がいわゆる「関数定義」や「マクロ定義」程度で終わっていると本当にもったいない気がする
もっともっと勉強したほうがいいかもしれない
Common Lispは知れば知るほどその恐ろしいほどの奥深さに戸惑うとともにいままで使ってきた他のプログラミング言語の威力の弱さに驚く
たしかダグ・ホイトだったと思うけど、Lisp以外の言語はLispの機能を削ぎ落したものだと、ある言語はLispのこれを取り除いたもの、別の言語はこの機能を取り除いた、とかそんなようなこと言ってた気がするけど、本当そのとおりだわ
びっくりする
少しづつだけどLisp勉強してよかったと思うよ
こんな素晴らしい言語を使って仕事ができたらなんて素敵なことだろうと思うけどlet over lambdaのキャッチじゃないけどこんなことやっているプログラマってホント何百人に一人とかそんなレベルなんじゃないのかな
頭のなかでこんなことできればいいのにというアイデアが形にできそう、できる言語って他にあるか
否、ない、Common Lispこそ唯一の頂点だと思う
素晴らしい
(読み返してみるとlisp信者丸出しでキモいことこの上ないですね)

アンダースタンディングコンピュテーションの感想の続き2

スモールステップ意味論ひと通り実装してみても結局なにが言いたいか理解できたのが30%くらいかな
少しづつ、一歩づつ評価を繰り返して小さくしていくということが言いたいのか
確かに最後のwhileの繰り返しは少しだけ思っていたことと違うと言うか繰り返しってもっとあっさりと実装できるかと思っていたら意外と手間がかかっていると言うか

まあなんにしても結局普通の会社や仕事ではなんの役にも立たない、こんなことやってるよりもググってコピペでプログラム作ってはいできましたって人のほうが役に立つと思われるんだろうけどさ
さもできる風に装っておいてどっかから拾ってきたプログラムを貼り付けてごちゃごちゃやってごまかしている人たちには無縁の話だろうな

アンダースタンディングコンピュテーションの感想の続き

足し算、掛け算演算を実装して、改めて実感できたことはやっぱり中置記法のアホさというか前後置記法の素晴らしさが際立っておりますね
演算子の優先順位とか結合法則なんて話を複雑にするだけで何一つ良いことないのになんでこんなアホな記法が世に蔓延っているのかまったく理解不能
演算子の左右にしか、しかも左右両方に対象を配置しなければ演算子として成立しないなんて本当にアホ丸出し
せっかく偉大なヤン・ウカシェヴィチが発見してくれたものを生かせない人類ってなんてアホの集まりなんでしょうか
大体さ、式なんて正確に記述できるかどうかだけが重要でさ、記述しやすければもうなんでもいいような気がするのだけど
本当、心の底から思うのだけど優先順位とか結合法則とか余計なもの持ちだして、人類はアホの集まりだからただでさえ悪い頭を余計なことに費やしてさらに悪くしているってなんてアホな集団なんでしょうか
ジョン・マッカーシー、ヤン・ウカシェヴィチこそが人類の希望だったと断言できる

アンダースタンディングコンピュテーションを読んで

アンダースタンディングコンピュテーションを読んで早速感化されてcommon lispでsimpleを実装してみました

githubで公開しております

https://github.com/andomasaharu/simple

しかし、この本を読んでいる人って日本に何人くらいいるのだろうか
オライリーで売れた数とかわかるのかしら
出版物だと印税の関係でどれだけ売れたか正確に把握する必要があると思うのだけど公表はされないだろうな

「スモールステップ意味論」と翻訳されておりますが実際、原始的と言うか単純な言語を実装してみてつくづくコンパイラの有り難みが身にしみてわかった気がしますね

やっぱり改めてですけどCommon Lispは偉大だなと思った
って言うかやっぱり中置演算うざいよ
ポーランド記法最高と再認識できたことが良かったです、とりあえず
Lispの文法って圧倒的に偉大だよな

CLOSについて

もちろん:accessorで生成される関数も多態させられるんだな
やっぱりもちろんだよね、当たり前だよね
:accessorが多態させられなかったとしたらとんでもないことだよな
CLOSってなんなんだよって感じになっちゃうもんね

ドット対って「.」の左右にスペースが必要なんだと今更知りました
ごめんなさい、もっと勉強します

CLOSを使った感想

defmethodと組み合わせると多態性が表現できて素晴らしい
いまのところ継承とか登場しないから快適
多態性のみ利用できるので素晴らしい


make-instance 〜〜って言うのがイチイチ面倒だからインスタンス生成の補助関数が必須か
って言うかいわゆるメンバ変数の参照が本当に面倒だ
いわゆるメンバ関数の呼び出しもグローバルな関数呼び出しだから
オブジェクト->メンバ
的な呼び出し方ができるといいのに
リードマクロでやるなら
(#@インスタンス->アクセサ)
とかになるんでしょうか
幸いCommon Lisp使っているので、マクロでなんとかできないもんかね
普通の人(OOPは実装の継承とカプセル化がすべてだと思っている、世の多数派のこと)がCLOSのdefclassとdefmethod見たらなんじゃこりゃって思うだろうな
Common Lispでカプセル化だったら高階関数使ったほうが圧倒的に便利だろうし


CLOSで多態させたときのデバッグと言うかどのdefmethodが呼ばれてエラーになっているか分かりづらかった印象がある
これはCLISPのデバッガの使い方がイマイチわかっていないところが大きな原因だと思うけど



まあでも不満点はIDE的なサポートがあれば別にどうってことないような
インスタンスから呼び出せるdefmethodリストも列挙するのは簡単だろうし
VC++のように背後でコンパイラが動きまくってdefmethodされているオブジェクトのテーブルでも作っていま記述しているインスタンスから呼び出されるであろう関数のリストを作るのは容易にできそう


defmethodのいいところは、特定のクラスで判別して呼び出す関数を振り分けられるのと合わせてhaskellのガードのotherwise的なその他を設定できるところだな
この動作は素晴らしいとしか言いようがないです
c#では真似のできない芸当、本当に素晴らしい
defmethod作った人は本当に頭がいい人なんだろうなと思う

common lispをどうやっているか

hyper spec参照
めちゃくちゃ充実しているリファレンス
(microsoft系の人へ：msdnなみの充実度)

clispのreplでお試し
hyper spec参照してそれを試す
引数の順番とかすぐ忘れるから

実践common lispで勉強
入門に向いていると思う

land of lispは指向が違うかな
プログラミンが好きになるためのとっかかりや、他の言語やっていてcommon lispスゲーってなるためには向いているかもしれませんが入門には向いていないかも
いわゆる「common lispにしかできないこと」が書いてある感じ
だから事前に他の言語を知っておいた方が楽しめる本だと思う

on lispでモチベーションアップ
これを読むと、とりあえずマクロが作ってみたくなる
けど、実用的なマクロは作れない
マクロも実践common lispのマクロの方が理解しやすいものが多いと思う
って言うかこれを読むためにはcommon lispがそれなりに使いこなせないと理解するのはなかなか難しいと思う

let over lambdaで混乱する
on lispより強烈な本

armでなにかcommon lispがまともに動かせるといいな




なにに使っているか
プログラミングコンテスト系の問題を解くためのみ

使い心地は？
IOがないならHaskellの方がいいかな
HaskellはIOがあると大変苦労するので
(問題の回答とIOで半々くらいの時間を使うので)

昨日YSP天白へMT-07の試乗にいきました

曇時々晴
とても丁寧な対応でした
素晴らしいお店、皆さんもお気軽に訪問してみてください
昨日は真冬の寒さにもかかわらず非常にたくさんの人が訪れておりました
実物のMT-07を間近で見たのは初めて
サイズは思っていた通りの印象
大型に属しますが車体サイズは中型に分類されてもいいのではないでしょうか
(下記印象について補足
筆者は現在WR250Xに乗っています
ですので下記は基本的にWR250Xとの比較と思ってください)
まず引きお越し、サイドスタンドを払う際に少し起こしましたが見た目よりも軽い感じがしました
ハンドル位置も適度に高いので引き回しもあまり苦にならない印象を受けました
乗車姿勢ですが、MT-07のステップは足の真下にあります
真下と言うのはシートに座って足を素直に引き上げたらステップに足が乗せられるという場所です
ネットの記事でよく見かける足つき性の良さについては少し疑問です
シート、タンクは足つき性を考慮されていると感じましたが、そのまま足を付こうとするとステップがじゃまです
ステップが真下にあるので走行中の乗車姿勢は非常に自然なのですが、その自然さの犠牲として停車時の足つき性が悪化していると思います
まあ、バイクは走行中の姿勢の方が圧倒的に重要なのでこの点は許容すべき点だと思います
ハンドル位置については上体が適度に寝る印象でしょうか
起きているわけでもなく、かといって寝すぎているわけでもない印象
シートについてですが、一番印象的だったのがシートです
とにかく「久しぶりにシート座った」と思いました
WR250Xのはあれは一体なんなんでしょうか
エンジンの印象は適度なドコドコ感があっていい味だしているといった感じです
走りだしは非常にスムーズMTと言っているだけあって低回転から適度にトルクが出ていると思います
四気筒と違ってもっとクセがあるかと思ったらそうでもない感じがしましたが、ゼロ発進は少し慣れが必要に感じました
乗車姿勢は比較的楽な姿勢を取ることができます
ですので高速道路などは少し辛いかもしれません
低い速度行で風を受けながら走ることを狙っている感じですね
かっ飛ばすバイクでもないですからね
かっ飛ばすことが目的ならMT-07は初めから対象にならないと思いますから
そんなにスピードを出していないのですが、街乗りは非常に乗りやすいバイクだと思います
軽い、低回転トルクの出方この二点はいいですね
曲がり方は交差点を二、三曲がっただけですがもっとピーキーな曲がり方をするかと思ったらこちらも滑らかな味付けになっていると感じました
WR250Xがピーキーすぎるので普通の人にはMT-07もピーキーに感じるかもしれません
曲がり始めにフロントサスがすごく沈む印象がありました
ターンインの際にすこしフロントブレーキをかけましたがそれに反応してグっとフロントが沈むのを感じました
それに比べてリアの方はそんなに沈むとか動く感じを受けませんでした
フロントが動く動作がお好みならオススメですがフロントが暴れていると感じるなら不快に思う動きです
あとはブレーキが安心できるような印象
ブレーキ効くなって感じ
せっかくなのでついでにMT-09も試乗させてもらいました
こちらもよく記事などで「07と09は別物」みたいなものを見かけて「本当か？」と疑問に思うと思うんですよ
一緒なんじゃないのってどうせエンジン違うだけでほとんど一緒じゃないのかと思うんですけど乗ってみたらびっくりするくらい違っていましたね
ホンダのみたいにカウルつけただけやちょっと見た目を変えましたみたいなものじゃなくてかなり性質が違う、狙っている層が違うと思います
MT-09は全然レーシーな感じMT-07は、まあ普通に「スポーツ」を狙っている感じなんですけどMT-09は明らかにスポーツは狙っていなくて「サーキットやレース」を意識している感じがしました
SSっぽい、いわゆるストリートファイター系ですかね
SSはいやだけどレーシーを求めている人にはばっちりだと思います
逆にスポーツやツーリング派はMT-09は過激に感じるだろうな
MT-09はステップがかなりバックステップ
バックでアップなステップでした
ハンドルも少しだけですが低く感じるので姿勢ははっきりうつ伏せ状態ですね
MT-09は見た目をもっと激しくレースに寄せてもいいくらいな印象を与えてもいいのではないかと思います
MT-07は見た目のとおりと言えばそうなるかな
あんな見た目で乗り味もそんな感じですよね
で、結局なんですけど試乗してみて後悔したというか買い換えたくなくなってきたと言いましょうか
WR250Xの良さを改めて認識できたというかWR250Xがとにかく良く出来すぎているんじゃないかなと
違うバイクを乗る度に思うんですけどWR250Xって相当良いバイクなんだなと
本当にすごい性能、エンジンも足回りも車体も全て良い
唯一ダメだと思うのは、エンジンに対してフロントブレーキが効かないところかな
あとは何と言っても圧倒的にチューブタイヤってところが曲者だよね
難点欠点
チューブタイヤって何一つ良いことがないんじゃないかな
オフロード走る場合は岩があったりなんだかんだいってもいろいろあってのオフロードって感じがしますがオンロードでチューブの必要性が全くないですよね
本当に百害あって一利なし
ハブが使いまわせるだけか
チューブタイヤのバイクには二度と乗りたくないと言うことが分かってまあ良かったというかこの世にチューブレスタイヤがあって良かったと思えるところかな

pitftが映らなくなった

raspbianをアップデートしたりファームウェアをアップデートしたらpitftが光るだけで映らなくなりました
再度設定を行うシェルスクリプトを実行したら無事映るようになりました

raspberry piでhaskell

せっかくraspberry piを購入したので利用しています
主な用途がlinux環境として利用しています
haskellやlispを動かす環境として利用していますがlispはclispが調子悪いしsbclも動きが悪いしでちょっと困っています
arm環境での動作は基本的にイマイチなのかな
なんか「ghci 7.4.2 is finally working on arm」って言うエントリーがあるのですがraspberry piで動かないのよね
ghciが使えないとちょっと不便なのでhugsを入れてみたらこれまた微妙に古いしghciに比べて使い辛い感じがします
arm環境でうまいことhaskellを実行する方法はなにかないものだろうか