_ ひきつづき体調悪い。アラーム鳴ってるのにしばらく気付かなかった。
_ 以前も借りた。当時は 日本語まわりの記述が少ないとどうもねえ...という感想だったが、 最近英語の教材づくりに関心を持っているので、そういう視点で見ると 俄然魅力的になってくるから現金なものだ。
_ ああいそがしい。大きなことばかり言って結局何もできない人達が多すぎて辟易する。 相手を批判しているその言葉をそっくり自分に跳ね返らせたときに どう受け止めるのか見てみたい気もするし、見たら余計うんざりするだけのようにも思う。 こんなのばっか集めてどうしたいんだ
_ なんか適切な略しかたはないものかな。
_ ひらしょーさんに私の記述をフォローいただいた。 私の記述に対するものだとは 書いてないが。といちいち断りを入れるのは欝陶しいので、以下は私の記述に 対して反応いただいているという前提で書いている。
_ 「→」の件。たしかにちゃんと書いてあったのを見落していた (p42←初版)。 出てくる場所がおかしいわけでもないし、目立たないわけでもないので、本当に 単純に見落していた。お恥ずかしい。 ただ、後付けの理屈を並べるようだけど、刻印されていない記号というのは 入力させるのが意外と大変という気持があったのは確かだ。仕事で関わったデータでも、 この横棒はどうやって入れたのだ？というようなものがあったりしたので、 慣れない人には大変なのかなあと想像していた。それを言いだすとそもそも IME自体が結構なハードルだし、この本に取り組む対象としてそのあたりで つまずくかどうかを設定するのは難しいところだなあと思う。 私のは無責任な想像でしかない(この本に取り組む人はPC操作にも明るくないという想像)
_ その上でよく思い出してみるとさらに2つの感想があった。ひとつは、 前段落の話のつづきで、(→は入力が大変だと思ったので)イコールで いいんじゃないかなあ、というもの。イコールがふさわしくないということは 以前読んでいたので頭では分かるけど。 もうひとつは、その後で気付いたんだけど、 矢印の向きだ。私の感覚では、イコール以外でここで使う記号として 思い浮かぶのは「→」じゃなくて「←」だった。メモリを「箱」として イメージしていたからだろう。メモリを「スイッチ」というイメージで 表現するのがとても新鮮だったので、自然と「→」の向きに対する違和感を 忘れていたらしい。この私の感情に関する説明は完全に後付けだけど。 とはいえ、そう考えると、第一印象である 「イコールでいいんじゃないかなあ」というのはもちろんよくないんだろう。
_ なお、「スイッチ」の比喩が適切なのかどうかは今のところ判断できていない。 どうしても「状態」という暗黙の前提がついてまわるような気がする。 と思ったのだが、あらためて読みなおしてみると、 メモリの「一部」がそうなのだ、という前置きもあるし、そのすぐ後に このあたりのフォローが本文と脚注でなされているので、折込済の話なのか。 うーんちゃんと読めてないな。そもそも手を動かしながら読んでいない状態なので論外だが。
_ 「参照」の件。私がひっかかったのは2つで(根は同じなのだけど)、 ひとつは、いざSunabaを出て別のことに取り組み始めたときに、 同じ用語を違う意味で使っていることに対して混乱がないかな？という点。 「参照」そのものの意味もあるし、「参照渡し」のような用語と思い浮かべる意味の ギャップといったものも想像した。 もうひとつは、Sunabaを出たばかりのときに他者とのコミュニケーションに 混乱が生じるのではないか、という心配。
_ 用語について私が意識するのは、 それが適切に実態をあらわしているのか？というのと、 伝達する際にそれが適切であるのか？という点がある。 両者は常にトレードオフの関係というわけではないが、 すでに定着してしまっているものを覆すには相当の労力が必要だと思っている。 用語はコミュニケーションの道具である以上、 共通の理解の上で築かれてゆくものなので、 前者が満たされたとしても後者の気配りを忘れるわけにはいかないのでは ないだろうか。といったようなことを思いながら、前回は感想を 書いた。
_ 「英断」と書いたのは、後者を 犠牲にしても前者をとった、と想像したからであり、 「うーんそれはどうなんだろう？という成分が多めの感情がある。」という 煮えきらない表現をしたのは、 それによって起こる混乱・害が想像できなかったからである。一時的なちょっとした混乱で済む話なのかもしれない。そのくらいであれば、 実態に合わない馴染めない用語を使うよりは、実態に合った適切な用語を 使うというのも十分割に合うと思う。 そのあたりが想像できなかったので、それはまずいんじゃないかなーというほどの 感情は生まれてこなかったし、そこのバランスが自分には興味深かったので、 重複になるが「英断」だと思った、という経緯だ。
_ また、「条件実行」はともかく、と書いたのは、私の知る限り「条件実行」は ARMのものしか思いつかなかったので、 そのような用語であれば混乱はなさそうだな、と判断したから。 (Sunabaを出てすぐにARMのアセンブラやる人がそんなにいるとは思えなかったし、 条件実行の定義はARM側でされているので)
_ この際なので(まだ取り組んでいないので)、 本が出る前に思っていたことを今のうちに書いておくと(若干手遅れだが)、 Sunabaのアーキテクチャについてはある程度見聞きしていたので、 それがどう本になるのかと想像しつつ形づくられた疑問というか期待は、 「メモリの中身がいつでも参照できて、何もしなくても状態を保持できる」 というのは別に自明な仮定ではないし、 他の可能性がありえないわけじゃないので、そのあたりがどういう描かれかたを しているのかなあというものだった。もちろんそういうことが書いてあるのかどうか、 書いてあるべきかどうかということについて意見があるわけではなく、 単にそういう思いが形づくられたというだけの話なのだけど、忘れてしまう前に 書いておこうと思った。 我ながらよくわからない段落だ。 「だから何」という合いの手を入れたくなってしまう。
_ やっと週末。いろいろ整理していたら 週の56%が定例打ち合わせに占められていることが分かり愕然としているところ。 こまぎれの時間をぼーっと過ごしてしまったら(しまうな)あっという間に 一週間終わってしまうのも当然だと思った。打ち合わせとパワポ(資料)と ワード(議事録)いじって生きてるような気がしていたが、 数字もそれを裏付けているな。
_ ともあれ落ち着いて作業できたのでだいぶ押し返すことができた。 (土日に落ち着いて仕事している場合ではないが)
_ ずっと昔に買った、Rich Dad, Poor Dadを今更ながら聞きながら読んだ。 大胆に飛ばされていて驚いた。 段落の途中で省略、段落ごと省略、へたすりゃ1ページくらいまるまる省略ということが普通にあって (後ろに行くほどひどい) これ元になっている本が違うのかしら？ 短くしたバージョンのようなものがあるのかしら？などと思ってしまった。
_ 先日「Switch」を買った。 「スイッチ!」は何度でも繰返して読みたい本なので、 どうせ繰返し読むなら原著を聞きながら読もうと思って買った。 オーディオブックはなんと6枚組だった。 わざわざ「Unabridged」と書かれているので、オーディオブックというのは いろいろ飛ばしながら読むのが普通なのかな。 そしてトラックが無造作に切られているのでシークがけっこう面倒。そうそう RhythmBoxにはブックマークみたいな機能がないらしく (プラグインでも見当たらなかった)、長大なオーディオブックをRhythmBoxで聞いていると、 他の音楽を聞こうとしたときに再生位置をわざわざメモして覚えておかなければいけないのがちょっと億劫だ。オーディオブック用にプレイヤーを分けようかとも ちょっと思ったが、それはもっと億劫だ。(億劫がってばかりで話にならん)
_ 取り組まないで能書きを書いていてもしかたないので開始。 ああそういえば家のWindowsマシンはVistaだった。すでに2世代前だ。 新規作成がXじゃなくてWなのが今となってはうっとうしい。Xには慣れたくないなあと ずっと思っていたのに気付いたらとっくに慣れていたようだ。
_ 指示の通り落としてきたので始めよう。 といいつつ追加パッケージに収録されているドキュメントを読み始めてしまった。 本に取り組むためにはまったく不要だが、いろいろと気になる部分について あらかじめ深く考えられていることに後から気付くということが多いようなので そのあたりを少し見ておきたくなった。たとえば昨日の「→」の話とか。
_ コンパイラとVMは分離されているのか。ではコンパイラだけ使わせてもらって VMは作るということも可能かもしれない。なんだかんだ言って Windowsマシンに向かって作業する時間がとりづらいというのが取組みを滞らせる 原因の一つになっているので、本に対する取組みが終わった後はもうちょっと やりやすい環境を作りたいところだ。
_ などと30分ほど読み耽った後に取り組み始めた。2章。100足すと下に行く (100x100) というのは分かりやすいなあ。番号手打は辛いんじゃないかと思ったが、 6YYXXでいいわけか。 (追記: 6XXYYと書いていたが6YYXXの間違い)
_ おお描画が目に見えるくらい遅い。ウェイトかかってるのか。そういえば 1周流したときにそういう記述(手加減)を見掛けたのを思い出した。 が、こんなにえげつないウェイトとは思わなかった。
_ 3章はくり返し。スイッチでない番号を使って覚えさせる(固定させていない数)際に、 以前試したときに0番をいじっても何も起きなかったので ここを(固定させていない数として)使おうといった表現がありウムムとなった。 それはSunabaのアーキテクチャについてイメージが出来上がっているから感じる違和感なのだろう。 それ以前に、目に見えるところで何も起こっていないから 使っていいとはならないのではというような違和感もあるのか。 もちろんここで0番は使っていいんだよ、なぜならそこはそのための場所だから、 という説明を入れるのはさほど難しくないだろうし、 ここでは著者が保証するので事情はともかく使ってよい、 といった表現も可能だったと思う。 が、不要と判断されたんだろう。
_ くり返しのコードを書いている当初はSunabaで実行しても何も見た目の変化がないので 本当に期待通りの回数まわっているのかは分からない (書換えが遅いのでDnDしてから「プログラムが最後まで実行された」が出るまでの タイムラグでもある程度「回数が増えたかな」という感じはつかめるけど)。 きちんと頭で追いかけて理解しなければいけないように仕向けられている。 と思いきや、問題入りのコードを直す際に「結果から考える」という 別のアプローチを出してくるのは絶妙だと思った。
_ そうそう昨日書いてて気になっていたこと(→のかわりに⇒を使ってみる)を 試してみたらエラーになった。そういう間違いがあるのかどうかすら想像できないので 我ながら少々paranoiacだな。
_ ちょっとフライングして四角形を描いてみようとした。二重ループでやって... と思ったら異常終了した。「メモリ範囲外をいじろうとした(番号:6505000)」らしい。 なんでそんなでかい番号に...？と思うのと、 掛け算のところに括弧つけるのを忘れていたと気付いたのはほぼ同時だった。 演算子の優先順位はないと書かれていたなあということを思い出す。
_ 数学のルールを採用しなかったのは「さほど便利とは思えない」からと書いてある。 そうなのかな...？ もちろん括弧をつける習慣は大事だし、 数学のルールを覚えるよりも括弧をつけるというルールの方が単純だ。 新しく覚えるなら私もそうだと思うんだけど、 小さいときからずっとやってきた数学のルールと違う結果になることは 驚き、最小の法則に反すると感じてしまった。 と思うのは数学のルールが身に染みているだけで、誰でもそうというわけではないのかな。
_ いっしきさんも取り組んでいるらしい。 テトリスを見せてもらった。私は2時間かけてようやく四角形まで辿りついた (メモとりながらとはいえ) のに対して いっしきさんは同じくらいの時間でテトリスの基本形が出来上がっていた。 さすがだなあと思った。
_ 今日も会社に行こうと思ったが電車の発車時刻を1分勘違いしてしまい改札の 手前に着いたときにはもうドアが閉まっていた。 今日は会社に行くべきではないのだと誰かが言っていると判断し休むことにした。
_ データは溜まって分析もできるけどそれをどう表現したものかなあと考えていたところ この本のことを思い出したので借りた。
_ 前半はものすごい勢いでグラフを作っている。軸つくったりラベル作ったりと、 文字通りグラフを描画するところをけっこうなページ数使ってやっている。 一瞬思わず引いてしまった。もちろんそういう作図用のライブラリはあるんだろうし、 それを使えば簡単に...! という構成もありうるんだろうけど、 最終的な目的である「インタラクション」を考えるとこうやって1から グラフを作ってゆく能力も必要になるということなんだろうと理解した。
_ けっこういろんなことを扱っていてProcessingそのもののについては さほど充実していない印象。どうやってデータを集めてくるのか、どうやって 加工するのか、ということのウエイトがかなり大きくて、いかにそれを見せるのか というものは相対的に少ない気がした。
_ Processingの本は2冊目。もう一つはBuilt with Processing。 Processingはやはり見れば見るほどJavaなので、 何がそんなに世の中のクリエイターさんをひきつけるのかが分からないままだ。 垢抜けた図を描くための気の効いた機能が最初からあるわけでもなさそうだしなあ。 ユーザ数が増えてきてそういう機能があとから充実しているという状況だとは思うけど、 それは結果の話であって、ユーザ数が少ない頃に何を魅力と感じたのかということに 対する答えにはなっていない。 この本で扱っているディレクトリ構造をどうにかするというのが ちょうど自分のやろうとしていることとかなり近いので、実際に取り組んで体得してみたいと思う。
_ ProcessingはSunabaを出て次に触るものの候補としても考えている。他には Sunabaの本の中にある通りJavaScriptというのもあるし、Scratch、Unityなども あるのか。このあたりは次に求めるものが何なのかという 難しい問題を含んでいるよな。ひらしょーさんの本を読んだ後に次に進むべき 方向ってどんなものがあるんだろう。環境としても、書籍としても。
_ Sunaba本...と言いたいところだが動向を見守ってからとする。
_ 3章の途中から4章にかけて。 今更だけど、メモリの参照と演算が混在できるので書くのは楽だ。 「再起動」ボタンは元のプログラムを 読み直してくれることに気付いた。したがって書換えるたびにDnDしなくてもよいようだ。
_ だいぶ1行が長くなってきたと思ったところに折り返しのルール。 オフサイドルールはないのか。これはまあどっちでもよい気がする。
_ 「もっと短く書く方法はないか」はてごわいな。ここまで来ると関数を作ることを 先に考えてしまうので、こういう組み換えを実際にやることはまずない。 動作を変えないまま構造を変えてゆくというのは少しずつ慎重にやらないと いけないので、リファクタリングのとっかかりにもなるし面白い。 このあたりでメモ帳ではしんどくなってきたのでサクラエディタに切り替えることにする。 インデントをあとから変えるのがメモ帳の場合は面倒だ。
_ 「メモリ」がゲシュタルト崩壊を起こしはじめた。あぶない。
_ 5章は「参照」。くり返しをいじって、くり返しだけでいろいろ頑張ってきたので この効果はでかいだろう。最初に読んだときは「参照」という用語が ピンと来ていなかった。すでに挙げたものを言いかえているだけなのかもしれないが、 「それを実行する」というニュアンスが感じられなかったため。つまり 「参照」というすでにある用語の方にイメージがひっぱられてしまったためだろう。 でもそれはきちんと読めていなかったからで、 冒頭から一貫して示されているレシピの例えであれば非常に分かりやすい。
_ 昨日の話をその後も考えつづけて、自分はいったいどういう視点でこの本に 取り組んでいるのかがよくわからなくなってきた。間違いなくあるのは 「今まで(この30年近くの間に)理解してきたものを振り返りながら取り組んでいる自分」 「若手に対して教育する立場の自分」の2点か。メインは前者で、後者はあまり うまく書けない。実際に教育する立場でいろいろと動いているのは事実だけど、 受け手が悩んだり困っていることを適切に理解しているとは言いがたいので、 ここでそれをうまく書ける気がしない。いろいろと煮えきらない表現が随所にあるのは それが原因だと考えている。
_ たとえば昨日の、「何も変化がなかったからそこを使うことにする」というのも、 現状の自分に照らしあわせて考えてみると、もし若手が自分の書いたものについて、 「使ってないみたいだったから使いました」、あるいは、もっと飛躍して 「これでいいと思ったのでそうしました」といった説明をしてきたら、 おそらくかなり強いレベルの指摘を入れると思う。取り決めのある世界なのだから、 ○○のようだ、○○だと思った、といった理由で動かれたのではたまらない。 あの文章にさしかかったときに反射的にこのような感情が生まれたのは そういった背景があると自分では理解している。したがって、記述自体に違和感があると表明する場合には こういった背景から生まれている意見なのだということをできる限り 明確にしておく必要があるのかなあと自分では考えている。その「背景」や 違和感の「原因」となるものがあまりに個人的なものであったり、理解不足から 来るものであったり、独善的なのであったりすればその指摘自体の有効性も 疑わしいと受け手が判断できると期待できるかなと思う。
_ 一方、そんなことを考えながらなんとなく形づくられた思いは、 幼児向けの本とかでよくある 「保護者の方へ」的なものがあったらいいのかなあというものだ。 ここはこういう狙いで書いているのだ、ここは敢えてそう書いているのだ、 というようなことは実際にそれを取り組んでいる人に対して漏れなく説明する 必要があるわけではないものだと思う。書いたところでその重要性が理解できるわけではないことが 多いし、書くことによって書く側のアリバイを果たせたというような 性質のものでもないだろう。一方で、これを初心者に薦める側の人間として見た場合、 ここは注意を払ってほしいとか、ここは大胆にデフォルメしたのでそのつもりで、 といった説明があると安心するように思う。 (スライド等でSunabaは なぜこうなっているのかという説明は見られるけど、 この本の記述に合わせたものではないので汲みとるのが難しいこともある)
_ でも、それがあったら本当にいいのかな。わからん。こんなことを 気にする人間が私一人かもしれないので、そうならばまったく意味がないだろうし、 そもそもひらしょーさんは一人で取り組むことができるものとして 書いているわけだから、前段落で書いたのは 予想される非初心者からのつっこみをあらかじめ回避するための 資料でしかないのかもしれない。成長した元初心者が読み直すものでもない気がする。 成長した元初心者が新しく生まれてくる初心者に指導する際には大いに参考に なるものだとは思うけど、誰もがそういう境遇になるわけでもないだろう。
_ でも「元初心者が次の初心者に何を伝えるか」というのは無視できない問題のように思う。 自分が取り組んできたものを自分がやった通りにやらせずに 途中経過抜きで薦めるようなことが往々にしてあるものだ。 何かを教育しようというときに 自分を基準に考えてしまうのはなかなか避けがたいことで、 それだけ「自分であること」や 「自分の経験」に対する臨場感は群を抜いているということなんだろう。何かの本で 読んだKnuthのインタビューで、「誰々が別のインタビューで若者に対する教育は こうあるべきだといったことを言っていましたがどう思いますか」(要約)と 聞かれたKnuthが、「でもそう言っている本人はそうやって学んでこなかったでしょ」 と一蹴していた(要約)のを思い出す。Knuthは過去何度も書いてきた通り自分とは 違う世界の人間だと思っているのだが、この点に関してはほんとうに同感だった。
_ ああ、フライングの上、十分でない記述をしてしまいすみませんでした。 身近に取り組んでいる方がいるのがうれしくてつい書いてしまいました。
_ 「過程」という点ではやはり「間」や試行錯誤が心配ですが、新山さんは あんまりそれを頓着されていないように感じられてたいしたものだなあ(誉め言葉)だと思いますね。お菓子喰いながらやってるときもあるし... 私もFreeMind動画を上げたときは、ある程度自分がこうしたいということを思い浮かべてから 取り組んでいましたし、また、予期しない問題でtake 3まで行ったので あれで済んだと思いますが、考えながら書きながら喋りながらというのは大変そう。
_ 今日は予定では定時までに2時間くらいは腰を落着けた作業ができるはずだったのだが、 蓋を開けてみたら見事に定時＋２時間は差し迫った作業に費されて終わった。 単に時間を開けただけでは駄目で、それを確保できるのかどうかが大事という超あたりまえの話だ。 もちろん期待通りに進まなくてびっくりしたというわけではない。が、どれほど 自分が差し迫った作業に囲まれているのかという点で見積りを誤るのはこの年頃の エンジニアとしてはまったく誉められたものではない。
_ 平日できないとどうしても間が開いてしまうので30分だけでも取り組むことにする。
_ 5章つづき。参照する側とされる側のどっちを先に書くのか、という話。 参照する側を上に書く、というスタイルを推奨していて、 実にその通りだと思いつつ、自分はそれがうまくできていないという自覚もある。 やりたいことが先にあって、そのために細かく区切ってゆく(トップダウン)が 望ましいのは頭ではその通りだと思うんだが、実際にはそのために必要な部品は これかな...というような先読みが走ってそっちを書き始めてしまうことが多い。 小さい部品の方がテストがしやすいという理由が大きいように思う。
_ 昨日の話で大事なことを書き忘れていた。 実際には望ましくない考えかたであったとしても、「砂場」は怪我することのない 安全な遊び場なので思う存分危ないことをしましょう、という 考えかたもあると思う。
_ そうか、5章の段階ではまだ仮引数はないのか。まだメモリに名前をつける話も 出ていないからな。メモリ経由で情報を引き渡してゆくのはなかなかスリリングだ。 これをしなくてよくなる瞬間が来たときに初心者の人には感動があるのかな、 あってほしいなと思う。
_ 仕事が増える一方だな。押し返してはいるつもりだが。前に進んでいるので 時間が解決するだろう。
_ 6章。うまく動かない手がかりとして「いくら経っても終わらない」を挙げているが、 これは独力で気付くのは難しそう。ループ100回だから、少なくとも 分単位で動きを見ないと分からない。本文にも 「このままずっと置いておくとわかるのだが」という前置きで書かれている。
_ p181「この間違いの本当の原因は何か？」は、その直前で メモリ範囲外をいじろうとしてエラーが出たことに対して「これは直さないといけない。次の課題だ」と書かれているので、その原因について書かれていると思ったが、 実際には参照元と先で同じメモリを使っていた問題について書いていてちょっと戸惑った。
_ ようやく「手加減」の話が。この展開はとても興奮するなあ。 「お手紙」はなんで繰り返しのたびに1にスイッチしなければいけないのか？ という説明はまだない。ダイヤルの比喩だといったん1に回せばまた1に回す操作に 何の意味が？という気がするんだが...もちろんそれを理解させるための説明は 入っている。入っているが、お手紙が届いたら0にしているんだ、 といったような記述を嫌ったようにも思える。それが正しいなら徹底しているなあと 思った。でもまだひらしょーさんの考えかたが把握できていないので、こういうところでも なんでそういう書き方になったのかなあ？と思ってしまう。
_ ウェイトがかかっていたというよりは、60000以降を書換えるたびに画面に更新を かけていたということなのか。
_ 最後に穴を開けてしまうのを避ける方法... ここまでの知識だとくり返し回数を 1回減らす以外に思いつかない。
_ ありがとうございます。 絡んでいるような書き方ばかりで心苦しいです。正直、私の書いていることが どんな意味や意義を持っているか自分でもよくわからないので、取り上げる価値が なければお見捨て下さい。 この前置きは、私の記述に対して 書かれているのは明白だけどそれを書くのは自意識過剰だよね、 みたいな逡巡があってそう書かせたものです。
_ さて、(常体に戻る)私は確かに若手を教育する立場にいて、目の前にあることをうまくやってゆきたい (うまく教えてゆきたい)とは思うけど、 教育・教科書を変えてゆきたいというほどの覚悟は持ちあわせていないので ひらしょーさんの姿勢は眩しい。自分だって教育に対する喜びや憧れを 持ちあわせているつもりなのに、そこまで踏み切れない自分を 見せつけられており非常によい刺激になっている。 自分の至らないところを見せられるのは決して心地よいものではないが、 重要なことだと心から思う。安直な言い方だけど畏怖に近い感情がある。
_ まして、教育のために叩かれる覚悟なんてあるはずもなく、 また、「ダメなことをやればダメと言われる」作りを実現させて そこで自由に遊ばせるなんていう発想はまったくなかった。 そして、「やっていいと書いていないことを平気でやる」ことを避けるためには そう説明すればいいと軽く思っていたので (だから、そう説明していないことに不満を覚えた)、 懐の広さがまったく違うと思った。 自分では脚注はアリバイ作りで云々と言っておきながら、問題の大きさに気付いていないだけだったのかと思い知らされた。
_ 「矢印の向き」については、私は「→」 だと、それの行き着く先はどうなるの？という 不安が先に立ってしまうので、まさにプログミングに毒されているんだなあと 痛感している。→ については、「そういうもんだ」という理解が先に立って 使っている状態。
_ = については、話がまったく別だけど、Erlangでは = はパターンマッチングのために 使われる演算子で、「プログラミングErlang」では たとえばX = 2という文があったときに、Erlangは 「この文を真にするにはどうすればいいんだろう？」と考えている、と説明していた。 Xが未束縛ならXが2になってこの式は真になり、Xがすでに別の(2以外の)値に束縛されているならこの式は真になりようがないのでエラーになる、と。 この説明を読んだときに ああなんてわかりやすいんだろうと感動したのを覚えている。
_ もちろん これが「わかりやすい」と思うには意識していない前提がいくつもあるように思う。 さらに、パターンマッチングならそれでいいけど、X = X + 1 のような BASICやCの構文の説明ができない (Erlangではエラーになるだけ)。 前段落冒頭に書いた通り、Sunabaとは何の脈絡もないことだけどそんなことを思い出した。
_ ともあれ、ひらしょーさんやひらしょーさんの本が叩かれる場合、 ひらしょーさんを超えるほど悩んで工夫して検証して、その上で覚悟までして 取り組んだ結果として叩くという迫力のある叩きかたができるひとがいったいどのくらい いるんだろうと思う。情緒的だったりあんまり深く考えてなさそうな叩き方であっても それが一定量溜まれば使いようもあるかもしれないが、戦いを挑んでいるとまで 書いているひらしょーさんにしてみればフラストレーションが溜まるばかりだろうと想像する。 それでも教育の世界に代謝をもたらしたいというのだから、 それだけの迫力は出てくるよなあと思う。
_ 「Switch」一周した。すぐさま2周目に入った。
_ 今日は7章。長くなってきたら、面倒見るメモリの数が増えてきたら、 こんがらがってきたら、見直して考えなおそうという習慣は素晴らしい。 そういう考えかたで成長してほしいと本当に思う。漠然とコードをいじったり 壊したりするだけでなく、つねに自分の能力の及ぶ範囲で面倒を見てゆくという 習慣は大事だと思う。
_ 私の感じる限りでは、「これ以上進んだら破綻しそう」 「自分では把握しきれなくなるな」という点では経験のある人のほうが よっぽど保守的だと思う。若手のコードを見てると、よくこれを書きつづけられるなあと 逆に感心することがある。もちろんうまくできているわけではないし、あるとき 突然手が止まることになるんだけど。
_ 「メモリに名前をつける」のは、未使用のメモリを割当ててもくれるらしい。 これは便利だ。そして名前つきメモリは部分プログラムの内外で断絶されている。 したがって情報の受渡しに使うことはできない。くり返しの外から中で作った 名前つきメモリも見えない。
_ 8章はキーボード操作らしい。特定のメモリ番号に名前をつける方法と、 部分プログラムの内外で情報を受渡しする方法を早く知りたいところだが仕方ない。 それ以前に寝不足なので今日はこのくらいにしておこう...
_ 今日は0.5回休みにしようと思ったが0.25回に減ってしまった。
_ つづき。 空いた時間を使って少しずつ入力していたので時間がかかってしまったが ようやく入力を終えた。38の練習問題と、 「Frame of Referenceの要点」をそれぞれ作成。前者と後者は 体裁が少し違うので、 前回作ったスクリプトをいじった。要するにハッシュに入れたものを 渡せばいいので、テキストを分析したものをjsonにするというスクリプトと、 jsonとテンプレートをjinja2にかけるスクリプトに分離した。
_ 入力自体に時間はかかったが、作業そのものはスムーズだった。 一字一句変えずにというわけにはいかず、揺れた表記をなおしたり、 「○行目のこれこれは…」といった表現を直さなければいけなかったりした (元よりもコンパクトに組まれているので、示されている通りの行にならなかった)。
_ さてA4サイズで作った資料を両面＋縮小で1枚あたり4ページ印刷して、 さらにそれを切離してA5*4枚とするにはどういう順番で印刷すればいいんだろう？ 自作リフィル用のカレンダー作ったときもえらい試行錯誤を繰返した記憶がある。 1→3→2→4 でいいのかな？ どうも回転とか裏表とかはイメージだけで解決できる気がしない。
_ 入力しながら問題を解きながらという感じで取り組んでみた。 1ヶ月のブランクがある割にはけっこう答えられるもんだ。8割がたは澱みなく 答えることができた。コンパクトに印刷して持ち歩くことができるようになったので、 さらに繰返しやってゆく予定。
_ 今週は暑い。 台風がいなくなってから一気に涼しくなったもんだが、今日は真夏日だったらしい。 またしばらくの間は寒いばかりの日が続くわけなので、思いがけず暑い日を 再び体験できたのは喜ばしいことなのかもしれないが暑いのは不快なので そういう気分にはなれないものだ。
_ ただ夜になったらずいぶん涼しくなった。肌寒いくらいだ。 なんだか米沢にいたころの晩夏を思い出すな。昼と夜で20度近く温度差があったように思う。 そういえば昔は晩夏という時期と、「晩夏」という言葉の響きに ものすごく切ないものを感じていた。理由は分からない。 最近はそういう気持にはならない。米沢の季節感がそうさせたのかもしれない。
_ 「晩夏」も打ち損じの多いVAIO Tシリーズさんにかかれば「馬鹿」になりがちだ。 3回に1回は馬鹿になるのでノスタルジーを感じている場合ではなくなるな
_ 今日は久しぶりに1回休みなので寝た。寝たらだるくなった。 何がしたいのかよくわからない。洗濯物をいっぱい乾かした。 洗濯機が異音を発しておりどうやらベルトが緩んでいるらしい。訪問修理してもらうのが安いのか買い換えるのが安いのか...
_ などと考えながらふと横を見たらジョンがこっちを見ていた。 リビングから出られないように冊を設けているのだが、どうしても隙が出来るので そこを使ってわりと自由に出入りしているらしい。が、当たり前のように 風呂場の様子を見に来られても困るところだ。
_ 「修復家」岩井希久子の自伝...なのだろう。同じようなことを 複数回書いていたりするので雑誌かなにかの記事を集めたものなのかと思った。 出典が書かれていないのでそうではなさそうだけど。
_ 美術にはほとんど関心がないけど修復という作業にはとても興味がある。 もちろん自分でやりたい、できそうという意味ではなく、 すでに作られたものを直して守ってゆくという仕事については、 そういう仕事そのものについても魅かれるし、実際に作業している様子にも 魅かれる。もうなくなったらしいが「Wiiの間」でも「修理、魅せます」が 一番好きだった。壊れ具合は一定ではないので手順も定まっておらず、 場合によっては道具を自作したりして元の姿に戻すという取組みは 見ているだけでも(であれば)楽しい。
_ 表面の汚れをとるのには唾液が適しているとか、 細かくおろした消しゴム、パン屑、あるいは「ふのり」など、 わりと身近なものが道具になっていたり、 医療用メスを使ったりと試行錯誤のあとが感じられる道具だてだと思う。 やはり職人芸なので後継者問題はついてまわるようだ。著者の場合は娘さんが 修復家の仕事を継ぎたいと言っているようで、親子で作業している写真が 何点かあったのも印象に残っている。
_ 間があいてしまった。8章から再開。
_ 考えてみたらこのタイトルすごいな。勇ましさを感じる。 タイトルは著者がつけるものではないらしいが...
_ → については前回書いた通り馴染めないがそういうものとして進めている。 これは適切か適切でないかという問題というわけではなく、 単にどう捉えてきたのか、他の言語でどうだったのかという話に集約されると思う。 ひらしょーさんの言う「プログラミングに毒されている」という状態。 で、メモリ[2] → 2 くらいならいいんだが、 メモリ[2] → メモリ[5] といった表記になると一気に混乱することに気付いた。 メモリ[2]の中身が参照されて、それがメモリ[5]にセットされる、と読んでしまう。 Sunabaでの動きは逆だ。メモリ[2]の中身がメモリ[5]になる、といった 読みかただろうか。この「毒されかた」は、 何がいつ参照されるのかという、プログラムを読む上で大事な要素について 混乱を覚えるということにつながるので、気をつけなければいけない。
_ キーの状態は特定のメモリの中身を見れば分かる。 そのメモリを書換えることは許されていない。実際に試してみると、 「このあたりのメモリは読み取れはするが、セットはできない」と怒られる。 「なぜそうなのかはわかるだろうか」という問いかけに対して、脚注で セットしても意味がないから禁止しておいたという意味の内容が書かれている。 意味がないものを禁止するというのは、「ダメなことをやればダメと言われる」作りに通じるのだろう。
_ さて、この文章の流れだけを読むと、問いかけに対する答えは 「意味がないから禁止している」ということになる。 これは何を伝えたいのだろう。もちろんその思想は妥当だと思うし、 そういう思想を感じてほしいと思うのも自然だと思う。けど、なんでこの タイミングでこの問いかけなんだろう？と思った。
_ 塗る色の話。 まだこの段階では論理演算も条件式もないので計算で望む色を求める方法が 出ている。実際には計算(連立方程式の解)で求めるのは乗除が入るから必ずしも 第一選択肢にはならない気もする。
_ 「00_左キーに反応」が期待通りに動かない。 ドロップする前に左を押しっぱなしにしているのだが白が出てこない。 左を押しながら再起動しても同様に何も出てこない。 条件を逆転 (1 - メモリ[50006]) してやると白く出るし、 無限ループ版では左を押している間だけ白くなるのに。なんか常駐ものが 悪さしているのかな？気になるが先に進むことにする。 (追記: ひらしょーさんのtweet を見ると私の環境だけの問題ではないようだ。)
_ 無限ループは「0 ＜ 1 なかぎり」としている。もちろん「1 なかぎり」でも いいわけだが不等式の方が分かりやすいか。
_ p227脚注で応答速度(キーを押してから反応があるまでの速度)について書かれている。 世の中には応答速度の遅いプログラムがたくさんある、のはいいとして、 この段階では、どうしてそんなに遅くなっちゃうのだろう？という疑問が残る。 どう書くとそういうプログラムになっちゃうのか？ と言いかえてもよい。 それを気にしつつ先に進むことにする。 (追記: これもループで時間がかかるとそうなるとはっきり書いているので、 単に読解力がないだけだと思う。どうしてそうなってしまうのか？という点では、 やはり実体験がないので、「気にしつつ先に進む」という結論は変わらないけど)
_ p222の脚注で「今のところ下キーは使っていないが」と書かれている意味が咄嗟に分からなかった。 「あのゲーム」では、という話か。 すぐ後で下キーを使い始めるのでなんのことかと思った。 (追記: 読みなおしてみたところ、 「あのゲーム」で使うキーとして一覧が出ていて、その脚注なので 「あのゲーム」では、という話に決まっている。ひどい読解力だな)
_ 上下左右に動くようになるとやはり楽しい。 ちらつきはなくなったが移動中に色が薄く (灰色に) 見えてしまうのは なんとかならないものかな。残像でそうなっているわけだから移動速度を下げればいいのだと思うんだが、それ以外のことが思いつかない。
_ 「動きっぱなしを避ける」。まだ条件分岐が出てこない。すごい。読みながら いつ出てくるんだろうと思ってしまったが、確かにここは0/1でどうにでもなる話だった。 そして論理演算を使わないのもなるほどなと思った。
_ 変数名に？が使えるのはいいな。なんだかんだで日本語ソースにも慣れてきた。 やっぱり自分で書くとだいぶ違うな。
_ ああ、もう日付が変わってしまった。明日仕事だからこのくらいにしておくか... 8章の途中までしかできなかった。そのときどう思ったのかはそのときに 書いておかないと急速に忘れていってしまうし、 さらに間違って思い出されることの方が多いように思うので、そのときにきちんと 書いておくのが私にとっては重要。したがってこの進みの遅さは仕方がないとして 諦めている。
_ 今日は工事立合いなどで会社にいた。 5年前と同じような状態。 同じ人物なのかどうかは分からんが同じ人物のような気がする。さもないと よほど人材豊富な会社なんだなあということになってしまう。 挨拶もろくにできない人間に対する評価は上げようがない。
_ 本を借りているうちに修得するつもりだったのだがなかなか時間がとれなかった。 ので今日やる。
_ なんか遅いな。PDEなるものの起動も遅いし、 スケッチでコード書いて再生ボタン押してから画面出てくるまでも遅い。 3秒くらいかかる。そしてセミコロン忘れたら 「unexpected token: null」なる不親切極まりないメッセージが出たきりだった。 といったあたりで最初の1分が経過。第一印象はあまりよくない。
_ コード書換えても前に実行していたのを止めないと再実行できないのかな？ パラメータヒントがほしい。 突然出てくるdraw()、setup()というメソッドは何者だ。突然出てくる mouseX、mouseYなる変数は何者だ。などと戸惑うところが多い。 慣れればどうということもないんだろうが...
_ いきなり7章に飛ぶ。シンボリックリンクの判定で getAbsolutePathとgetCanonicalPathの結果を比較しているがこれは Windowsだとうまくいかないことがあるようだ。というのもgetCanonicalPathでは ドライブレターが大文字になるようなので、元のパス指定でドライブレターを 小文字にしていると一致しないため全部シンボリックリンクとして認識されてしまう。 もちろん最初からドライブレターを大文字にしていれば問題ないが。 シンボリックリンクかどうかを一発で判別できるメソッドってなかったっけ。
_ ...うーんこの本けっこう不親切だな。説明をよく読まないとどこのコード いじってるのかすぐに見失ってしまうし、そもそも追加するべきコードを 示していないこともある。
_ PDEにはデバッガがないのか？止めかたが分からん。
_ コンパイラもあんまり親切ではない気がする。 {} の数が合ってないと 怒られたんだが目視で見ても問題ないように見えるんだけどなあ。 リアルタイムに文法エラーを指摘してくれるシステムに慣れすぎたせいかもしれない。 あとこういうのを見るとPythonのようなスタイルがいいなあと思えてくる。
_ ..ああ、他のタブで閉じ忘れていた。そんな気がしていた。 なぜならおかしいと主張しているタブはいじった記憶がなかったので。
_ といったところで時間切れ。なんだかこの環境で大きなものを作る気になれないな。
_ 疲労のため0.5回休み...のつもりだったが0.25回になった。なんか先日も 同じようなことがあったばかりの気がする。
_ 集中力が保てず1回休み。過去の記述にいくつか追記した。
_ 参照を名詞で使っていないということはないと思います。 「くり返し」と「参照」という働きのくくりかたをしているので(カギカッコつきの表記も存在する...たとえば5章の最初とか)、 「参照」を機能のように捉えてしまうのは、 すでに「関数」のイメージを持っているせいだとまでは言えないのではないかなと思います。
_ この方のレビューはだいぶ私の印象や考えに近い気がする。 というより、私がひとつひとつつまずいているところを綺麗に整理の上 評価されているので彼我の差を感じざるを得ない。 なお、私自身は「参照」に関する逡巡はすでに十二分に述べたつもりであり、 かつひらしょーさんの考えかたも教えてもらってよく理解したので、 現在はすんなりと受け入れている。
_ 一方、私はこの人ほど 「初心者がいきなりなんでもできるプログラム言語を修得しようとすることの 危うさ」を想像できていなかった。たしかに、テキストエディタで開いた目の前の ファイル以外に見るべき場所がないというのは大きいことなのかもしれないな。 「知らないうちに動かなくなっていた」というときに、何をすれば まっさらに戻せるのか？という問いに答えるのは難しい環境も多い。
_ 巨大な台風が来るとかで、しかも関東は朝方に一番ひどいことになるということで 警戒していた。5時くらいの段階ではとくに風が強くなることもなく、 なんだどうってことないじゃないかと思っていたら1時間ほどして暴風になった。 電車もいろいろ運休になって、会社に近付けそうにないので家で様子見した後、 結果として会社に行くのはかなり無理しないと駄目そうだと判断して1回休みにした。
_ 1回休みなので疲労回復でも計るか...と思い2時間ほど昼寝してみた。 寝れば寝るほどだるいな。天気はすっかりよくなって、ちょっと風が強いかなという 程度になったが運動する気にもなれずにずっと横になっていた。
_ 8章つづき。 今ある道具でできることを考える、今ある道具に何が加わったらよいのか考えるという 習慣は大事だな。いろいろ知ってしまってからそれを考えるのは難しい。 たまに勝手の全く違う言語に取り組んでみたくなったり、 アセンブラやりたくなったりするのもそういう感覚を取り戻したいという気持が あるように思う。やったことはないけどCode Golfとかもそうなのかなあ
_ 9章に入った。ゆっくり動かす。ついに条件実行が出てきた。が、正直なところ、 前の章で取り組んできたことを考えるとこの段階で条件実行？という感もある。 条件実行が欲しくなるのは、実行中にスピードを変えたいとか、そういう欲求が 出てきたときのような気がする。
_ それはともあれ、条件実行は繰返しとフラグさえあれば代替可能であり、 つまりここまでの知識で条件実行は実現可能だったわけだ。
_ p267 繰返しの回数が本当に10回になっているか？という話は実はタイムリーで、 コードレビューしているときに実は期待した回数より1回少ない状態で ループしていたというのが昨日発見されたばかりだ。
_ 「計算の本当の意味」。ここにきて式の値と評価の方法が出てくる。 「1 なかぎり」でもよいと言えるのは これを理解できてからであり(でもここに至るまでにそれに近い記述はあったように 記憶しているが)(追記: わかりづらい上に勘違いだったためこのカッコの中身は 撤回します。すみません。詳しくは翌日の 記述を御覧下さい)、ここを理解することで複雑な 条件を自由に書けるようになるわけか。 and/orも掛け算/足し算で実現できてしまうので、 この書きかた/考えかたはとてもパワフルだ。
_ 「用心深いプログラム」。ループの終了条件(カウンタの比較)をイコールにするか 不等式にするかという話。私も不等式にするけどassertもつけたいと思う。 イコールでよかったのはカウンタが1刻みでしか増えないという前提があるわけで、 いずれ気がかわって2以上の刻みで増えるようになっても、 不等式なら確かにループは正しく 終わるようになるけど、前提(カウンタが1刻みでしか増えない) が 変わったことによる影響がそれだけなのかということが分からない＝他にも なおさなきゃいけないところがあるにもかかわらず気付かず放置してしまうという 可能性が残る。修正した当初は問題なく動いているように見えて、ずっと後になって おかしくなったとすると、もはや前提があってそれが崩れていたということを 覚えていないということもあったりするので、暗黙の前提はきちんとassertで 明るみに出るようにしたいと思う。
_ 「部分プログラムで整理できないか」。最後に 「これに関してはあきらめてもらう他ない」と書いているが、これは何をあきらめて もらっているのかというのは整理が必要だと思う。 部分プログラムに値を渡すことも、 部分プログラムから値を戻すことも後の章で出ているようなので、 それ自身はあきらめるものではない。ここでは、部分プログラムの外側の 名前つきメモリを部分プログラム側から書換えることができない、ということを あきらめる必要がある、という理解になる。部分プログラムに 名前つきメモリ以外の方法で何かを与えたり、部分プログラムから 何かを貰ったりすることができないという意味ではなさそうだ。 位置を指定した「メモリ」からは離れられないのか？とおののいてしまうが、 そこは工夫次第でなんとかなると思う。
_ コンピュータにおける「計算」とはどういうことなのかというのはこの本の 大事なテーマだと思う。コンピュータに計算させるためにどういうお膳立てが 必要なのかという感覚が掴めていないと、そもそもプログラムを書くというのは どういうことなのかということが分からないように思う。
_ 追われるように打ち合わせや仕事をやっつけて、ああようやくもともと やるつもりだった(今日締切の)仕事を始められる...と思ったときには 20時になっていて驚いた。今月はこんな調子で推移しそうだが 来月は押し返すことができるだろうか。それも今月の頑張り次第だな...
_ は、1回休み。明日は帰ってこれない予定なので週開けまでいじれないかもしれない。
_ 昨日書いた「でもここに至るまでにそれに近い記述はあったように記憶しているが」については あらためて読みなおしてみたところ勘違いだったことが分かった。 まずこれは何を書きたかったのかというと、 ここに至るまでのどこかの脚注か何かで、くり返しの条件は0かそれ以外かで 判別しているというようなものを見た気がしていた、ということを書こうとして生まれた文章だ。
_ そして読みなおしてみたところ、そういう記述は見あたらなかった。 単に勘違いだったようだ。昨日も書いている最中に、本当にそうだったっけ、 読み直してからのほうがいいなと頭の片隅で警告が出ていたのですが、 警告に逆らってそのまま上げてしまいました。 紛らわしい書き方な上に勘違いというのは救いようがない。すみません...
_ ただでさえ疲労困憊するような生活だったのに、 それに加えて肉体労働の疲労まで追加されたのでちょっと深刻に疲れた。 睡眠がきちんととれなかったのも手伝って 今日は家まで帰ってこれないのではないかと心配する疲労具合だった。まあ 帰ってきて飲んで食べてフロ入ったら多少元気になったのであとは しっかり眠れば回復するだろう。
_ なんか会社でこれを1台買ったようなのだが、それを借りて若手社員に ping打ち続けさせるということをやらせてみたところIPアドレスの打ち損じが 多発していろいろ無駄な時間を過ごしてしまったので、打ちづらいのは私側の 問題ではないんだなあということをあらためて思った。
_ と、ここまでで10回くらい打ち損じが発生している。肉体労働で握力が 低下しているのも影響しているのかもしれない。
_ 身体の疲れがとれないので思い切ってユンケル飲んでみた。 よく効くなあ。夕方にはすっかり元気になった。今日は4時間ぶっとおしで 喋りつづけるという苛酷な日だったんだけど、それでも元気になっているので やはりたいしたもんだと思う。
_ モニタのリフレッシュレートが可変になるのかー。言われてみれば 今までなんでそういうのがなかったんだろうと思うような機能だ。 IGZOと相性がよかったりするんだろうか。
_ リフレッシュレートが固定という先入観は昔からPCいじっている人ほど 多いように思う。リフレッシュのタイミングを待って何かをするということが 当たり前のようになされていたし、Vsync割り込みを使ってタイマー的な 処理をするというのも、Vsyncが一定間隔で発生するという前提があるわけで、 それが覆る状況を想像するのが難しいと思う。
_ 疲労回復がおいつかないな。
_ 10章。10ページ進めたところで集中力がなくなってしまったので中断。
_ 「ここから先は、物事が起こる順番に片づけていくのが良さそうだ」という見方の 提示は少し唐突感がある。 ここまでで条件実行も道具として とりいれたので、どこから手をつけてもいいというのが背景にあるのかなと 想像している。 私は「気になるところ」「問題と思うところ」について優先度をつけて 対応してゆくということをしがちなので「唐突感」を覚えた。 優先度をつけるときに、問題の関係を見直してゆくという作業を無意識のうちに 行っているように思う。
_ やりたいことを簡潔な文章であらわす、それはどういうことなのかを考える、 答えやすい問い方が見つかるように問いかけを変形する。 なるほどなーと思うんだけど、自分が何かを作りたいとき、 その実現方法を考えるとき、そういうことをやっているのか？というのがよくわからない。 無意識のうちにやっているのかな。よくわからないが、 確かに私も他人に教えるときに そういう言いかたをすることに気付いた。「まず何をやりたいのか言ってみよ」 「それをするにはどうすればいいのか言ってみよ」というのを、 実現可能になるまで聞き続けるというような。少なくとも教える側の私としては そういう思考方法以外によい方法が思いつかないので、 話の流れもとても自然に見えるんだけど、他の人はどう感じるんだろうかというのが 気になる。
_ これはまったく個人的な経験からの感想でしかないんだけど、前段落のような やりかたがまったくピンと来ていない人もいるようだ。何かを作れと指示すると、 それを作ることだけを考えて手が動かないまま、というようなことがあり、 前段落のように、まず何をやりたいのかをよく考えてみよと言っても 混乱するばかりでまったく先に進めない。問いかけを変えて掘り下げて尋ね 続けることに対して尋問を受けているかのように身構えてまったく 居心地がよさそうには見えない様子を見ると (まあ私の方の指導方法に問題があるのは間違いないとして)、 求める形に近づけるために必要な取組みが見えていない人というのは どうやって導いたもんなのかなあと思ってしまう。 これはプログラムに限らず、資料づくりや料理や工作など、未知なものや 不確定なものが含まれる対象について取り組むときには是非とも必要な 能力だと思うんだが、そうでもないのだろうか？
_ 今回思い描いている人物は、他人に言われてどうこうというのが そもそも苦手なようで、つまり「自分のペース」でないと消化できないようなので、 この本のように考えかたを導いてくれる本を与えて 自分の気の済むようにやらせてみるというのがよいのかなあ、という気もする。 それを許すような内外の状況ではないというのが別の悩みとしてあるが。
_ なんだか取組みの内容でもなんでもないことばかりを書いているようだ。
_ ようやく休み。体の疲れがなかなかとれずに難儀していたので、 ペースを取り戻すチャンスだ。 週の始めから目が離せなかった2つの台風は、身のまわりのことだけを言えば たいしたことがないまま過ぎていった。最大限の警戒をした結果、 今日は家でひきこもることを決定していたが、こんなことなら外出か 出社でもすればよかったと後になって思う。
_ 早く読み終えて次に進みたい気持と、ゆっくり読まないと勿体ない気持が 交錯していて、そこにきてなかなか時間とれないというもどかしさがあって、 つまりあまり進みがよくない。
_ 10章続き。60000以降のメモリの値はとれないようになっている。 BASICには画面に書かれている文字を取得する命令があったように思う。 あれも機種によってあったりなかったりだし、BASIC以外の言語ではまず 見掛けない命令だった気がする。昨今ではVRAMの中身をとるのは とてもコストがかかるのでこの考えかたは自然だろう。
_ 「積もった順に覚えていく」。素直な発想だとこうなるのか。たしかにそうだよな。 私は覚えると言われたときに反射的に「積もっているかどうかを場所ごとに覚える」 というものを思いついた。「積もった順に覚えていく」は、 無意識のうちに却下していたのか、無意識のうちに意識に上がらないように なっていたのか、いずれにしても判定に時間がかかりそうだし無理だろうと思った。
_ こういう思考の流れを細かく見直すのは大事だと思うけど、 一方でとても難しさを感じる。自分なりに思考経路を分解しているつもりで 後付けの理屈を作っているだけなのではないかという感覚が拭えない。 訓練でどうにかなるのか、何らかの方法で「試す」ものなのか。そもそも 試すことができるものなのか...。 でも大事な取り組みだよな。「初心者向け」の本やアドバイスに感じる違和感というのは 結局のところこのあたりを軽視した結果がほとんどだと、自戒も込めてそう思う。
_ 取り組む前に複数のやりかたを思いついて、それを比較するべきというのは その通りだなあと思う。積もりかた、くらいであれば前段落のように 思いつく前に選別が終わっていると言いきれそうに思うが、先日も 覆面算をErlangで解こうとして、最初に思いついたやりかたでは答えが出るまでに 分単位で時間がかかったが、やりなおしてみたら1秒未満で終わるようになった というような経験をした。
_ 複数思いついた方法のうちどちらを使うべきか？消費するメモリの数と 実行する行数(計算の数)で判断している。これは適切な判断だと思う。
_ 「大抵の場合、『面倒くさい』は間違っていることを表すサインである」は、 本当にその通りだと思う。 ひらしょーさんが以前書いていた プログラマにとって「面倒くさい」ほど信頼できる感覚もないに 通じる(11章にも同じ表現がある)が、 面倒と思わないのか、このまま行ったら破綻しそうといった 感覚に乏しい初心者は多い。
_ 勢いでひらしょーさんの5月の記録を読みなおしたところ、 ifの登場時期に関する逡巡が見られた。 苦心の跡が無意識のうちに感じられたのか、当時の記録をおぼろげながら覚えていたのかよくわからないが。
_ 「積もるし壁に当たる」までできた。右を押しっぱなしにしたときと、 左に押しっぱなしにしたときの積もりかたが違う。左の方が1つ多い。 なんでかな... ああ最初の位置が真ん中じゃなくて左寄りだからか... だから「真ん中あたりから」という註釈がついていたのか。今更気付く奴。
_ 横から当てられるようになると俄然テトリスっぽくなるな。
_ そのまま11章に入る。コードが長くなってきたので気付いたんだが 字下げが重要な言語だとページをまたいだコードというのは ちょっと気をつかわないといけないんだな。気をつければいいだけの話だけど。
_ 確認するために手間をかける話。これも大事だと思う。 以前書いたように、 何度も確認するために複雑な手順を踏んでいることに疑問を覚えないというような ケースに出会うと、少し手間をかけて確認を楽にするようにしようよ、 と思う。
_ 350ページ手前でようやく「入力」(引数)が使えるようになった。 なんかメトロイドに似た感覚があるな。そこにあるのは分かっているのに、 手に入るまではあるもので頑張るしかない、というあたりが。 ともあれ、これでメモリの何番がこういう役割で...ということを気にせずに 書けるようになるので、気をつかう部分がだいぶ減る。 3番4番5番ともさよならだ。どんどん削ってゆけるのは感動ですらある。 積もった場所を覚えとく部分もどうにかしたい...けど、まだ戻り値を入手していないので我慢だ。
_ 11章おわった。ここからゲームができあがるまでがちょうど100ページらしい。 だいぶゲームっぽくなってきたとはいえ、まだブロックは1コだけだし、 もちろん回転もしていない。
_ そうそう、「1 なかぎり」について、 「1 なかぎり」 の初出は (「お手本」を除くと) 116ページであることを いっしきさんに教えていただいた。 くり返しの条件に関する説明ではなく、空白の要否に関する説明の部分なので 説明が前後しているわけではないので、私が勘違いしていたことには 違いないのだが、「1 なかぎり」って何だ？というタイミングで登場している というのは言えるのかもしれない。そうでもないのかもしれない。
_ いっしきさんの作例で遊ぶ。 パックマンは苦手なゲームのひとつだが(そもそも得意なゲームがないが) なんとかクリアした。
_ 久しぶりに天気がよかったので洗濯したり散歩したりで過ごした。
_
Wineで動かす試み。以前試したときはうまくいかなかったが、
うまくいかない理由が思いつかないので粘ってみた。
いろいろ試みた結果動くようになった。証拠画像:
_ どうもmonoだとうまくないらしい。C++/CLIだとだめなのか？ メッセージを見る限りではそんな感じがするがよくわからない。 .NET Frameworkはセットアップでこける。 どうも1.4系だとだめらしいので、1.7.4まで上げてみた。 現時点で把握しているポイント:
_ Sunabaは131006バージョン。OSはUbuntu 13.10。 いちばん大きく拡大しても60fps出るし、DnDもきちんと反応する。便利。 本を読みながら学習する間は今までの環境でとくに問題ないが、いろいろ いじったり試したりするには普段使ってるUbuntuの環境の方がなにかとやりやすいので Wineで動くようになったのはとてもうれしい。
_ 12章に入った。今日はp394まで。
_ Sunabaにはelse-ifがない。脚注には「わざと」と書いてあるが、なぜそうしたのかは 書いていない。本書の中ではないが、どこかで「その方がむしろミスが少なくなった」といったような意味の記述があったように思う。 if-elseにあたる処理をするためには、逆の条件のifを準備した上でネストさせる必要があるので、 むしろ複雑になる気がして、あんまり実感がないな。 初心者が何を複雑に思うのかという差が出ているのだろうか。
_ p389の脚注「しかし今はピンと来ないだろう。いずれひどい目にあって学べば良い」は、 今まで私が書いてきたりひらしょーさんに教えてもらったりしたところの発想が 凝縮されているように思う。さらりと書いているがこの覚悟は尋常じゃない。 自分にできるのは、 目の前の初心者がひどい目に合っている状況を適切にフォローできるように 身構えることくらいだ。
_ アップグレードした。特に困ったことはないな...と思っていたが1日も 触っているといろいろ違和感が。
_ じゃあ以前作ったsynclientもどきで センサの状態を見てみようかと思ったらshmgetに失敗しているというメッセージが。 じゃあオリジナルのsynclientで...と思ったらモニタモード的なものがなくなっている。 synaptics(4)を見ると、SHMConfigオプションがRemovedのところに入っている。 このあたりはいろいろ変わってしまったらしい。
_ さらにsyndaemonなる見慣れないデーモンが動いている。 マニュアルを見るとキー操作中にタップ動作などが起こらないように するものらしい。そういえばタップの反応が心なしか悪くなったような 気がしていたが、今のオプションだとキー操作から1秒間はタップに反応しないように なっているようなのでそのせいなのかもしれない。
_ 変わった結果より快適になっているというよりは、 変わったせいで戸惑いが多いので悩ましい。