質問: 現実の世界で「強力な」型システムを使用している、たとえば、大規模なwebアプリの場合はどうでしょうか。 これは非常に広範で、あいまいで、おそらく哲学的な質問であることを知っています。ある程度、質問の中で最も重要なキーワード-「強力な」型システム-それ自体は ill-defined です。だから、私が何を意味するのか説明してみましょう。質問の全体的なコンテキストruby on rails)で非常に大規模なwebアプリを構築しており、スタックについては一般的に満足しています。必要に応じて、ものを本当に速く出荷することができます-"ビジネス"ケースの90%で機能し、約10%のエッジケースをあまり心配する必要はありません。一方、コードレビューとテストカバレッジの助けを借りて、ゆっくりと慎重に、すべての拠点をカバーするようにしてください。このような綿密な調査と安全に値する状況でのみです。しかし、チームが成長するにつれて、スタックに組み込まれた「セーフティネット」が欠如していることに不快に感じ始めました。私たちは最近、javaでいくつかのネイティブandroid=開発を開始しました。そして、コンパイルされた/静的/厳密に型指定された言語によって提供される安全性を(喜んで)思い出しました。 スペルが間違っている変数、誤ったデータ型、誤った関数呼び出し、および些細なエラーのホストは、ide自体によって捕捉されます。ideコンパイラに入力し、プログラムの「正確さ」の特定の側面を確認します。 関数のシグネチャを変更する必要がありますか?簡単です。 compiler + ideは、すべての呼び出しサイトを見つけるのに役立ちます。 特定の例外が常に処理されるようにする必要がありますか?あなたの救助の例外を確認しました。 現在、これらの安全機能には長所がありますが、短所もよく知っています。さらに、「定型の重い」javaの世界では。したがって、私はjavaの代わりに、人々が最近取り組んでいる現代の「強く型付けされた」多くの言語を調べ始めました。例:scala、rust、haskellなど。最も興味深いのは、型システムと静的/コンパイル時チェックの能力です。さて、質問より大きなアプリケーションでこれらの強力な型システムと静的/コンパイル時機能を使用するにはどうすればよいですか?たとえば、これらの強力な機能への標準の「hello world」のような導入をどのように進めればよいでしょうか?リッチタイプシステムを使用してビジネスドメインの問題をモデル化するものですか。タイプシステムは、30,000 loc +ゾーンにいるときに役立ちますか、それとも妨げになりますか?システムが弱く型付けされた外部の世界とやり取りすると、これらの型システム(およびコンパイル時チェック)によって提供されるセーフティネットはどうなりますか。 jsonまたはxml api、さまざまなデータストア、ユーザー入力などを介して.
回答: 私が見たこと:私はいくつかの大きなruby webアプリケーション(rails)、1つの大きなhaskell webアプリケーション、およびいくつかの小さなアプリケーションを使用してきました。その経験から、haskellアプリケーションでの作業は多くのことを言わなければなりません。 railsメンテナンスや学習曲線の低下などの点でより簡単です。これらの利点は両方ともhaskellの型システムと関数型プログラミングスタイルによるものだと思います。しかし、多くの場合とは異なり、型コントラクトの「静的」部分は、動的コントラクトを使用するときに得られるメリットがまだあるという点で、非常に便利です。私が信じていることhaskellプロジェクトがより優れたメンテナンス特性を実現するのに役立つと思われる主な機能のいくつかを提供するのに役立つ contracts ruby という素敵なパッケージがあります。コントラクトrubyは実行時にチェックを実行するので、高度なテスト収束と組み合わせると最適ですが、それでも、インライン注釈と型注釈の使用と同じ意図と表現の表現を提供しますhaskellなどの言語。質問の答え上記の質問に答えるために、haskellや他の高度な型システムの言語に慣れることができる場所はたくさんあります。ただし、完全に正直に言うと、これらのドキュメントのソースはそれ自体は優れていますが、ruby、python、java =と他のそのような言語。いずれの場合でも、 real world haskell は古くなっていますが、依然として優れたリソースです。カテゴリー理論haskellを選択すると、カテゴリー理論について論じている大量の文献に出くわします。 imhoカテゴリ理論は有用ですが、必須ではありません。 haskellコミュニティで普及していることを考えると、タイプの賛否両論をカテゴリー理論の実用性についての感情と簡単に融合させることができます。それらが2つの異なるものであることを覚えておくと役立ちます。つまり、カテゴリ理論によって導かれる実装は、静的だけでなく動的に型付けされた言語でも実行できます(型システムが提供する利点を法として)。高度な型システムは一般にカテゴリー理論に拘束されておらず、カテゴリー理論は型システムに拘束されていません。タイプの詳細型を使用したプログラミングとその中のテクニック(楽しいので非常に迅速に行われます)についてさらに学習すると、型システムでより多くのことを表現したくなるでしょう。その場合、私は次のリソースのいくつかを調べて、これらの機能を備えた産業品質のツールが、使いやすいインターフェイス(contracts rubyなど)を公開するものにのみパッケージ化されることを望んでいることをツールベンダーに知らせます。 atsでのプログラミングの概要 smtおよび述語の抽象化によるliquidhaskell絞り込みタイプ イドリスによるタイプ駆動開発