[解決済み】Scala 2.8のコレクション・ライブラリは「歴史上最も長い遺書」のケースか？[クローズド] Scala

質問

を見始めたところです。 Scala コレクションライブラリの再実装 が迫っている。 2.8 をリリースしました。2.7からライブラリーに慣れ親しんだ方は、使い方の観点から、ライブラリーにほとんど変化がないことに気がつくでしょう。例えば...

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

...は、どちらのバージョンでも動作します。 ライブラリは非常に使いやすい 実際、素晴らしいです。しかし、これまでScalaに馴染みのなかった人や 言語の感触をつかむためにあちこちに出没する のようなメソッドシグネチャの意味を理解しなければならなくなりました。

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

このようにシンプルな機能でありながら、この署名は大変なもので、私自身も理解するのに苦労しています。 Scalaが次のJavaになると思っていたわけではありませんが (しかし、Scalaが次のRubyやPythonになる（つまり、重要な商用ユーザベースを獲得する）ことは可能である／可能であった、と私は考えています。）

• これでは、Scalaに来る人がいなくなるのでは？
• Scalaの評判が悪くなる？ 学術的な遊び道具 博士課程の学生しか理解できないのでしょうか？そうです CTO とか、ソフトウェア部門の責任者が怖気づいてしまうのでは？
• ライブラリの再設計は賢明なアイデアだったのか？
• Scalaを商用で使っている人は、このことを心配しているのでしょうか？2.8をすぐに採用する予定ですか、それとも様子を見る予定ですか？

スティーブ・イェッゲ かつてScalaを攻撃した (私の意見では間違っていますが）彼は、その複雑すぎる型システムを見ていました。私は、誰かが次のようなことを言いふらすのではないかと心配しています。 FUD このAPIで（ジョシュ・ブロッホがどのように 日本共産党 は、Javaにクロージャを追加するのをやめました)。

備考 - 私は、次のように考えていることを明確にしておく。 ジョシュア・ブロッホ BGGA閉鎖案の却下に影響を与えたのは、この案が誤りであるという彼の誠実な信念以外の何ものでもありません。

妻や同僚に何を言われようが、私は自分がバカだとは思っていない。私は、筑波大学で数学の優秀な学位を持っています。 オックスフォード大学 そして、商業的なプログラミングを12年近くやってきて、その中で Scala を1年ほど使っています（これも商業的に）。

なお、扇動的な件名のタイトルは 英国政党のマニフェストを引用しています。 1980年代前半 . この質問は主観的なものですが、純粋な質問なので、CWにしましたので、ご意見をお聞かせください。

どのように解決するのですか？

自殺行為でないことを祈りますが、あなたの言いたいことはわかります。Scalaの長所であると同時に問題点でもある、その 拡張性 . このため、ほとんどの主要な機能をライブラリで実装することができます。他の言語では map または collect が組み込まれ、コンパイラがそれらをスムーズに動作させるために通らなければならないすべての輪を誰も見る必要はないのです。Scalaでは、すべてがライブラリの中にあるので、オープンにされています。

実際 map この複雑な型がサポートするのは、かなり高度なものです。これを考えてみましょう。

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

常に最適な型が得られることがおわかりいただけたでしょうか。もし Int を Int を再び取得します。 BitSet しかし、もし Int を String を取得すると、一般的な Set . mapの結果の静的な型と実行時の表現は、どちらもmapに渡された関数の結果型に依存します。そして、これはセットが空でも動作するので、関数は適用されません。私の知る限り、これと同等の機能を持つコレクションフレームワークは他にない。しかし、ユーザーの視点からは、このようになります。 と思われる ということです。

問題は、これを実現するための巧妙な技術がすべて型署名に漏れてしまい、それが大きくなって恐ろしいことになることです。しかし、もしかしたらユーザーはデフォルトで map ? を調べたらどうでしょう？ map で BitSet を得たそうです。

map(f: Int => Int): BitSet     (click here for more general type)

この場合、docsは嘘をつきません。なぜなら、ユーザーの視点から見ると、確かにマップはタイプ (Int => Int) => BitSet . しかし map は、より一般的なタイプも持っており、別のリンクをクリックすることで検査することができます。

このような機能は、まだツールに実装していません。しかし、人々を怖がらせないため、そしてより有益な情報を提供するために、これを行う必要があると私は信じています。このようなツールがあれば、スマートフレームワークやライブラリが遺書にならずに済むと思います。