Scala 2.8コレクションライブラリは、「史上最長の自殺ノート」のケースですか？[閉まっている]

差し迫った2.8リリースで提供されるScalaコレクションライブラリの再実装を検討し始めたところです。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を商業の世界で悪名にするのでしょうか？されCTO sおよびソフトウェアの頭はオフ怖がって取得するつもり？
• ライブラリの再設計は賢明なアイデアでしたか？
• Scalaを商業的に使用している場合、これについて心配していますか？すぐに2.8を採用する予定ですか、それとも何が起こるか確認するのを待ちますか？

Steve Yeggeは かつてScalaを攻撃した（私の意見では誤解している）が、過度に複雑な型システムと見なしたものを攻撃した。私は誰かがこのAPIでFUDを広める実地の日を過ごすことを心配しています（Josh Bloch がJavaにクロージャーを追加することからJCPを怖がらせたのと同様に）。

注 - 私は私がいることを信じていながら、ことは明らかであるジョシュア・ブロックが、私は提案が間違いを表現することを彼の正直、信念以外にこれを帰ません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!)

常に最良のタイプを常に得る方法をご覧ください。IntsをIntsにマッピングするとBitSet、再びを取得しますが、IntsをStringsにマッピングすると、一般を取得しますSet。マップの結果の静的な型と実行時の表現の両方は、それに渡される関数の結果の型に依存します。そして、これはセットが空でも機能するので、関数は適用されません！私の知る限り、同等の機能を持つ他のコレクションフレームワークはありません。しかし、ユーザーの観点からは、これが想定されている方法ですの作業に。

私たちが抱えている問題は、これを可能にするすべての巧妙な技術が、大きくて恐ろしい型シグネチャに漏れることです。しかし、たぶん、ユーザーはmap？どのように彼女は見上げた場合についてmapでBitSet彼女ました：

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

ユーザーの観点から見ると、マップは実際にtypeを持っているので、ドキュメントはその場合にはありません(Int => Int) => BitSet。しかしmap、別のリンクをクリックして検査できるより一般的なタイプもあります。

このような機能はまだツールに実装していません。しかし、私はこれを行う必要があると信じています。人々を怖がらせないようにし、より有用な情報を提供するためです。そのようなツールがあれば、うまくいけば、スマートなフレームワークとライブラリが自殺ノートにならないでしょう。

私は博士号を持っておらず、CSや数学、その他の分野の学位も持っていません。私は、Scalaや他の同様の言語を使用した経験がありません。私は、リモートで比較可能なタイプのシステムでさえ、経験がありません。実際に、私もこれだけの表面的な知識よりも多く持っていることを唯一の言語があるタイプのシステムは、正確にその洗練された型システムのために知られていないパスカルは、あります。（それががない私の知る限りほとんどいない他の言語を持っている範囲の種類を、持っているが、それはここでは本当に関係ありません。）私が知っている他の3つの言語でも型システムを持ってどれもBASIC、SmalltalkのやRuby、です。

それでも、map投稿した関数のシグネチャはまったく問題ありません。map私が今まで見た他のすべての言語とほとんど同じ署名のように見えます。違いは、このバージョンの方が一般的なことです。HaskellというよりはC ++ STLのように見えます。特に、それはIterableLike、引数がであることのみを要求することによって具象コレクション型から抽象化し、結果値のコレクションから何かを構築できる暗黙の変換関数が存在することのみを要求することによって具象戻り型から抽象化します。はい、それはかなり複雑ですが、それは実際には一般的なプログラミングの一般的なパラダイムの表現にすぎません。実際に必要のないことを想定しないでください。

この場合、コレクションmapは実際にはリストである必要はなく、順序付けされているか、ソート可能である必要もありません。唯一map気にはそれがコレクションのすべての要素へのアクセス、次々ますが、順不同を得ることができるということです。そして、それは結果のコレクションが何であるかを知る必要はなく、それを構築する方法を知る必要があるだけです。したがって、それがその型シグネチャで必要なものです。

したがって、代わりに

map :: (a → b) → [a] → [b]

これはの従来の型シグネチャでmapあり、具象Listではなく単なるIterableLikeデータ構造を必要とするように一般化されています。

map :: (IterableLike i, IterableLike j) ⇒ (a → b) → i → j

これは、ユーザーが望むデータ構造に結果を変換できる関数が存在することだけを要求することで、さらに一般化されます。

map :: IterableLike i ⇒ (a → b) → i → ([b] → c) → c

構文は少し不格好ですが、セマンティクスは同じです。基本的には、

def map[B](f: (A) ⇒ B): List[B]

これは、の従来の署名ですmap。（Scalaのオブジェクト指向の性質が原因で、入力リストパラメーターが消失することに注意してください。これは、単一ディスパッチOOシステムのすべてのメソッドが持つ暗黙のレシーバーパラメーターであるためです。）次に、具体的なものからListより一般的なものに一般化されました。IterableLike

def map[B](f: (A) ⇒ B): IterableLike[B]

現在は、IterableLike結果のコレクションを、ほとんど何でも生成する関数に置き換えています。

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

これは、私は本当に信じていないこと、ハードを理解します。必要な知的ツールはほんのわずかです。

1. あなたは（大体）何であるかを知る必要mapがあります。メソッドの名前なしで型シグネチャのみを指定した場合、何が起こっているのかを理解するのがはるかに難しくなります。しかし、何をすべきかをすでに知ってmapおり、その型シグネチャがどうあるべきかを知っているので、シグネチャをすばやくスキャンして、「なぜこれmapが1つではなく2つの関数を引数として取るのか」などの異常に焦点を合わせることができます。
2. 型シグネチャを実際に読み取ることができる必要があります。しかし、これまでScalaを見たことがない場合でも、これは非常に簡単です。これは、他の言語ですでに知っている型構文の混合にすぎないためです。VB.NETは、パラメトリック多態性に角かっこを使用し、矢印を使用して名前とタイプを分離するための戻りタイプとコロンは、実際には標準です。
3. ジェネリックプログラミングの概要を知る必要があります。（されていないこと、それは基本的にすべての名前で綴られますので、ハードは、把握する：それは文字通り、一般的なやり方でプログラミングです）。

これらの3つはどれも、プロまたは趣味のプログラマに深刻な頭痛を与えることはありません。map過去50年間に設計されたほとんどすべての言語の標準機能でしたが、HTMLとCSSを使用してWebサイトを設計した人なら、言語によって構文が異なるということは明らかであり、リモートでプログラミングすることもできません。セントステパノフ教会の迷惑なC ++ファンがいない一般的なプログラミングの利点を説明する関連メーリングリスト。

はい、Scala は複雑です。はい、Scalaには、Haskell、Miranda、Clean、Cycloneなどの言語に匹敵する、さらには優れた言語として知られている最も洗練された型システムの1つがあります。しかし、複雑さがプログラミング言語の成功に対する反論であるとすれば、C ++はずっと前に亡くなっており、私たち全員がSchemeを書いているでしょう。Scalaが成功しない可能性が非常に高い理由はたくさんありますが、プログラマーがキーボードの前に座る前に頭をオンにするのに煩わされることができないという事実は、おそらく主なものではないでしょう。

C ++でも同じこと：

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.push_back(func(*it));
    }
    return res;
}

まあ、私はあなたの痛みを理解することができますが、率直に言って、あなたや私などの人々、またはほとんどすべての通常のスタックオーバーフローユーザーは、ルールではありません。

私はそれで意味しているため、ほとんどのプログラマは、その型シグネチャを気にしないだろうということです... 彼らはそれらを見ることは決してないだろう！彼らはドキュメンテーションを読みません。

彼らがコードがどのように機能するかのいくつかの例を見て、コードが彼らが期待する結果を生成することで彼らを失敗させない限り、彼らはドキュメントを決して見ないでしょう。それが失敗した場合、彼らはドキュメントを見て、上部に使用例が表示されることを期待します。

これらを念頭に置いて、私は次のように考えます。

1. そのタイプシグネチャに出くわす人（ほとんどの人と同様）は、Scalaが前もって処理されていれば、Scalaを限りなく模倣し、Scalaが好きな場合はScalaのパワーのシンボルと見なします。

2. 使用例を提供し、メソッドの目的と使用方法を明確に説明するようにドキュメントが拡張されていない場合、Scalaの採用が多少損なわれる可能性があります。

3. 長い目で見ると、それは重要ではありません。Scala がそのようなことを実行できることにより、Scala用に作成されたライブラリーがより強力で安全に使用できるようになります。これらのライブラリとフレームワークは、強力なツールに惹かれるプログラマを引き付けます。

4. 単純さと直接性を好むプログラマーは、PHPまたは同様の言語を引き続き使用します。

悲しいかな、Javaプログラマーはパワーツールに非常に精通しているので、それに答えて、主流のScalaの採用に対する私の期待を改めました。Scalaが主流の言語になることは間違いありません。Cメインストリームではなく、おそらくPerlメインストリームまたはPHPメインストリーム。

Javaについて言えば、クラスローダーを置き換えたことがありますか？これに関係することを調べたことがありますか？フレームワークの作成者が行う場所を見ると、Javaは恐ろしいかもしれません。それはほとんどの人がそうしないというだけです。同じことがScala、IMHOにも当てはまりますが、初期の採用者は、遭遇する各岩の下を調べて、そこに何かが隠れているかどうかを確認する傾向があります。

これは人々がScalaに来るのを先送りにするでしょうか？

はい、しかしそれはまた人々が延期されるのを防ぎます。Scalaがより高い種類の型のサポートを得て以来、より高い種類の型を使用するコレクションの欠如が大きな弱点であると考えてきました。APIドキュメントはより複雑になりますが、実際には使用がより自然になります。

これは、専門の博士課程の学生だけが理解できる学術的な遊び道具として、スカラに商業の世界で悪名を与えるでしょうか？CTOとソフトウェアの責任者は怖がるでしょうか？

おそらくそうするでしょう。Scalaの複雑さや、多くの開発者が学習したくないという理由により、Scalaは多くの「プロフェッショナル」開発者がアクセスできるとは思いません。そのような開発者を雇用するCTOは当然怖がるでしょう。

ライブラリの再設計は賢明なアイデアでしたか？

もちろんです。それはコレクションがまだいくつかのラフなエッジを持っている場合でも、他の言語や型システムとはるかによく適合します。

scalaを商業的に使用している場合、これについて心配していますか？すぐに2.8を採用する予定ですか、それとも何が起こるか確認するのを待ちますか？

商用利用はしていません。バグを洗い流すことができるように、それを導入しようとする前に、2.8.xシリーズが少なくとも2、3回転するまで待つことになるでしょう。EPFLのリリースプロセスの開発を改善する上でEPFLがどれだけ成功するかについても待ちます。私が見ているものは希望に満ちているように見えますが、私は保守的な会社で働いています。

「Scalaは主流の開発者にとって複雑すぎるのですか？」というより一般的なトピックの1つ...

主流またはそれ以外のほとんどの開発者は、既存のシステムを維持または拡張しています。これは、彼らが使用するもののほとんどがずっと前に行われた決定によって決定されることを意味します。まだCOBOLを書く人はたくさんいます。

明日の主流の開発者は、今日構築されているアプリケーションの維持と拡張に取り組みます。これらのアプリケーションの多くは、主流の開発者によって構築されていません。明日の主流の開発者は、今日最も成功している新しいアプリケーションの開発者が使用している言語を使用します。

ScalaコミュニティーがScalaを初めて使用するプログラマーの恐怖を和らげるのに役立つ1つの方法は、練習に集中し、例を挙げて教えることです。このアプローチを取るいくつかのサイトを次に示します。

• 毎日のScala
• 小さなバイトでScalaを学ぶ
• 単にScala

これらのサイトでしばらく時間を過ごした後、Scalaとそのライブラリーは、おそらく設計と実装は難しいかもしれませんが、特に一般的なケースではそれほど難しくないことにすぐに気付きます。

私は安価な「マスマーケット」の米国の大学で学士号を取得しているので、ユーザーインテリジェンス（または少なくとも教育）のスケールの真ん中に陥ると思います:) Scalaをほんの数か月使ってみました。 2つまたは3つの重要なアプリに取り組んできました。

特にIntelliJが、現在最高のScalaプラグインであるIMHOを備えたすばらしいIDEをリリースしたので、Scalaの開発は比較的簡単です。

• 私はScalaを「セミコロンなしのJava」として使用できることを発見しました。つまり、Javaで行うのと同じようなコードを記述し、型推論によって得られるような構文の簡潔さから少し利益を得ています。例外処理は、私が実行する場合には、より便利です。クラスの定義は、getter / setterボイラープレートがなければ、それほど冗長ではありません。

• たまに1行でJavaの複数行に相当するものを書きました。該当する場合、マップ、折りたたみ、収集、フィルターなどの機能メソッドのチェーンは、作成するのが楽しく、見栄えが良いです。

• Scalaのより強力な機能、つまりクロージャーと部分的（またはカリー化）関数、パターンマッチングなどの恩恵を受けることはほとんどありません。

初心者として、私は簡潔で慣用的な構文と格闘し続けています。パラメータのないメソッド呼び出しでは、必要な場所を除いて括弧は必要ありません。matchステートメントのケースには太い矢印（=>）が必要ですが、細い矢印（->）が必要な場所もあります。多くのメソッドは/:orのように短くて不可解な名前を持っています\:-十分なマニュアルページをめくれば自分の仕事をやり遂げることができますが、コードの一部は最終的にPerlまたはラインノイズのように見えます。皮肉なことに、構文の速記の最も人気のあるビットの1つが実際には欠けIntています++。

これは私の意見です。Scalaには、C ++の複雑さと可読性を組み合わせたC ++の機能があるように感じます。言語の構文が複雑であるため、APIドキュメントも読みにくくなっています。

Scalaは非常によく考えられており、多くの点で優れています。私は多くの学者がそれにプログラムしたいのではないかと思います。ただし、それはまた、巧妙さと落とし穴がいっぱいで、Javaよりもはるかに学習曲線が長く、読みにくいです。フォーラムをスキャンして、Javaの細かい点にまだ取り組んでいる開発者の数を見ると、Scalaが主流の言語になることは想像できません。以前は1週間のJavaコースのみが必要だった場合、3週間のScalaコースで開発者を派遣することを正当化することはできません。

その方法の主な問題は、(implicit bf : CanBuildFrom[Repr, B, That])説明なしで行くことです。私はどのような暗黙の引数があるか知っていますが、これが呼び出しにどのように影響するかを示すものは何もありません。scaladocを追跡しても、混乱するだけです（CanBuildFromドキュメントに関連するクラスはほとんどありません）。

単純な「スコープには暗黙のオブジェクトが必要です bfためB、戻り値の型にオブジェクトのビルダーを提供するThat」と多少は役立つと思いますが、本当にやりたいことはA、Bの。実際、タイプが何をRepr意味するのかわからないので、私はそれが正しいかどうか確信がありませんTraversable。

したがって、私は2つのオプションを残しましたが、どちらも快適ではありません。

• 古いマップがどのように機能するか、他のほとんどの言語でマップがどのように機能するかを想定します
• ソースコードをもう少し掘り下げる

Scalaは本質的にこれらのものがどのように機能するかという根本を明らかにしており、最終的にこれはoxbow_lakesが説明していることを実行する方法を提供していると思います。しかし、それは署名の邪魔です。

私はScalaの初心者であり、正直なところ、その型シグネチャに関する問題は見当たりません。パラメータはマップする関数であり、暗黙的なパラメータは正しいコレクションを返すビルダーです。明確で読みやすい。

実際、全体は非常にエレガントです。ビルダー型パラメーターを使用すると、コンパイラーは正しい戻り型を選択できますが、暗黙的なパラメーターメカニズムにより、この余分なパラメーターがクラスユーザーから隠されます。私はこれを試しました：

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

それは正しく行われた多態性です。

当然のことながら、これは主流のパラダイムではなく、多くの人を怖がらせます。しかし、それはまた、その表現力と優雅さを大切にする多くの人を魅了します。

残念なことに、あなたが与えたマップの署名はマップの署名ではなく、確かに正当な批判があります。

最初の批判は、マップの署名を覆すことにより、より一般的なものがあるということです。これがデフォルトで美徳であると信じることは一般的なエラーです。そうではありません。map関数は、共変ファンクタFx->（x-> y）-> Fyとして非常によく定義されており、構成と同一性の2つの法則に準拠しています。「マップ」に起因する他のすべては茶番です。

指定された署名は別のものですが、マップではありません。それがしようとしているのは、論文「イテレーターパターンの本質」からの「トラバース」シグネチャの特殊化された、わずかに変更されたバージョンだと私は思います。ここにその署名があります：

traverse :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

私はそれをScalaに変換します：

def traverse[A, B](f: A => F[B], a: T[A])(implicit t: Traversable[T], ap: Applicative[F]): F[T[B]

もちろん失敗します-一般的ではありません！また、少し異なります（Identityファンクタをトラバースすることでマップを取得できることに注意してください）。ただし、ライブラリの作成者が十分に文書化されているライブラリの一般化を理解している場合（エフェクトを使用したアプリケーションプログラミングの前に前述）、このエラーは発生しないと思います。

次に、map関数はfor内包表記で使用されるため、Scalaでは特殊なケースです。残念ながら、これは、よりよく装備されたライブラリ設計者は、理解の構文上の砂糖を犠牲にすることなく、このエラーを無視できないことを意味します。つまり、Scalaライブラリの設計者がメソッドを破棄する場合、これは簡単に無視されますが、マッピングしないでください。

誰かがそれについて話してくれるといいのですが、それは、Scalaが主張するエラーを回避するのが難しくなるからです。つまり、「平均的なプログラマーからの無責任な異議（つまり、難しすぎる！）」に対する解決策は、「彼らをなだめるために彼らをなだめるように落ち着かせる」ことではなく、より良いプログラマーになるための指針と支援を提供することです。私自身とScalaの目的はこの問題で争っていますが、あなたの主張に戻ります。

あなたはおそらく「平均的なプログラマ」からの具体的な反応を予測して、あなたの主張をしていました。つまり、「でも複雑すぎる」と主張する人たち。またはそのようなもの。これらはあなたが言及するイェージまたはブロッホです。これらの人々の反知的主義/プラグマティズム運動に対する私の反応は非常に厳しく、私はすでに大量の反応を予想しているので、それは省略します。

Scalaライブラリーが改善されることを心から願っています。少なくとも、エラーが安全に片隅に隠れるようになることを願っています。Javaは「有用なことをしようとする」ことは非常にコストがかかる言語であり、圧倒的な量のエラーを回避することができないため、多くの場合それは価値がありません。私は同じ道をたどらないようにScalaに働きかけます。

私は質問とマーティンの答えの両方に完全に同意します:)。Javaでも、ジェネリックでjavadocを読むのは、余分なノイズが原因で、本来あるべきよりもはるかに困難です。これはScalaで複合化されており、質問のサンプルコードのように暗黙的なパラメーターが使用されます（暗黙的には非​​常に便利なコレクションモーフィング機能を実行します）。

言語自体の問題だとは思いません。ツールの問題だと思います。そして、私はJörgW Mittagが言うことに同意しますが、私はscaladoc（またはIDE内の型のドキュメント）を見ると思います-メソッドが何であるか、それが何を返し、何を返すかを理解するのに可能な限り少ない頭脳の力を必要とするはずです。それを取得するために、少しの代数を少しの紙にハックする必要はないはずです:)

確かにIDEは、変数/式/タイプのすべてのメソッドを表示するための優れた方法が必要です（マーティンの例と同様に、すべてのジェネリックをインライン化できるため、簡単に操作できます）。私は、デフォルトで暗黙を隠すというマーティンの考えも好きです。

scaladocで例をとるには...

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

これをscaladocで見るとき、ジェネリックブロック[B、That]をデフォルトで非表示にして、暗黙のパラメーター（おそらく、マウスで小さなアイコンにカーソルを合わせると表示される）を非表示にしたいそれを読むことは、通常は関係ありません。たとえば、これが次のようになっていると想像してください...

def map(f: A => B): That

それが何をするのか分かりやすく、明確で明白です。「あれ」が何であるか不思議に思うかもしれませんが、マウスを上に置くかクリックすると、たとえば[あれ]を強調表示する[B、あの]テキストが展開されます。

[]宣言と（暗黙的...）ブロックに小さなアイコンを使用できるので、ステートメントの小さな部分が折りたたまれていることは明らかですか？トークンを使用するのは難しいですが、私はを使用します。今のところ...

def map.(f: A => B).: That

したがって、デフォルトでは、型システムの「ノイズ」は、人々が見る必要のある主要な80％から隠されています-メソッド名、そのパラメーター型、および戻り値の型は、シンプルで簡潔な方法で、詳細への拡張可能なリンクがほとんどありません。あなたが本当にそんなに気にかけているなら。

ほとんどの人はscaladocを読んで、型に対して呼び出すことができるメソッドと、渡すことができるパラメーターを見つけています。私たちは、ユーザーがIMHOをどのように細かく過負荷にしているのかを理解しています。

ここに別の例があります...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

ジェネリック宣言を非表示にすると、読みやすくなります

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

次に、たとえばA1にカーソルを合わせると、A1がA1であることの宣言を示すことができます<：A.ジェネリックでの共変および反変の型は、ノイズを多く追加します。

私はそれをどのように壊すかわかりませんが、ケンブリッジの博士号を取得しており、2.8を使用しています。

もっと真剣に、私は2.7にほとんど時間を費やさず（私が使用しているJavaライブラリと相互運用しない）、1か月ほど前にScalaを使い始めました。私はHaskellである程度の経験がありますが、心配していることを無視して、Java（私が生活で使用しているもの）での経験と一致するメソッドを探しました。

だから：私は「新しいユーザー」であり、私は延期されませんでした-それがJavaのように機能するという事実は、私が理解していないビットを無視する十分な自信を与えてくれました。

（しかし、私がScalaを検討していた理由の1つは、仕事でそれをプッシュするかどうかを確認することであり、まだそうするつもりはありません。ドキュメントをあまり威圧しないようにすることは確かに役立ちますが、驚いたのは、それでもそれがどれだけ残っているかです。変更して開発中です（公平に言うと、最も驚いたのはその素晴らしさでしたが、変更点はすぐ近くにありました）。だから、私は、限られたリソースを投入するほうが好きだと思います。最終的な状態-私は彼らがこれほどすぐにこの人気になるとは思っていなかったと思います。）

Scalaについてはまったく知りませんが、数週間前はClojureを読むことができませんでした。今ではそのほとんどを読むことができますが、最も単純な例以外には何も書くことができません。Scalaも同じだと思います。学習方法に応じて、優れた本またはコースが必要です。上記のマップ宣言を読んだだけで、おそらくその 3分の1 を得ました。

より大きな問題は、これらの言語の構文ではなく、日常のプロダクションコードで使用できるようにするパラダイムを採用して内部化することだと思います。私にとって、JavaはC ++からの大きな飛躍ではありませんでした。Cからの大きな飛躍ではありませんでした。PascalやBasicなどからの飛躍ではありませんでした。しかし、Clojureのような関数型言語でのコーディングは、大きな飛躍です（とにかく私）。Scalaでは、JavaスタイルまたはScalaスタイルでコーディングできると思います。しかし、Clojureでは、Javaからの命令的な習慣を維持しようとするかなりの混乱を作成します。

Scalaには、非常に複雑で学術的に見える奇妙な機能（特に暗黙的なパラメーターが関係する場合）がたくさんありますが、使いやすいように設計されています。最も有用なものは、構文糖（[A <% B]タイプAのオブジェクトがタイプBのオブジェクトに暗黙的に変換されることを意味します）とそれらが何をするかについての十分に文書化された説明を取得します。しかし、ほとんどの場合、これらのライブラリのクライアントとして、暗黙のパラメーターを無視して、それらが正しいことを実行することを信頼できます。

これは人々がScalaに来るのを先送りにするでしょうか？

Scalaには多くの能力があり、その構文はHaskell、OCaml、SML、LispなどのJava / C ++ / PHPプログラマーにとって外部的なものではないため、これがScalaの人気度に影響を与える主な要因ではないと思います。等..

しかし、Scalaの人気は、Javaが現在ある場所よりも安定するだろうと思います。次の主流の言語を大幅に簡略化する必要があると私は思います。また、純粋な不変性、つまりHTMLのような宣言型ですが、チューリングは完全です。しかしながら、私はそのような言語を開発しているので私は偏見がありますが、私が必要とするものをScalaが十分に満たすことができないという数ヶ月にわたる研究を除外した後にのみ私はそうしました。

これは、専門の博士課程の学生だけが理解できる学術的な遊び道具として、Scalaを商業の世界で悪名にするのでしょうか？CTOとソフトウェアの責任者は怖がるでしょうか？

Scalaの評判がHaskell複合体の影響を受けるとは思いません。しかし、ほとんどのプログラマーにとって、Scalaを使用するように強制するユースケースはまだ見当たらないため、学習を先延ばしにする人もいるため、学習を延期する人もいると思います。おそらく、非常にスケーラブルなサーバー側が最も説得力のあるユースケースです。

そして、主流の市場にとって、Scalaの最初の学習は「新鮮な空気の息吹」ではなく、最初にHTMLやPythonを使用するなど、すぐにプログラムを作成します。Scalaは、最初からつまずくすべての詳細を学んだ後、あなたに成長する傾向があります。しかし、おそらくScalaでプログラミングを最初から読んでいたとしたら、私の経験と学習曲線についての意見は異なっていたでしょう。

ライブラリの再設計は賢明なアイデアでしたか？

絶対に。

Scalaを商業的に使用している場合、これについて心配していますか？すぐに2.8を採用する予定ですか、それとも何が起こるか確認するのを待ちますか？

新しい言語の初期プラットフォームとしてScalaを使用しています。Scalaを商業的に使用していれば、Scalaのコレクションライブラリでコードを構築することはおそらくないでしょう。私は自分のカテゴリー理論ベースのライブラリーを作成しました。一度見たとき、Scalazの型シグニチャーはScalaのコレクション・ライブラリーよりもさらに冗長で扱いにくいことがわかりました。その問題の一部はおそらくScalaの型クラスの実装方法にあり、それが私が自分の言語を作成している小さな理由です。

Scalaのコレクションクラスの設計を自分の言語用に行っているものと調査して比較したいと思ったので、この回答を書くことにしました。私の思考過程も共有するかもしれません。

2.8 Scalaコレクションでのビルダー抽象化の使用は、健全な設計原則です。以下の2つの設計のトレードオフについて説明します。

1. 書き込み専用コード：このセクションを書いた後、私はトレードオフになると予想することに同意するカールスモトリクスのコメントを読みました。James Strachanとdavetron5000のコメントは、Thatの意味（That [B]でさえない）と暗黙のメカニズムは直感的に理解するのが容易ではないことを認めています。以下の問題＃2でのモノイドの使用を参照してください。Derek MaharのコメントはScalaの記述に関するものですが、「一般的なケース」ではない他の人のScalaの記述についてはどうでしょうか。

   私がScalaについて読んだ批判の1つは、他の人が書いたコードを読むよりも、書く方が簡単だということです。そして、私はこれがさまざまな理由（例えば、関数を書くための多くの方法、自動クロージャー、DSLのユニットなど）のために時々真実であるとわかりますが、これが主要な要因であるかどうか私は未定です。ここで、暗黙の関数パラメーターの使用にはプラスとマイナスがあります。プラスの面では、冗長性が減少し、ビルダーオブジェクトの選択が自動化されます。オデルスキーの例ではBitSet、つまりSet [Int]からSet [String]への変換は暗黙的です。コードの不慣れな読者は、現在のパッケージスコープに存在する可能性のあるすべての潜在的な非表示の暗黙的なビルダー候補について十分に推論できない限り、コレクションの種類を簡単に理解できない可能性があります。もちろん、経験豊富なプログラマーとコードの作成者は、BitSetがIntに制限されていることを知っているため、Stringへのマップは別のコレクション型に変換する必要があります。しかし、どのコレクションタイプですか？明示的に指定されていません。

2. アドホックコレクションデザイン：このセクションを書いた後、トニーモリスのコメントを読んだところ、ほぼ同じことを言っていることに気付きました。おそらく、私のより冗長な説明がポイントをより明確にするでしょう。

   「タイプによるビットの腐敗と戦う」Odersky＆Moorsでは、2つの使用例が示されています。これらは、BitSetからInt要素への制限、およびMapがタプル要素をペアにするための制限であり、一般的な要素マッピング関数A => Bが代替の宛先コレクション型を構築できる必要がある理由として提供されます。しかし、これはカテゴリー理論の観点から見れば欠陥があります。カテゴリ理論で一貫性を保ち、したがってコーナーケースを回避するために、これらのコレクションタイプはファンクタであり、各モーフィズムA => Bは、同じファンクタカテゴリのオブジェクト間でマップする必要があります。List[A] => List [B]、BitSet [A] => BitSet [B]。たとえば、オプションは1つのSome（オブジェクト）とNoneのセットのコレクションとして表示できるファンクターです。OptionのNoneやListのNilから、他のファンクタへの一般的なマップはありません。

   ここでは、トレードオフの設計を選択します。新しい言語のコレクションライブラリのデザインでは、すべてをファンクタにすることを選択しました。つまり、BitSetを実装する場合は、非ビットフィールドの内部表現を使用して、整数型のパラメーターであり、その機能は既にScalaで継承するセットに含まれています。そして、私のデザインのMapは、その値のみをマップする必要があり、（key、value）のペアのタプルをマップするための別個の非ファンクターメソッドを提供できます。1つの利点は、各ファンクタが通常はアプリケーションであり、おそらくモナドでもあることです。したがって、要素タイプ間のすべての関数（A => B => C => D => ...など）は、リフトされたアプリケーションタイプ間の関数に自動的にリフトされます（例：List [A] => List [B] => List [ C] =>リスト[D] => .... ファンクタから別のコレクションクラスにマッピングするために、モノイドを取得するマップオーバーロード（Nil、None、0、 ""、Array（）など）を提供します。したがって、ビルダー抽象化関数はモノイドのappendメソッドであり、必要な入力パラメーターとして明示的に提供されるため、目に見えない暗黙の変換はありません。（接線：この入力パラメーターは、空でないモノイドへの追加も可能にします。これは、Scalaのマップ設計ではできません。）そのような変換は、同じ反復パスでのマップとフォールドです。また、カテゴリの意味でのトラバーサブル、「エフェクトを使用したアプリケーションプログラミング」、マクブライド＆パターソンを提供します。これにより、すべてのコレクションクラスが両方であるすべてのトラバーサブルから任意のアプリケーションへの単一の反復パスでマップ+フォールドも可能になります。

   したがって、Scalaコレクションは、カテゴリー理論に基づいていないという意味で「アドホック」であり、カテゴリー理論は、高レベルの表示セマンティクスの本質です。Scalaの暗黙のビルダーは、最初はファンクターモデル+モノイドビルダー+トラバーサブルよりも「一般化」されているように見えますが、適用可能です。最も一般的な意味とコーナーケースが与えられるものは、どのカテゴリーモデルにも従わないかもしれません。より多くの変数を追加することでより一般的なものになるというのは事実ではありません。これは、カテゴリ理論の大きな利点の1つであり、より高いレベルのセマンティクスに引き上げながら一般性を維持するためのルールを提供します。コレクションはカテゴリです。

   私がどこかで読んだのは、ライブラリー設計のもう1つの正当化として、Oderskyだったと思います。純粋な関数スタイルでのプログラミングには、再帰の制限とテール再帰が使用されない速度のコストがあるということです。これまでに遭遇したすべてのケースで、末尾再帰を採用することは難しいとは思いませんでした。

さらに、私はScalaのトレードオフの一部が、たとえばHaskellや私が開発している言語とは異なり、変更可能な言語と不変の言語の両方になることを試みているためであるという不完全な考えを覚えています。これは理解のためのトニーモリスのコメントに同意します。私の言語では、ループや変更可能な構造はありません。私の言語は（今のところ）Scalaの上にあり、その多くがそのおかげです。Scalaに一般的な型システムと可変性がない場合、これは不可能です。私はOdersky＆Moors（ "Fighting Bit Rot with Types"）が間違っていると思うので、それは真実ではないかもしれませんMLにはそれらがあります。また、SMLの型システムは同等に柔軟である可能性があります（1980年代以降）。これは、構文がScalaほどJava（およびC ++ / PHP）に似ていないため、すぐには理解できません。いずれにせよ、これはScalaを批判するものではなく、トレードオフの不完全な分析を提示しようとする試みです。ScalaとSMLはHaskellが実行できないことに悩まされないダイアモンド多重継承は重要であり、Haskell Preludeの非常に多くの機能がさまざまなタイプで繰り返される理由は理解しています。

ここで学位を示す必要があるようです：政治学の学士号とコンピュータサイエンスの学士号。

ポイントへ：

これは人々がScalaに来るのを先送りにするでしょうか？

基礎となるプログラミングパラダイムが難しいため、Scalaは困難です。関数型プログラミングは多くの人を怖がらせます。PHPでクロージャーを作成することは可能ですが、ほとんどの人が作成することはありません。したがって、このシグネチャではありませんが、基礎となるパラダイムの力を評価するための具体的な教育を受けていない場合、残りすべてが人々を先延ばしにします。

この教育が利用可能であれば、誰でもそれを行うことができます。昨年、私はSCALAでたくさんの学校の子供たちとチェスコンピュータを構築しました。彼らは問題を抱えていましたが、結局うまくいきました。

Scalaを商業的に使用している場合、これについて心配していますか？すぐに2.8を採用する予定ですか、それとも何が起こるか確認するのを待ちますか？

気になりません。

私もオックスフォードで数学の学位を持っています！新しいコレクションのものを「入手」するのにしばらく時間がかかりました。でも今は好きです。実際、「マップ」のタイピングは、2.7で私を悩ませた最初の大きな問題の1つでした（おそらく、最初に行ったのは、コレクションクラスの1つであるサブクラスだったためです）。

新しい2.8コレクションに関するMartinの論文を読んだことは、暗黙の使用法を説明するのに本当に役立ちましたが、そうです、ドキュメント自体は、コアAPIのメソッドシグネチャ内の異なる種類の暗黙の役割を説明するより良い仕事をする必要があります。

私の主な懸念はこれ以上です：2.8はいつリリースされますか？バグレポートはいつ届きなくなりますか？Scalaチームが2.8でかじることができる以上に噛み付きました/一度に多くを変更しようとしましたか？

新しい2.8を追加する前に、2.8がリリース用に安定化されることを優先し、（傍観者から見ながら）scalaコンパイラーの開発ロードマップの管理方法にいくつかの改善を加えることができるかどうか疑問に思います。

使用サイトのエラーメッセージはどうですか？

そして、DSLに適合するカスタムタイプと既存のタイプを統合する必要があるユースケースがいつになるかについてはどうでしょう。関連付け、優先順位、暗黙の変換、暗黙のパラメータ、より高い種類、そしておそらく存在型の問題について十分に教育する必要があります。

ほとんどが単純ですが、必ずしも十分ではないことを知っておくのはとても良いことです。広範囲にわたるライブラリを設計する場合、少なくともこのことを知っている人が1人いるはずです。