TypeScriptには期待してたんだけど、ガッカリだよ。 それでもまー、割と好きだけど。 *1 [追記]各所でご指摘いただきました（ありがとうございます）ように、コンパイル・オプション付きなら、シングルトン型のセマンティクスになります。この記事はほぼ言いがかりでした。事実誤認した経緯と、内容的修正を「TypeScript、僕が悪かった、ゴメン： nullやundefinedの扱いはマトモだった」に書きました。 この記事の本文自体はそのままにします。事実誤認も含めて記録が残ってもいいかな、と思うので。ただし、この記事だけを読む人が同じ誤認をしないように、何箇所かに修正記事へのリンクは入れます。[/追記] 内容： 特殊な型や値の扱い方はイイカゲンになりがち 特殊な型とは TypeScriptの基本型にnullは入らないと信じていた どんな伝統なんだよ TypeScriptにシングルトン型はな

2016年9月に次の記事を書きました。 関数型プログラミングとオブジェクト指向について、何か書く、かも タイトルからして引き続く記事を予告しているのですが、その予告を実行することができませんでした。タイトル中の「何か」とは「型クラス」のことです。上記の記事の最後の部分は： 関数型プログラミングにもオブジェクト指向にも関係があって、今後重要度を増すであろう「型クラス」ですが、今述べた（愚痴った）ような事情で（あと、C++のコンセプトは宙ぶらりんだし）、説明の方針も題材も定まりません。でも、いつか、何か書く、かも。 今回この記事で、予備知識をあまり仮定しないで型クラスの説明をします。言いたいことの1/3くらいは書きました。1/3でも長い記事なので、ぼちぼちと読んでもらえれば、と。書き残したことは最後に触れます。いつか、1年はたたないうちに(苦笑)、続きを書くつもりです。 内容： Haskell

「奥野幹也『理論から学ぶデータベース実践入門』はどこがダメなのか」のなかで、ピンクで「（詳細は別途記述予定。）」と書いてあるところが6箇所あります。これらの“ピンクの宿題”を順不同で片付けていきます（全部、片付くかは不明）。 ピンクの宿題 その1 単なるベキ集合でも（ある意味）重ね合わせです。[...今回の話題に関係ないので省略...]この枠組内でNULLの意味も（ヨタ話じゃなくて）分析できます。（詳細は別途記述予定。） NULLに関する基本的な事項についてゼロから考察してみます*1。予備知識として、ラーメン屋さんに行った経験を仮定しますが、その経験がなくても読めるように心がけました。この記事を読めば、NULLの使用法とダメさ加減がハッキリと分かるでしょう。 内容： NULLはダメなの？ なんで？？ 型と型構成子 ベキ集合の型 ラーメン屋さんの食券販売機 繰り返し型と不明型 繰り返し型を禁

言い訳から始めます。この記事を（途中まででも）読んだ人は、次のように言いたくなるでしょう。 『理論から学ぶデータベース実践入門』は良い本なのか悪い本なのか、いったいどっちなんだよ?! この本は間違いや説明不足があり、誤読されやすい表現も多く、その点では残念な本です。しかし、面白いアイディア、するどい観察も含まれていて、行間を補い深読みすれば、多くの示唆を得られる本でもあります。 よって、「良い／悪い」の二択では答えられません。良い点と悪い点の両方を、できるだけ客観的に記述するしかないのです。それをした結果、長い記事となりました。 内容： ことの発端： zhanponさんの批判 奥野本擁護と奥野本批判 僕の擁護・批判の方針 zhanponさんの指摘の再検討 1. 論理的な矛盾とデータの不整合を混同している 2. 命題論理の限界についての説明がおかしい 3. 古典論理の定義を間違えている 4.

先週末に、N君が「イプシロン-デルタ論法って、なんすかアレ？ 全然分からないっす！」と言ってました。そのときはそれ以上話す時間もなかったし、次回会うときはこの話題を忘れてしまうかも知れないので、書き記しておきます。 僕は、伝統的なイプシロン-デルタ論法そのものには懐疑的です*1。ゴタゴタした不等式をいじり回すのは早々に切り上げて、開集合を導入したほうがいいと思います。そんな思いから、出来るだけ不等式を使わずに集合族に注目するスタイルでイプシロン-デルタ論法を紹介します。 内容： イプシロン-デルタ論法 時間や運動のイメージを捨て去る ユークリッド距離と開球体 扱う関数達と実例 平面から平面への写像 一点の周辺を記述する開球体の族 写像による開球体の像 デュエルゲームとしての連続性 論理式で書き下そう 再びイプシロン-デルタ論法 続編： 距離空間と位相空間と連続写像 イプシロン-デルタ論法

確率変数（random variable, stochastic variable）という言葉の意味が分からない！ と何度か書いています。 2015-05-26 「確率変数」と言うのはやめよう 2015-05-27 「分布、測度、密度」は同じか違うか 2015-06-17 まだ「確率変数」が分からない 結局分からないままでした。「慣れ」の問題かも？ と思ったこともあります。 2015-05-28 「慣れれば分かる」問題 慣れることも出来ませんでした。 最近、「これなら納得できるかな」という解釈に出会いました。 [追記 date="翌日"]最後に分かりやすいマトメを付けました。[/追記] 内容： 「確率変数」はなぜ分からないのか アレックス・シンプソンのアイディア 「確率変数」の2つの用法 確率空間と圏Prob 測度論的確率変数 曖昧な確率変数 前層と米田埋め込み 米田埋め込みとしての確率変

割と最近、次の記事がブックマークと注目を集めたようです。 若手プログラマー保存版！フローチャート徹底解説と作成カンニングペーパー 見る前に予想したように、「何言ってんだ!? コイツ」「アホかバカか」的な扱いでしたね。雰囲気としては、「ホメオパシー効いたよ、マジおすすめ」という類の記事への反応と似たようなものです。 ブックマーク： http://b.hatena.ne.jp/entry/it-koala.com/flowchart-2241 上記「フローチャート徹底解説」記事は、特段に酷いとは思いませんが、かといってたいして役立ちそうにないし、反感を買いそうな記述もある*1ので、記事を擁護する気はありません。しかし、フローチャート自体は強く擁護してきたので、ここでまたフローチャート擁護論を展開すべきかな、… と思わなくもないですが、あんまり乗り気じゃない -- 言いたいことは過去にほぼ書き尽

「「関数型プログラミングはオブジェクト指向の正当な後継」なの？」を書いていて次のようなことを思いました： テクノロジーに関する思索を語るのは推奨されるべき事だと思いますが、ベーシックな知識に裏打ちされてないと、解釈困難で意味不明になりがちです。せっかくの経験や思いがうまく伝わらないことになります。 知識は大切だな、とは思っているので、ちょっと気になりそうなトピックに関して、ベーシックな知識の入り口を解説する記事を書いてきました。 モナド 入門 → 世界で一番か二番くらいにやさしい「モナド入門」 （2006年） 圏論 入門 → はじめての圏論 その第1歩：しりとりの圏 （2006年） 継続 入門 → CPS（継続渡し方式）変換をJavaScriptで説明してみるべ、ナーニ、たいしたことねーべよ （2008年） メタクラス・レイフィケーション 入門 → いまさらながらだけど、オブジェクトとクラ

名前や記号の多義的使用をオーバーロードと呼びます。オーバーロードとは「曖昧な表現を使う」ことだ、と言ってもいいでしょう。曖昧さを嫌うコンピュータに、曖昧な表現を理解させるのは難しいことです。コンピュータに関する技術や理論以前に、「我々人間は、曖昧な表現をどう使い／どう解決しているのか？」と問う必要があります。 内容： Haskellの場合 -- The・構造の仮定 要素とコレクションの事例 型クラスの境界線は引けるのか 名前・記号の問題は難しい Haskellの場合 -- The・構造の仮定 「入門的ではない型クラスの話：Haskellの型クラスがぁ (´^｀;)」において： 後知恵で言えば、[注：Haskellのオーバーロード・メカニズムは]「悪いお薬」だったと思います。服用するとモノ凄く元気になるが、長期的には心身を蝕んでしまうお薬だったと。 Haskellが実装した記号の乱用はやはり

タイトルに「入門的ではない」と入れたのは； 先日の「関数型プログラミングとオブジェクト指向について、何か書く、かも」において、「型クラス入門」の記事を書くかもと予告じみたことを言ってしまったので、その入門じゃないぞ、と。でも、型クラスの話だぞ、と。そういう意味合いです。ヨロシク、アシカラズ。 型クラスの元祖はHaskellです。なので、「型クラス ＝ Haskellの型クラス」という前提での解説が多いみたいです。しかし、元祖は“最初の試み”であるがゆえに、使用経験や後発の理論を活かすことが出来ず、むしろ問題をかかえていたりします。Haskellの型クラスも、なんだか残念なところが。 内容： オーバーロードと人生 型クラスは何がうれしいのか（オーバーロードなしでも） 型クラスの実際 記号の乱用の実装法 Haskellの型クラスは何がマズイのか オーバーロードと人生 型クラス誕生の動機は、演算

オブジェクト指向を知っている人々に、「関数型もオブジェクト指向と大差ないよ、大丈夫だよ」とお誘いする記事は大いに存在意義があると思います。 関数型プログラミングはオブジェクト指向の正当な後継である 上記の記事は、そういう目的を持って書かれたのでしょう。その内容（目次）は次のようです（僕のこの記事の目次じゃないよ）。 対象読者 なぜこの記事を書こうと思ったのか？ なぜ関数型プログラミングはわかりにくいのか？ オブジェクト指向の負の遺産を捨てよう 関数型プログラミングの概要 「阿吽の呼吸」とも言うべき使いやすさの拡張 型にまつわる考察 まとめ 最初のほうを読むと、言ってることはまっとうで好感を持てます。が、「5. 関数型プログラミングの概要」の節あたりから雲行きが怪しくなって、ちょっと何言ってるかわかんない（(c)サンドウィッチマン）。 檜山のこの記事の内容： 真面目なポエム モナドっておいし

『シン・ゴジラ』は僕のツボにはまったんですよね。コワ面白かった！ 最近、もうひとつ「これは面白い！」と思っていることがあります。微分幾何の応用の話です。多くの人が「応用」という言葉から連想する内容とはちょっと違います。微分幾何を換骨奪胎して、その枠組を、微分とも幾何ともまったく無関係と思える分野にも適用するのです。 「微分とも幾何ともまったく無関係と思える分野」には、コンピュータ科学や組み合わせ論が含まれます。これには驚きました。好奇心を刺激されて、しばらく猿になって調べまくってました。 調べても理解できないことがたくさんあるので、断片的で中途半端な知識を推測（妄想？）でつなぎ合わせるという手法（いつものやり口）で語ってみます。圏と多様体の定義くらいは仮定しますが、それ以外の知識は要求しないオハナシ調です。 内容： リソース計算が微分計算だってぇぇ?! 微分の計算が出来る圏 組み合せ論とデ

とあるC++コードがコンパイルエラーするんですが、原因がまったく分からなかったんですよ。「そんなバカな?!」という感じ。しばらくハマってしまいましたよ。 結局、C++でもCでも同じことが起きることが分かりました。次は、僕が遭遇したのと同じ現象が起きるC言語のソースコードです。 // -*- coding: sjis -*- // strange.c struct ThreeNums { int x; // 負の数も指定可能 int y; int z; }; int total(struct ThreeNums nums) { return nums.x + nums.y + nums.z; } コンパイルすると： $ type tdm-gcc tdm-gcc is aliased to `/c/Installed/TDM-GCC-64/bin/gcc.exe' $ tdm-gcc --ve

2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん

Rはメタプログラミングの能力を持っていますが、情報がまとまってなくて苦労します。けっこう落とし穴もあります。基本的な事項をここにまとめておきます。 内容： 関数オブジェクトの基本構造 関数オブジェクトのコンストラクタ ペアリストと仮引数リスト 空な名前とデフォルト値なし コールオブジェクトと関数本体 関数の評価環境 関数の登録先環境 コールオブジェクトの操作 引数の式をコールオブジェクトとして取得する その他のメタプログラミング・ツール メタプログラミングのサンプル R言語メタプログラミングの基礎：補足 関数オブジェクトの基本構造 ユーザーが定義した関数をデータとして見ると、3つの部位（スロット、メンバー）を持つ構造体と考えることができます。3つの部位とは、仮引数リスト（formal parameter list）、本体（body）、環境（environment）です。その要点を次の表にま

TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「

2008年に書いた記事「CPS（継続渡し方式）変換をJavaScriptで説明してみるべ、ナーニ、たいしたことねーべよ」はCPSの説明にJavaScriptを使っています。しかし、JavaScriptでは型宣言や型総称（ジェネリックス）が使えないので、「未来のJavaScript」という最初の節で架空のJavaScript方言を定義しました。最近のAltJSのなかには、当時の「架空のJavaScript方言」の機能を実現したものがあります。そのなかでも、TypeScritは強力な型システムを持っています。2015年に現存するJavaScript風言語であるTypeScriptで、関手やモナドがうまく書けるかどうか探ってみます。 内容： 圏論とプログラミング言語 TypeScriptの型の書き方 お題はリストモナド モナドの乗法と単位、全体のまとまり 追記： TypeScriptに関する補足

最近、「おおおー、これは凄い、すんばらしい！」と思ったことがあるので、それについて書きます。 最初に言葉についてのお断り； "categorical"の訳語をどうしようか？ と。片仮名で「カテゴリカル」が無難ですが、漢字で書きたい。「圏論的」が落ち着きがいいようですが、必ずしも「論」の意味を含まないときもあります。そこで、以下、「圏的」を使います。 [追記 date="2013-02-12"]入門的解説を書きました。→「衝撃的なデータベース理論・関手的データモデル 入門」[/追記] スピヴァックと関手的データモデル デイヴィッド・スピヴァック（David I. Spivak, http://math.mit.edu/~dspivak/）は、MITの研究者です。 彼は圏的情報学（categorical informatics）を提唱しています*1。圏的情報学の中心的な概念が関手的データモデル

デイヴィッド・スピヴァックによる衝撃的なデータベース理論である関手的データモデル。どうしたらうまく説明できるか？ と色々と悩んでしまいますが、まー、書けるところから書き始めてしまいましょう。 さー、いらっしゃい、いらっしゃい。関手的データモデルの世界へようこそ。圏論の言葉は出てきますが、圏論の予備知識はほぼゼロでOKですよ。 [追記 date="翌日"]取り急ぎ勢いで書きましたので、不注意と早とちりが混じっていました。追記と取り消し線の形で訂正と注記を足しました。字句レベルの表現の変更は直接編集しています。 あとそれと、圏論の基本用語を知りたいときはコチラ、… って、……、ゴメン！[/追記] 内容： はじめに 本の購入のサンプル スキーマのグラフ表現 キーとか計算カラムとか 圏としてのスキーマ 関手としてのデータベース状態 テーブルの変化 自然変換としてのデータ操作 データベースに圏論が使

jQueryのドル記号「$」は、理不尽なくらいに大活躍します。あまりにも何でもできるので、「ありゃ何なんだ？」と思いますよね。$(...) という形で呼び出せるので、関数なのは確かです。JavaScriptでは、ひとつの関数名に対して呆れるくらいにオーバーロード（多義的定義）ができます。 内容： コンストラクタあるいはクラスとしての関数 メソッドとしての関数 名前空間あるいはモジュールとしての関数 関数／オブジェクトとしての関数 試してみる コンストラクタあるいはクラスとしての関数 関数は、オブジェクトのコンストラクタとして使用できます。 function Point(x_, y_) { this.x = x_ || 0; this.y = y_ || 0; } お尻にアンダースコアが付いた引数名 x_, y_ は省略可能のつもりです。new Point()、new Point(2)、ne