iBookに「Intro to App Development with Swift」という本があります 日本語版は「Swiftによるアプリケーション開発:入門編」です Appleが自ら書いたSwiftによるiOSアプリ開発の入門書です まったくプログラミングしたことのない中学生あたりがターゲットだと思われます が、ただのプログラミング入門ではありません やってることは簡単だけど教えようとしていることはけっこうまじめ 各章についてる「アプリ開発日誌」っていうコーナーを読むと アプリ開発者の育成に対する本気度を感じます 製品をどうやって売ろうか、と思って考える範囲がそこまで広いことに驚き 日本語版も出たことだし無料ですのですぐ見てみることができます ただし要Mac・要Xcode さらに下の年齢層にはiPadアプリのSwift Playgroundがいいかも こちらも日本語になりました 娘とい

lambdaは手習いのvalueにもありましたが、set!が出てきた関係で 複数の式を書けるようにする必要があります (define *lambda (lambda (e table) (lambda (args) (beglis (body-of e) (multi-extend (formals-of e) (box-all args) table))))) クロージャの作られ方が手習いの時とすこし違うかな？ 手習いの時はこうでした (define *lambda (lambda (e table) (build (quote non-primitive) (cons table (cdr e))))) こちらは単純にテーブル・仮引数・関数本体をリストにして記憶してますね 今回は関数（クロージャ）を作って返し、あとでその関数を評価するようにしています テーブル・仮引数・関数本体はクロー

ふたたびdeepM deepを内部に持つバージョンから始めます (define deepM (let ((Rs (quote ())) (Ns (quote ()))) (letrec ((D (lambda (m) (if (zero? m) (quote pizza) (cons (D (sub1 m)) (quote ())))))) (lambda (n) (let ((exists (find n Ns Rs))) (if (atom? exists) (let ((result (D n))) (set! Rs (cons result Rs)) (set! Ns (cons n Ns)) result) exists)))))) これはメモ化が十分に働かない半バグバージョン これを何度か修正して、以下のような形にします (define deepM (let ((Rs (quo

代入です set!はdefineされた変数に値を代入します と書くと先生に怒られるかもしれません 「名前xはaを参照しています」という言い方はここが初めてかな？ こちらが正しい表現なんでしょう さっきまでaを参照していたxに、今度はbを参照させるというのがset!と いうことになります set!とdefine set!はすでにdefineされた名前についてのみ使用可能です 実際に、定義されてない名前をset!しようとするとエラーになります 逆に、define済みの名前でもう一度defineしようとするのもエラーかと思いきや成功 > (define x (cons (quote chicago) (cons (quote pizza) (quote ())))) > x '(chicago pizza) > (set! x (quote gone)) > x 'gone > (set! y

普通のソースをdefineを使わないソースに変換する手法は 様々なシーンで役立つノウハウですのでまとめておきましょう（嘘 lambdaによる名前付け defineによる定義は、lambdaによる名前付けに書き換えることができます 修正前 (define A (lambda (a) (aaaaa))) (A aaa) 修正後 ((lambda (A) (A aaa)) ;Aの本体 (lambda (a) (aaaaa))) 一律名前付けして使うより、適宜インライン展開して使った方がかえって見やすい場合も あるかもしれませんが今回は全て元のまま名前付けしました 複数の関数 複数の関数を同時に名前付けすることが可能です 適宜グループにして同一の階層で定義し、階層が深くなり過ぎないようにします ただし、互いに呼び出し関係にない場合に限ります 同時に定義すると、相手の関数がスコープにはいらないためで

第9章「……もう一度、もう一度、もう一度、……」は、変な関数の話？ まずは部分関数と全関数から (define looking (lambda (a lat) (keep-looking a (pick 1 lat) lat))) (define keep-looking (lambda (a sorn lat) (cond ((number? sorn) (keep-looking a (pick sorn lat) lat)) (else (eq? a sorn))))) この関数、引数によっては無限ループに入ってしまい、実行が終わりません つまり関数が値を返しません 引数によっては関数が値を返さない関数を部分関数と言います これまで出てきた関数は、リストを扱うものであれば リストのcdr（や場合によってはcar）について再帰を行っていました そのため、再帰のたびにリストの長さが短くな

基本的な再帰の練習は5章までで終わり 第6章「影法師」からは応用編といった感じ 6章では算術式を題材にして表現と抽象化を学びます 算術式をschemeで取り扱うためにS式で表したものを算術式の表現と呼びます まずは単純に、n + 3を(n + 3)と表現します ということは1 + 2 + 3の表現は(1 + 2 + 3)かと思ったらハズレ ここでは「2つの（数を含む）アトムか算術式を+か*か^で結合したもの」を算術式と呼んでます 算術式の定義に算術式が出てきますので再帰的定義ですね こういうのが後から出てくるのがこの本の特徴 1 + 2 + 3は算術式1 + 2と算術式3を+で結合したものか、 または算術式1と算術式2 + 3を+で結合したものとみなせるので その表現は((1 + 2) + 3)か(1 + (2 + 3))のどちらかになります 右から結合とか左から結合とかは決まっていないよ

ちょっと話題になっていたので鎌倉シャツでシャツを買ってみました 初めて洗濯したシャツを見てあっ、と気付きました これは、形態安定シャツじゃない 生地にこだわると形態安定じゃなくなるのでしょう いつも買ってるシャツより高級感があっていい感じ そこについては満足度は高いです 形態安定シャツが出たとき（当時は形状記憶シャツって言ってたかな）は 飛びついて買ったものですが 自分の中で形態安定シャツが当たり前となってしまった今はいちいち 形態安定かどうか確認しなくなってました 油断です 痛い アイロンがけというものが発明された日は呪われていいと思っています 布を伸ばしたり折り目をつけたりするためになぜ貴重な時間を使うのでしょうか 人類の生産性を下げようという宇宙人の陰謀に違いありません 昔は形態安定シャツだったら洗濯して乾いたらそのまま着ていったものですが ヨメがシャツにはアイロンがかかってるべきと

何かいろんなものが頭のなかでつながっている いつかまとまった文章にできるだろうか これくらい 脳 禅 瞑想 マインドフルネス 集中 自分を観察する 内向的 今ここ アドラー ゾーン スイッチが入る 無心 ひらめき・（女の）直感 大局観 答えはすでに出ている 並列処理 map/reduce 機械学習 ディープラーニング 経験 ビッグデータ 言葉を捨てる 直列処理 集中 ていねい ワーキングメモリ 海馬 記憶 チャンク モデル フリーライティング ジャーナリング 0秒思考 GTD 外部脳 Evernote WorkFlowy マインドマップ ネットワーク PoIC KJ法 結びつき 熟成 アウトプット

次は数のリストを扱います 数のリストはタップ(tup)と呼ばれています 扱い方はラットとほとんど同じ タップに含まれる数の合計を返すaddtup (define addtup (lambda (tup) (cond ((null? tup) 0) (else (o+ (car tup) (addtup (cdr tup))))))) ()の代わりに0、consの代わりにo+を使っています (addtup '(3 5 2 8)) (o+ 3 (addtup '(5 2 8))) (o+ 3 (o+ 5 (addtup '(2 8)))) (o+ 3 (o+ 5 (o+ 2 (addtup '(8))))) (o+ 3 (o+ 5 (o+ 2 (o+ 8 (addtup '()))))) (o+ 3 (o+ 5 (o+ 2 (o+ 8 0)))) (o+ 3 (o+ 5 (o+ 2 8)))

第2章「一度、もう一度、さらにもう一度、またもう一度、……」ではラットの再帰を学びます ラット(lat)はこの本だけの用語で、アトムだけが並んだリストのことです List of ATomsのことだと思われます 引数がラットであるかどうかを判定する関数lat?です (define lat? (lambda (l) (cond ((null? l) #t) ((atom? (car l)) (lat? (cdr l))) (else #f)))) この関数に引数として(bacon and eggs)を与えてやったときの動きを1行ずつ じっくりと追いかけていきます こんな感じです 一部略してます (lat? l)の最初の質問は何ですか。 (null? l)です。(略) 次のcond行 ( (null? l) #t) の意味は何ですか。 (null? l)は引数lが食うリストかどうか質問します。(

Scheme手習いの復習を兼ねて、お勉強ログを焼き直しながら書いていきます 第1章「おもちゃ」ではアトム・リストの基礎を覚えます できることなら、読みながら例を試してほしい。 と書いてありますので実際に動かしながら進めましょう 以下のような問いを処理系で確かめるには lのcarは何ですか。引数lは次の通り。 (a b c) lのcarは何ですか。 ここで lは ((a b c) x y z) です。 以下のようにします > (define l '(a b c)) > (car l) a > (define l '((a b c) x y z)) > (car l) (a b c) lを2回defineしてますが、REPL上ではエラーになりませんでした 考えてみると不思議なことです 処理系に依存してるのかもしれません きちんとやるとすると、(この本には出てきませんが)letを使ってこんな風に

モノはこれです NORTH LEAF・メッセンジャーバッグba-546 たまたま行った先のバッグ屋でなにか予感がして見つけたものなんですが 3000円という価格で即決衝動買いしました 逸品というわけでもデザインが素晴らしいというわけでもないんですが 自分の使い方にぴったりしすぎてて手放せません 2013年11月に購入してずっと愛用しています いますぐどうこうという危機に陥っているわけではないんですが ふと検索してみたら通販のページがなくなってました 公式ページはもともとない模様 というわけで誰か情報を知ってたら教えてほしいという話 バッグは機能優先で選びます 大事なのは両手が使えることと入れたものがうまく納まって取り出しやすいこと 底の方にぐしゃっと溜まってしまうのはNG 取り出しにくいし美しくありません 見た目は特に気にしてませんが、シンプルで機能的なら 機能美ってやつが付いてくると思っ

WorkFlowyと言えば階層ですが 実を言うと階層構造はあまり好きではありませんでした 階層構造では項目をどこに入れてよいかわからなくなる、いわゆる「こうもり問題」のせいです たとえば友人という階層と仕事という階層とがあったとして 仕事でつながりのできた友人のことはどちらにいれるのか、という話 書く前にどこに入れていいか悩むと書くのが億劫になってしまいます ちょっとした億劫のためにいつのまにかやめてしまってた、ということを数限りなく経験しています そんな私が、階層が主役であるWorkFlowyを使い続けられているのはちょっと不思議な事ですが いろいろ試しながら現在の階層構造に落ち着いてきた流れを書いてみようと思います 大事なことは以下の２点 タグとうまく組み合わせて使うこと こだわりすぎないこと 始まり 最初は特に何も決めずに書いてましたので適当な階層ができました タスクリストっぽい階層

WorkFlowyをだいたいのアウトライン構成が落ち着いてきたので運用をまとめてみます これに従ってやってます、というよりいつの間にかこんな風になってました、という感じです WorkFlowyにどんなことを書くか はじめは思いつきを書いていただけですが こういうのはたくさん情報が集まっていたほうが価値が高まる気がしますので 徐々に書くことが増えてきました 要するになんでも書いてます 考えごと 日記 タスク・プロジェクト 予定 など 手帳に書いてたようなことも書いてみてます 今のところ手帳も以前通りに使っていますので二重管理っぽくなっていますが 意外とそれも悪くありません アウトラインの構成 現在のアウトラインの構成は以下のようになっています タスク #wip #next #someday #project #wait タスクを探しやすいようにタグを並べています wipは仕掛中のタスクやプロ

「Scheme手習い」というちょっと風変わりなプログラミング本があります Scheme手習い 作者: Daniel P. Friedman,Matthias Felleisen,元吉文男,横山晶一 出版社/メーカー: オーム社 発売日: 2010/10/22 メディア: 単行本（ソフトカバー） 購入: 5人 クリック: 129回 この商品を含むブログ (34件) を見る どんな本？ Structure and Interpretation of Computer Programs(SICP)という本があります かなりメジャーなのでご存じの方も多いでしょう 有用性だけでなく概念の難解さや練習問題のボリュームでも有名です もともとかのMITの教科書として書かれた本ですが MITの学生たちですら手にあまるため後にもっと簡単な教科書に変更されたといういわくつき 一方、その壁を乗り越えた人たちには非

11月も後半になって言うのもなんですが、今年はアウトプットを出す年にしようと思ってました アウトプットというのはつまり何か文章を書くこと ブログ記事を読んでいると、深く考えて書いてるな、すごいな、と思うことがあります ちょっとしたあこがれの気持ちです でもそれは逆で、書いてるから深く考えられるんじゃないか、と思うようになりました で、自分でも書いてみたいと 意識してアウトプットしようとしなくても本を読んだりインプットを増やしていけば いずれはあふれたものが自然とアウトプットされるんじゃないかと期待していたり でもそうはなりませんでした 本当は書くことでなくてもよかったのかもしれません 別に絵が描けたり歌を作ったり試合に勝ったりできるならそれでもいいし でも自分にできそうなことと言えば書くことくらいしかありません と言ってもこれまで何かを書いていたわけではありません 書きたいという気持ちは昔