JSONスキーマの功罪を、印象や感情じゃなくて考えてみようか - 檜山正幸のキマイラ飼育記 (はてなBlog)
「JSONの可能性がグンと拡がるぞ！ JSONスキーマ」に対して、がくぞーさんからトラックバックをいただきました。その冒頭を引用すると： この記事のブコメを見てみると XML Schema が在るんだし軽さがウリの JSON にそんなの必要なくね？的なコメントが散見されます。 なるほど、「なんだか複雑になりそうでヤダなー」とか「そんなもん要らねーよ」という印象や感情を持たれた方もいるんでしょうね。僕は、JSONスキーマをプロモートする気はないので、「ヤダ」とか「要らねー」の人を説得する動機はないのですが、「印象や感情だけじゃ主張や議論にはなりませんよ」って趣旨でちょっと書いてみます。 内容： 僕の感情と事情 妥当性の検証はたいてい必要 JSONにスキーマはそぐわない？ JSONスキーマの弊害 バリデータ実装の負担 僕の感情と事情 「印象や感情じゃ、ラチあかんよ」と言いましたが、まずは僕の感
Back to XML (2) - 檜山正幸のキマイラ飼育記 (はてなBlog)
過去に蓄積されたXML技術のどのあたりを檜山が面白いと感じ、再評価・再発見してみたいと望んでいるのか？ それは、また次ね。 前回、こんな文面で終わってしまったので、「それはどこ？」の話をせざるを得ないでしょうね。だから実際しますけれども、論理的な順序から言うと、その前に話しておくべきことがあるのだった。まー、いきがかりだから論理的順序は無視します。したがって、解説としては若干不親切で、幾分錯綜した感じになりそう。致し方ない。 話は前世紀まで遡＜さかのぼ＞るのだが 「過去に蓄積されたXML技術」という言葉は、なにか特定単一の仕様を意味してるわけではありません。いまだ脈ありと僕が思っているものがいくつかあるわけです。そのなかで第一の候補を挙げれば、… … XLinkです。 XLinkは、XML 1.0仕様とほぼ同じ時期から構想されているものです。XMLの初期のドラフトでは、XLink仕様がXM
Erlang実験室：武士道と云ふは死ぬ事と見付けたり - 檜山正幸のキマイラ飼育記 (はてなBlog)
Erlangでは、「死ぬこと＝プロセスをクラッシュさせること」の解釈／意義／価値観が、他の言語とは随分違います。潔＜いさぎよ＞く死ぬことが推奨されていますが、これは責務の放棄とは違います。 内容： 事故や災害への対処は個人ではなくて企業や社会が行うべき 正常と異常のはざま 例外を使うのは例外的？ 多プロセス並列プログラミングと例外 潔さと無責任は違う -- 武士道プログラミング ●事故や災害への対処は個人ではなくて企業や社会が行うべき Erlangの書き方や文化で、なかなか馴染めないのが「異常時の処理を書かない」という方針です。 多くのプログラミング言語のコードでは、次のような分岐をしばしば見受けます。 if (正常条件) { 正常時の処理; } else { 異常時の処理; } switch (値) { case 正常な値_1 : 正常時の処理_1; break; case 正常な値_2
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
シェルのリダイレクトを「こわいものなし」というくらい完全に理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Java BlockingQueueで遊ぶ：パイプラインごっこ」でパイプラインの話をしたので、本来の、つまりUnixのパイプやリダイレクトを少し調べてみました。 たまに話題となる some-command >file 2>&1 と some-command 2>&1 >fileの挙動の違いについて、「シェルはコマンドラインリダイレクトの指定を右から左に解釈実行する」なんて説明が見つかりました。んなバカな！ パージングは左から右にするものですよ。パーズツリーを逆順にたどることはできるけど、そんなことする必然性はなんにもないよ。 次の記事を読むと、「右から左」なんて事情じゃないことが分かるでしょう。 UNIXの部屋 検索: リダイレクト シェルのリダイレクトにまつわる失敗 さてここでは、複雑なリダイレクト処理も完全に理解できる処方箋を示しましょう。例えば、次のコマンドラインが何をするか分かる
絵を描いて学ぶ・プログラマのためのラムダ計算 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「JavaScriptで学ぶ・プログラマのためのラムダ計算」は、1回では述べ切らなくて、一段落付いたところで区切りました。これはかえって良かったですね、ブックマークやトラックバックでフィードバックが得られたので。 そのフィードバックなどをかんがみて、「残り＝次回の話題」として予告した内容とは食い違ってしまうのだけど、今回は、文章では伝わりにくい（前回うまく伝わらなかったと思える）ラムダ計算の大事なツボを、なんとか表現してみようと思います。 ［このエントリーの内容はだいぶ前にほぼ出来上がっていたのだけど、ココに書いてある事情で、“お絵描き”がなかなか出来なかったのです。］ ※印刷のときはサイドバーが消えます。 内容： 知っていて損はない 計算は身体的に理解しよう ラムダ項のツリー表示：準備 ラムダ項のツリー表示：描く！ β変換に対応するツリーの描き換え もっとβ変換をやってみよう 計算現象を
DI（依存性注入）を白紙から説明してみる - 檜山正幸のキマイラ飼育記 (はてなBlog)
「DI（依存性注入）からどこへ行こうか その1」において： DI（依存性注入）については、雑誌や書籍で随分紹介されているので、そういうのを見てください。 こんなこと[注：DI化]して何がうれしいかって？ それは、ファウラー先生とかその他エライ人とかエラクない人とかに聞いてください。 と書きましたが、DI（Dependency Injection; 依存性注入）そのものについても説明を試みてみましょう。具体的なサンプルを使うことにします。そのため、サンプルの説明が長くなってしまうのが困ったことですが、まー、単なる能書きよりはサンプルがあったほうがいいでしょ。 内容： サンプルはテンプレート処理系 レクサー（字句処理系） レクサーをインターフェース経由で使う サービス・ロケーター 依存性が消えてない！ DI（依存性注入）登場 DIが、かつてIoC（制御の逆転）と呼ばれていた理由 ●サンプルはテ
檜山正幸のキマイラ飼育記 - 圏論やモナドが、どうして文書処理やXMLと関係するのですか？
…という類＜たぐい＞の質問に答えるのはちょっと面倒なんですけど、とりあえず1つだけ具体例を挙げておきましょう。テンプレート処理が、もろにモナドになっている、ってハナシ。今回はテキスト処理について説明。次回（いつになるかまったく不明）はXML処理の予定。 テキスト処理だけでも長ーい説明（最長記録かも）なのだけど、分割すると“勢い”がなくなるから一挙掲載。読むときはユックリ・ジックリ読んでくださいね。プログラミング課題も、実際にコーディングしないまでも、「こうやればいいな」という方針くらいは考えてください。 ※印刷のときはサイドバーが消えます。 内容： ネストしたテキスト テンプレート処理 ブロック、文字列、名前 フラット・テキストとテンプレート・テキスト 多段階のテンプレート処理 蛇足 素材を整理しよう モナドに向かって突っ走れ！！ バッチリ、モナドだぜぇ 残りは脱兎のごとく 最後に言ってお
檜山正幸のキマイラ飼育記 - 世界で一番か二番くらいにやさしい「モナド入門」
気まぐれと偶然となりゆきで、ここ2,3回はモナドを話題にしました。googleで「モナド」を引いてザッと眺めると、「モナドはむずかしいー」とか「モナドで挫折した」みたいな雰囲気が感じられて、説明芸人の血が少し騒ぎましたね。「なら、予備知識ゼロでモナドの説明をしてやろうじゃねーか」と。 タイトルはだいぶ煽っちゃった…… けど、ハッタリじゃないつもり…… けど、実際はどうかな？ ※印刷のときはサイドバーが消えます。 内容： とりあえず、あたりさわりなくモナドの来歴を紹介する こんな課題を考えてみよう：副作用付き計算 カウントアップする関数達 カウントアップしたい意志を戻り値で伝える それでは、いったい誰がカウントアップをするのだ 関数の引数の型をCountup型にまで拡張する そして、これがモナドだ とりあえず、あたりさわりなくモナドの来歴を紹介する 今からここで説明する「モナド（monad）
はじめての圏論 その第1歩：しりとりの圏 - 檜山正幸のキマイラ飼育記
全体目次： 第1歩：しりとりの圏 （このエントリー） 第2歩：行列の圏 第3歩：極端な圏達 第4歩：部分圏 第5歩：変換キューの圏 第6歩：有限変換キューと半圏 第7歩：アミダの圏 第8歩：順序集合の埋め込み表現 第9歩：基本に戻って、圏論感覚を養うハナシとか 付録／番外など： 中間付録A：絵を描いてみた 番外：同期／非同期の結合 中間付録B：アミダとブレイド 番外：米田の補題に向けてのオシャベリ 一部のプログラミング言語の背景として、圏論（カテゴリー論）が使われたりするせいか、以前に比べれば多少は圏論に興味を持つ人が増えたような気がしなくもないような。でも、安直な入門的文書はあまり見かけないですね。もちろん、シッカリした教科書や論説はあるんですが、どうもシッカリし過ぎているような。例えば、圏の例として「コンパクト・ハウスドルフ空間と連続写像の圏」とか言われてもねぇ（この例はいい例なんです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
