最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti

これは一人Computer Scienceアドベントカレンダー 15日目の記事です。 Computer Science何も関係ないけど大丈夫か？(まぁ一応Haskellはテーマの1つであったというアレはあるけど) 今回はHaskellで開発を始める時にいつもやってるセットアップの作業とかの説明をします。 どうも、Haskellerによるstackみたいな周辺ツールの情報の発信が足りてないんじゃないかみたいな噂が流れてきたのでじゃあまぁなんか記事にするかという流れです。 ところでstackの説明はググれば日本語の記事がそれなりにヒットするようになったと思うのでここではあんまり説明しません。 開発環境構築 このセクションは初回のみです。 Haskellのインストール stackはプロジェクトを管理するツールっていうのかな？まぁビルドツールになったりパッケージマネージャーになったりghcを管理す

DI DIの重要性はここ数年で急速に高まってきている。 依存性が注入されたりとかそういうことはどうでもよくて、設計と実装を分けたい、人類はそれだけのために色々と工夫をこらし最終的にたどり着いたのがDIであったのだろう。 Haskellでも設計と実装を分けるためにDIしたいというのは自然な流れである。 ここでは型も含めて設計が実装に依存してはいけないということを要求する。 例えば設計でMySqlConnection、みたいな型が出現することも分離できていないので禁止とする。 問題点 設計を定義するときには他の言語ではインターフェイスなどの仕組みが使われることが多い。 Haskellには型システムという仕組みがあるのでこれがインターフェイス相当の機能として紹介される場合がある。 しかし型システムはインターフェイスとは違い、型を固定する仕組みがない。型クラス TypeClass a のインスタン