リビジョン管理システムを使える技術者はイケテいる - 檜山正幸のキマイラ飼育記 (はてなBlog)
ある程度の経験を積んだ技術者／プログラマであるかどうかを判断したいとき、「リビジョン管理システムを普通に使えるかどうか？」という基準はけっこう有効な気がした。 以下の使い方は、「使ってみれば便利さが分かるから」とか言ってなんら説明をしなかった僕の責任です -- と前置きしますが： proj/2009-10-23/, proj/2009-11-10/ なんてディレクトリが、リビジョン管理下になっている。 同じことだが、foo.c, foo-v2.c, foo-v3.c なんてファイルがある。 リポジトリのワーキングコピーとは別に、“ほんと”のワーキングディレクトリがあり、ほんとのワーキングディレクトリから一端リビジョン管理下ワーキングディレクトリにファイルコピーしてからコミットしている。 複数人参加単一プロジェクトのディレクトリ構成が、proj/tanaka/, proj/suzuki/,
型チェックと型推論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「ソフトウェアの意味論は何のため／誰のために必要か」において、意味論（モデル）は精神衛生上の理由で必要だ、みたいなことを書きました。そればっかり強調すると、また変に誤解されかねないので、技術的／実用的な観点からの意味論の必要性についても敷衍＜ふえん＞しておきます。 意味論と対＜つい＞になる言葉は構文論です。構文の議論をちゃんとやろうとすると、意味論が必要です。以下、Catyについて話しますが、Catyでは型システムの役割が大きいので、型システムの構文論／意味論を話題とします。 内容： 型チェックがなぜ必要か 型推論と静的な型チェック 型宣言を書く動機付け 型推論演繹系と意味論 実行時チェックを併用するわけ 型チェックがなぜ必要か Catyでは、到るところで型チェックを行います。「どうして型チェックをするのか」というと、まず第一の理由は、人間の間違い（ミス）とそれに起因するトラブルを少なくす
クラス継承、リスコフの置換原則、部分集合の型 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「クラス、オブジェクト、型； なんだか変じゃない？」に、まだチラホラとコメントが付いているようです。んじゃ、少し補足しておきましょう。 何人かの方が「リスコフの置換原則」に言及しているので、その話。それと、列挙型や部分範囲型についても触れます。「クラス、オブジェクト、型； なんだか変じゃない？」に挙げておいた事例（Point3D extends Point2Dとか）は断りなしに引用します。 継承では、受け継ぐ財産を拒否できない 「クラスはデータと手続きを一緒に定義したものだ」とか言われますね。データはヒープ上のメモリブロックで、手続きはサブルーチンのセットです。クラス継承によって、データも手続きもいやおうなくサブクラスへと押しつけられます。要らないと言ってもダメです。 例えば、bonotake方式で UserHandle extends UserID とした場合、UserHandleでは
はじめての圏論 その第1歩：しりとりの圏 - 檜山正幸のキマイラ飼育記
全体目次： 第1歩：しりとりの圏 （このエントリー） 第2歩：行列の圏 第3歩：極端な圏達 第4歩：部分圏 第5歩：変換キューの圏 第6歩：有限変換キューと半圏 第7歩：アミダの圏 第8歩：順序集合の埋め込み表現 第9歩：基本に戻って、圏論感覚を養うハナシとか 付録／番外など： 中間付録A：絵を描いてみた 番外：同期／非同期の結合 中間付録B：アミダとブレイド 番外：米田の補題に向けてのオシャベリ 一部のプログラミング言語の背景として、圏論（カテゴリー論）が使われたりするせいか、以前に比べれば多少は圏論に興味を持つ人が増えたような気がしなくもないような。でも、安直な入門的文書はあまり見かけないですね。もちろん、シッカリした教科書や論説はあるんですが、どうもシッカリし過ぎているような。例えば、圏の例として「コンパクト・ハウスドルフ空間と連続写像の圏」とか言われてもねぇ（この例はいい例なんです
完全実装付きでもう一度お送りします、しりとりの圏 - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日のセミナーで、圏の簡単な事例として「しりとりの圏」を出したのですが、ハッキリとしたイメージを持てなかった人も多かったようです。 “技術者／プログラマ”であれば、実際に動くコードを持ち出すのが手っ取り早いのかな、と思い、しりとりの圏をJavaScriptで実装してみました。ここでは、このJavaScriptコードにそって、あらためてしりとりの圏を解説します。セミナーの内容や知識をまったく前提にしていません。白紙からの説明です。ただし、以前の記事（2006年8月21日）は参照する必要があります。 以前の記事とJavaScriptソースコードを並べて表示したい人は、次のリンクをクリックしてください。別なウィンドウ／タブで2つの参考エントリーが開くはずです。 はじめての圏論 その第1歩：しりとりの圏 （以前の記事） しりとりの圏 -- JavaScriptによる実装 （JavaScriptソー
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
なんで多重継承はそんなに嫌われるのか？ ちょっくら分析してみるか - 檜山正幸のキマイラ飼育記 (はてなBlog)
多重継承を嫌う人は多いですよね。「複雑だからダメだ」ってことらしい。でも、「複雑＝ダメ」はちょっと乱暴。必然性／必要性がある複雑さなら、それは受け入れざるをえないのですから。それに、どの程度の複雑さなのか、その複雑さはどこから来るのかを知らないと「ダメ」かどうかの判断はできないと思います。 という次第で、多重継承の複雑さを調べてみます。ダメかどうかの判断は僕はしません。圏論の道具を使うのだけど、事前の知識は一切不要です（最後の節を除いて）。最後にまとめて圏論的な解釈をしますが、ここは省略可能。 内容： クラスとその例 多重継承は集約と単純継承の組み合わせ 嫌われる理由 1：名前のバッティング 嫌われる理由 2：ダイアモンド継承 ダイアモンド継承の対処 とりあえずのまとめ 圏論からのアプローチと整理 クラスとその例 多重継承の話をするので、もちろんクラス概念は仮定します。でも、複雑さの話を複
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
檜山正幸のキマイラ飼育記 - 世界で一番か二番くらいにやさしい「モナド入門」
気まぐれと偶然となりゆきで、ここ2,3回はモナドを話題にしました。googleで「モナド」を引いてザッと眺めると、「モナドはむずかしいー」とか「モナドで挫折した」みたいな雰囲気が感じられて、説明芸人の血が少し騒ぎましたね。「なら、予備知識ゼロでモナドの説明をしてやろうじゃねーか」と。 タイトルはだいぶ煽っちゃった…… けど、ハッタリじゃないつもり…… けど、実際はどうかな？ ※印刷のときはサイドバーが消えます。 内容： とりあえず、あたりさわりなくモナドの来歴を紹介する こんな課題を考えてみよう：副作用付き計算 カウントアップする関数達 カウントアップしたい意志を戻り値で伝える それでは、いったい誰がカウントアップをするのだ 関数の引数の型をCountup型にまで拡張する そして、これがモナドだ とりあえず、あたりさわりなくモナドの来歴を紹介する 今からここで説明する「モナド（monad）
絵を描いて学ぶ・プログラマのためのラムダ計算 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「JavaScriptで学ぶ・プログラマのためのラムダ計算」は、1回では述べ切らなくて、一段落付いたところで区切りました。これはかえって良かったですね、ブックマークやトラックバックでフィードバックが得られたので。 そのフィードバックなどをかんがみて、「残り＝次回の話題」として予告した内容とは食い違ってしまうのだけど、今回は、文章では伝わりにくい（前回うまく伝わらなかったと思える）ラムダ計算の大事なツボを、なんとか表現してみようと思います。 ［このエントリーの内容はだいぶ前にほぼ出来上がっていたのだけど、ココに書いてある事情で、“お絵描き”がなかなか出来なかったのです。］ ※印刷のときはサイドバーが消えます。 内容： 知っていて損はない 計算は身体的に理解しよう ラムダ項のツリー表示：準備 ラムダ項のツリー表示：描く！ β変換に対応するツリーの描き換え もっとβ変換をやってみよう 計算現象を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
