☰

Scala 2.8 コレクション ライブラリは「史上最長の遺書」のケースでしょうか? [終了] 質問する

tag-icon • tag-icon scala scala-2.8 scala-collections
Scala 2.8 コレクション ライブラリは「史上最長の遺書」のケースでしょうか? [終了] 質問する

私はちょうど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 (または /C/C++/C#) になる可能性は低いと思います。開発者がその市場を狙っていたとは思いません。しかし、Scala が次の Ruby や Python になることは確かに可能だと思います (つまり、かなりの商用ユーザーベースを獲得する)。

  • これにより、人々は Scala に来るのを躊躇することになるでしょうか?
  • これはScalaに、熱心な博士課程の学生だけが理解できる学術的なおもちゃとして商業界で悪評を与えることになるのでしょうか？最高技術責任者開発者やソフトウェア責任者は怖気付いてしまうのでしょうか?
  • 図書館の再設計は賢明なアイデアでしたか?
  • Scala を商用で使用している場合、この点について心配していますか? 2.8 をすぐに導入する予定ですか、それともどうなるか様子を見る予定ですか?

スティーブ・イェッゲ かつてスカラを攻撃した（私の意見では間違っていますが）彼はその型システムが複雑すぎると見なしていました。誰かがそれを広めて大騒ぎするのではないかと心配しています。不安このAPIで（ジョシュ・ブロックがJCPJava にクロージャを追加することをやめました。

注-私は、ジョシュア・ブロックBGGA 閉鎖提案の拒否に影響を与えた人物ですが、この提案は間違いであるという彼の正直な信念以外に、このことの理由があるとは思いません。

妻や同僚が何を言おうと、私は自分がバカだとは思っていません。私は大学で数学の学位を取得しています。オックスフォード大学私は商業的にプログラミングを12年近くやっており、スカラ約1年間（商業的にも）。

炎上する主題のタイトルは英国政党のマニフェストに関する引用1980 年代初頭。この質問は主観的ですが、純粋な質問です。私はこれを CW にして、この件について意見を聞きたいです。

ベストアンサー1

これが「遺書」でないことを願いますが、あなたの言いたいことはわかります。あなたは、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!)

常に最適な型が取得されることがわかりますか? s をsIntにマップすると、再び が取得されますが、 s を s にマップすると、一般的な が取得されます。マップの結果の静的型と実行時表現は、渡される関数の結果型によって異なります。また、セットが空であっても機能するため、関数は適用されません。私の知る限り、同等の機能を備えたコレクション フレームワークは他にありません。ただし、ユーザーの観点からは、これが動作の想定方法です。IntBitSetIntStringSet

問題は、これを実現する巧妙な技術のすべてが型シグネチャに漏れ出し、それが大きく恐ろしいものになってしまうことです。しかし、ユーザーには の完全な型シグネチャがデフォルトで表示されるべきではないのではないでしょうか。 で を検索した場合、次のようになるmapとしたらどうでしょうか。mapBitSet

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

その場合、ドキュメントは嘘をついていません。ユーザーの観点から見ると、 map は確かに型 を持っているからです(Int => Int) => BitSet。しかし、map別のリンクをクリックして調べることができる、より一般的な型もあります。

私たちのツールにはまだこのような機能を実装していません。しかし、人々を怖がらせないようにし、より有用な情報を提供するためには、これを実行する必要があると考えています。このようなツールがあれば、スマートなフレームワークやライブラリが自殺メモにならないことを願っています。

おすすめ記事