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

に関してです
スタックを消費してもいいから計算をなるべく簡約したい場合はビッグステップ意味論が適している
スタックの消費がやばい場合はスモールステップ意味論が適している
と言う認識でいいのだろうか
で、具体的にどちらがどんな場面に向いているかと言うことなんだよな
普通にビッグステップ意味論だけでまかなえそうなんだけど無理なのかな
スタック、と言うか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の市場原理で良い物が市場を独占できるわけじゃないって理論も別に正しくなかったってところかな
結局どんな配列が効率的なのかよくわかんない
って言うかなんでこの配列になっちゃったかは結局キーボード入力とはまったく関係ない筋道だったと言うか、コンピュータのキーボードを微妙に関係ないタイプライターをもとにしちゃったのが不幸の始まりなんだろうな
入力装置のことをあまく見た結果なんだと思う
あと、石田晴久氏なんかも都市伝説の流布に一役買っていたって言うのが以外でした
得られた教訓としては一次ソースをあたれってことだよね