パイプライン指向JSON処理プログラミング言語 jq - 檜山正幸のキマイラ飼育記 (はてなBlog)
jq（https://stedolan.github.io/jq/）の紹介では、「JSON処理のワンライナー〈一行野郎〉としてめちゃくちゃ便利！」とアピールするのが定番です。もちろんそれは本当で、「めちゃくちゃ便利！」です。が、実は jq は、ワンライナー記述にとどまらない、かなり本格的なプログラミング言語です。 JSON処理のためのDSL〈Domain Specific Language | 領域特化言語〉なので、汎用言語ではありません。しかし、汎用言語が備えている言語機能の一部（関数定義、モジュールシステムなど）を jq も持っています。また jq は、独特で楽しいプログラミング・パラダイム -- “パイプライン指向”に基づいて設計されています。 この記事では、ワンライナーを超えた jq の使い方と、プログラミング言語としての jq の特徴を紹介します。長い記事になってしまったので、一
入門的ではない型クラスの話：Haskellの型クラスがぁ (´^｀;) - 檜山正幸のキマイラ飼育記 (はてなBlog)
タイトルに「入門的ではない」と入れたのは； 先日の「関数型プログラミングとオブジェクト指向について、何か書く、かも」において、「型クラス入門」の記事を書くかもと予告じみたことを言ってしまったので、その入門じゃないぞ、と。でも、型クラスの話だぞ、と。そういう意味合いです。ヨロシク、アシカラズ。 型クラスの元祖はHaskellです。なので、「型クラス ＝ Haskellの型クラス」という前提での解説が多いみたいです。しかし、元祖は“最初の試み”であるがゆえに、使用経験や後発の理論を活かすことが出来ず、むしろ問題をかかえていたりします。Haskellの型クラスも、なんだか残念なところが。 内容： オーバーロードと人生 型クラスは何がうれしいのか（オーバーロードなしでも） 型クラスの実際 記号の乱用の実装法 Haskellの型クラスは何がマズイのか オーバーロードと人生 型クラス誕生の動機は、演算
フローチャートを復権させよう -- 2020年代のプログラミングへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「悟りやヒラメキがほんとに大キライだ 」という記事を書いた背景には、ユースケースの「主／副シナリオ」、「<<extend>>, <<include>>」とかの概念にウンザリしたことがあります。あれから後も、この件がどうも気にかかっていて、『ユースケースの適用：実践ガイド』（asin:4894711869）という本を恵比寿の有隣堂で見つけてすぐ購入しました。 この本には、僕が疑問に思っていた点が説明してあって、理解に役立ちました。ある程度は理解できた事と、その内容に賛同するかどうかは別問題でして、（理解してもなお）納得のいかない点は多々あります。その話は、まーいずれするかも。 ところで、この『ユースケースの適用：実践ガイド』の第5章「ユースケースを図で表現する」の冒頭に次のような文があります。 これまで、長い時間をかけてユースケースのテキストを書いてきました。しかし、ことわざにもあるとおり、
型チェックと型推論 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「ソフトウェアの意味論は何のため／誰のために必要か」において、意味論（モデル）は精神衛生上の理由で必要だ、みたいなことを書きました。そればっかり強調すると、また変に誤解されかねないので、技術的／実用的な観点からの意味論の必要性についても敷衍＜ふえん＞しておきます。 意味論と対＜つい＞になる言葉は構文論です。構文の議論をちゃんとやろうとすると、意味論が必要です。以下、Catyについて話しますが、Catyでは型システムの役割が大きいので、型システムの構文論／意味論を話題とします。 内容： 型チェックがなぜ必要か 型推論と静的な型チェック 型宣言を書く動機付け 型推論演繹系と意味論 実行時チェックを併用するわけ 型チェックがなぜ必要か Catyでは、到るところで型チェックを行います。「どうして型チェックをするのか」というと、まず第一の理由は、人間の間違い（ミス）とそれに起因するトラブルを少なくす
いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ - 檜山正幸のキマイラ飼育記 (はてなBlog)
オブジェクトとクラスの関係について、次のような説明を見かけました（文言の引用ではなくて、檜山による要約）。 オブジェクトとクラスは全体としてツリー構造をしていて、ツリーの末端をオブジェクト、末端以外のノードをクラスという。末端であるオブジェクトは、その親ノードであるクラスのインスタンスと呼び、クラスどおしの親子関係を継承関係と呼ぶ。 うーむ、この説明、ある意味「簡潔でわかりやすい」とも言えるのだけど、ちょっと単純化し過ぎでしょ。 オブジェクトやクラスの概念て、そんなに美しくもなきゃ、整合的でもありません。実用性やら実装上の都合やらでゴチャゴチャですがね。しかし、そのゴチャゴチャが悪いともいえません。ゴチャゴチャを無理に単純化することなく、必然性を持った（幾分は偶発的だけど(苦笑)）複雑さとして理解すべきかと思います。 というわけで、メタクラスやレイフィケーション（reification）な
シネマコンプレックス「新宿バルト9」の驚嘆すべき大バカ最低システム - 檜山正幸のキマイラ飼育記 (はてなBlog)
驚いた。あきれた。なにがどうなったらこんなバカげたシステムができるのだろう？ 補足解説編もあります。 さらなる補足。 コメントをしたい方は、なるべくコレにも目を通してみてください。 連休・子連れで映画館へ 連休、安直に「映画でも」と、子供二人を連れて「新宿バルト9」にはじめて行きました。9つの映画館を集約した施設、なかなかリッパです。上映開始10分前に着いたのに、既に長蛇の列、結局25分も並ばされた。すごく混んでいた？ いやっ、さほどではなかったんですよ。長蛇の列の原因は、発券カウンターの処理能力が異常に低いためでした。 上映開始15分後に入れた -- ってことは 9つの映画館すべてのチケットを一箇所の総合カウンターで発売します。全席指定、完全入れ替え制です。僕らは結局、到着25分後／上映開始15分後に入れました。ここで少し考えれば、次のことがわかりますよね。 満席になればその回は入場でき
福井市の小学生が驚くべき発見 - 檜山正幸のキマイラ飼育記 (はてなBlog)
たまたま目にした論文に面白いことが書いてありました。 随分と昔（1976年）のことらしいのですが、福井県福井市中藤＜なかふじ＞小学校の先生が、「図形の周囲の長さから面積は求められないし、面積から周囲の長さも求められない」ことを子供達に納得してもらうために、次のような宿題を出したんだそうです。 次の図の「S」と書かれた四角は正方形のタイルです。このタイルの一辺の長さを単位として測ることにして； 図形(a)の周囲の長さは16、面積は16です。たまたま長さも面積も16でしたが、これで法則性があると早とちりしてはいけません。(b)から(e)までの周囲の長さと面積も求めてみなさい。 驚くべきことに、先生の意図に反して、とある子供が“周囲の長さと面積の関係”を発見してしまったというのです。 この子の発見は、その前年（1975年）出版の論文集（University of Tokyo Press）に公表さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
