collection - Scala 2.8のコレクションライブラリは、「歴史上最も長い自殺メモ」の一例ですか?

これはScalaに来る人々を捨て去るつもりですか？

Scalaには多くのパワーがあり、その構文はHaskell、OCaml、SML、LispsなどのJava / C ++ / PHPプログラマーにとって異質ではないので、Scalaの普及率に影響する主な要因ではないと思います。等..

しかし、Scalaの人気は、Javaが今日のどこよりも安くなると思うのですが、次の主流言語ははるかに単純化されなければならないと思うので、純粋な不変性、つまりHTMLのような宣言的ですが、 。しかし、私はそのような言語を開発しているので私は偏っていますが、私はスカラが私に必要なもので十分ではないという数ヶ月の研究を否定しただけです。

これは、専攻博士課程の学生だけが理解できる学術的なものとして、商業的な世界でScalaに悪名を与えるでしょうか？CTOやソフトウェア責任者は怖がっていますか？

私はScalaの評判がHaskellの複合体に苦しんでいるとは思わない。しかし、私は、ほとんどのプログラマにとって、Scalaの使用を強制するユースケースはまだ見ていないので、学習を延期する人もいるので、一部の人はそれを習得しないと思います。おそらく、スケーラビリティの高いサーバー側が最も魅力的なユースケースです。

そして、主流市場では、最初にScalaを学ぶことは、最初にHTMLやPythonを使用するなど、すぐにプログラムを書く「新鮮な空気の息吹」ではありません。Scalaは、最初から不安を抱くような細部をすべて学んだら、あなたの上で成長する傾向があります。しかし、最初からScalaでProgrammingを読んでいたのであれば、私の経験と学習曲線の意見は異なっていたでしょう。

図書館は賢明なアイデアを再設計しましたか？

絶対に。

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

私は新しい言語の最初のプラットフォームとしてScalaを使用しています。Scalaを商業的に使用していた場合は、Scalaのコレクションライブラリにコードを構築していない可能性があります。ScalaのコレクションのライブラリよりもScalazの型シグネチャがさらに冗長で扱いにくいことがわかったので、自分のカテゴリ理論に基づくライブラリを作成しました。その問題の一部は、おそらくスカラの型クラスを実装する方法であり、それは私自身の言語を作成しているマイナーな理由です。

私はこの答えを書くことに決めました。Scalaのコレクションクラスのデザインを自分の言語のために研究して比較することを強く求めたからです。私の思考プロセスを分かち合うかもしれない。

2.8スカラコレクションでは、ビルダー抽象化の使用は健全な設計原則です。私は以下の2つのデザインのトレードオフを探求したいと思う。

1. 書き込みのみのコード：このセクションを書いた後、私はCarl Smotriczのコメントを読んで、私はこのトレードオフになると思います。James Strachanとdavetron5000のコメントは、Thatの意味（That [B]でさえない）と暗黙のメカニズムが直感的に理解するのが容易ではないことに同意します。下の問題2で私のモノロイドの使用を参照してください。これははるかに明白です。Derek MaharのコメントはScalaの作成に関するものですが、「一般的な場合」ではない他のScalaの読み方についてはどうでしょうか。

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

2. AD-HOCコレクションデザイン：このセクションを書いた後、私はTony Morrisのコメントを読んで、私がほぼ同じ点を作っていることに気づいた。おそらく私のより冗長な展覧会は、ポイントをより明確にするでしょう。

   Odersky＆Moorsの "Fighting Bit Rot with Types"では、2つのユースケースが提示されています。それらはBitSetからInt要素への制限であり、Mapはタプル要素のペアであり、一般的な要素マッピング関数A => Bが別の宛先コレクション型を構築できる必要があるからです。しかし、これはカテゴリー理論の観点からは欠点があります。カテゴリ理論で一貫してコーナーケースを避けるために、これらのコレクション型は、それぞれのモーフがA => Bである同じファンクタカテゴリのオブジェクト間でマップする必要があるファンクタです。List [A] => List [B]、BitSet [A] =>ビットセット[B]。たとえば、OptionはSome（オブジェクト）とNoneのセットのコレクションとして見ることができるファンクタです。 OptionのNoneまたはListのNilから、他のFunctorへの一般的なマップはありません。tは "空"状態です。

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

   だからスカラーコレクションはカテゴリ理論に根付いていないという意味で「アドホック」であり、カテゴリ理論はより高位の意味論的意味論の要点です。 Scalaの暗黙のビルダーは、ファンクターモデル+ Monoid Builder + Traversable-> applicativeよりも、最初に「より一般化された」ようですが、どのカテゴリーとも一貫しているとは証明されていません。最も一般的な意味で、コーナーケースはどのカテゴリモデルにも従わないことがあります。より多くの変数を追加すると、より一般的なものになるということは単に真実ではなく、カテゴリ理論の大きな利点の1つは、より高いレベルのセマンティクスに持ち上げながら一般性を維持するためのルールを提供することです。コレクションはカテゴリです。

   ライブラリデザインのもう一つの正当な理由として、純粋な関数型のプログラミングでは、テール再帰が使用されない再帰と速度の制限があるということです。これまでに遭遇したすべてのケースで、末尾再帰を使用することは難しくありませんでした。

さらに、私は、Scalaのトレードオフのいくつかは、例えば、Haskellや私が開発している言語とは異なり、可変で不変の言語にしようとしているという不完全な考えを私の心に持っています。これは、理解のためのTony Morrisのコメントに同意します。私の言葉では、ループはなく、変更可能な構造はありません。私の言葉はScala（今のところ）の上にあり、それには多大な負担があります.Scalaが一般的な型システムと可変性を持たないなら、これは可能ではありません。私はOdersky＆Moors（ "Fighting Bit Rot with Types"）は、Scalaが高級な唯一のOOP言語であると述べるのは間違っていると思うので、私は自分自身とBob Harperを介してStandard MLにはそれらがあります。また、SMLのタイプシステムは、（1980年代から）同等に柔軟性がありますこの構文はScalaのようにJava（およびC ++ / PHP）にあまり似ていないため、簡単には理解できません。いずれにせよ、これはScalaの批判ではなく、トレードオフの不完全な分析を提示する試みです。私はこの問題に密接に関係しています。 ScalaとSMLはハスケルができないことに悩まされないダイヤモンドの多重継承は非常に重要なことであり、私が理解するのは、なぜHaskell Preludeの中の非常に多くの関数が異なる型に対して繰り返されているのかということです。

これはScalaに来る人々を捨て去るつもりですか？

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

これは、博士課程の専攻学生だけが理解できる学術的なものとして、商業界でスカラーに悪名を与えるでしょうか？ CTOやソフトウェア責任者は怖がっていますか？

おそらくいくつか。 Scalaは、Scalaの複雑さや、多くの開発者が習得したくないために、多くの "プロ"開発者がアクセスできるとは思えません。 そのような開発者を採用しているCTOは正しく脅かされるでしょう。

図書館は賢明なアイデアを再設計しましたか？

絶対に。 たとえまだまだ荒いエッジが残っていても、コレクションは他の言語や型システムと比べてはるかに優れています。

あなたがスカラを商業的に使用しているなら、これについて心配していますか？ すぐに2.8を採用する予定ですか、何が起こるのを待っていますか？

私はそれを商業的に使っていない。 私は恐らくバグを洗い流すことができるように導入する前に、2.8.xシリーズに少なくとも2つ以上回転させるまで待つでしょう。 また、EPFLがリリースプロセスの改善をどの程度成功させたのかを待つつもりです。 私が見ていることは有望に見えますが、私は保守的な会社に勤めています。

「Scalaは主流の開発者にとっては複雑すぎるのですか？

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

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

ScalaコミュニティがScalaに慣れていないプログラマの恐怖を緩和するための1つの方法は、実践に焦点を当て、例を挙げて指導することです。 このアプローチを採用しているサイトは次のとおりです。

• 毎日のスカラ
• 小さなお尻でスカラを学ぶ
• 単純にスカラ

これらのサイトに時間を費やした後、Scalaとそのライブラリは、設計や実装が難しいかもしれないが、特に一般的なケースでは、それほど難しくありません。

ここに学位を授与する必要があるようです：政治学のBAとコンピュータサイエンスのB.ed。

ポイントへ：

これはScalaに来る人々を捨て去るつもりですか？

その基本的なプログラミングのパラダイムが難しいため、Scalaは難しいです。機能プログラミングは多くの人を怖がらせる。PHPでクロージャを構築することは可能ですが、人々はほとんど行いません。そうではありません。この署名ではなく、残りのすべてが、彼らが根底にあるパラダイムの力を大切にするような具体的な教育を受けていなければ、人々を捨てるでしょう。

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

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

私は心配しないだろう。

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

また、ユースケースになると、既存のタイプをDSLに適合するカスタムタイプと統合する必要があります。関連性、優先度、暗黙的な変換、暗黙的なパラメータ、より高い種類、おそらく存在するタイプの問題について十分に教育されなければならない。

それはほとんどそれがシンプルだが、必ずしも十分ではないことを知っていることは非常に良いです。広大な図書館が設計されているなら、少なくともこの人物を知っている一人の男がいなければなりません。

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

最初の批判は、地図の署名を覆すことによって、より一般的なものがあるということです。 これがデフォルトでは美徳だと考えるのはよくある誤りです。 そうではありません。 マップ関数は、共起関数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]

もちろんそれは失敗します - それは一般的ではありません！ また、それはわずかに異なります（IDファンクタを介してトラバースを実行してマップを取得できることに注意してください）。 しかし、私は、ライブラリの作者がよく文書化されているライブラリの一般化を知っていれば（前述のように、Applicative Programming with Effectsが先行する）、このエラーは表示されないと考えられます。

第2に、map関数は、for-comprehensionsでの使用のために、Scalaの特別なケースです。 これは残念なことに、より良い装備を備えた図書館デザイナーは、理解の構文的砂糖を犠牲にすることなくこのエラーを無視することはできません。 言い換えれば、Scalaライブラリデザイナーがメソッドを破棄した場合、これは簡単に無視されますが、マップしないでください！

誰かがそれについて話してくれることを願っています。なぜなら、スカラが強く反対している理由のために、スカラが主張しているエラーを回避することは難しくなるからです。すなわち、「平均的なプログラマーからの無責任な反対（すなわち、あまりにも難しい！）」に対する解決策は、より良いプログラマーになるための指針と支援を提供することです。自分自身とScalaの目標はこの問題に争点がありますが、あなたのところまで戻ります。

あなたはおそらく "平均的なプログラマー"からの特定の反応を予測して、あなたの指摘をしていました。つまり、「それは複雑すぎる」と主張する人たちです。またはそのようなもの。これらはあなたが参照しているイージーまたはブロッホです。反知的主義/実用主義運動のこれらの人々に対する私の反応はかなり厳しいものであり、すでに私は反発の嵐を予期しているので、私はそれを省略します。

Scalaのライブラリが改善されることを願っています。少なくとも、エラーは安全にコーナーで逃げることができます。Javaは、「有用なことをしようとする」という言葉は信じられないほど高価なので、圧倒的な量のエラーを単純に回避することはできないため、しばしば価値がありません。私はScalaが同じ道を踏み外さないことを納得させます。

私はあなたにそれを壊す方法はわかりませんが、私はケンブリッジから博士号を持っています。私は2.8を使っています。

もっと真剣に、私はほとんど使用していなかった2.7（これは、私が使用しているJavaライブラリと相互運用することはありません）とScalaをわずか1ヶ月前から使い始めました。私はハスケル（多分ではない）といくつかの経験を持っていますが、あなたが心配しているものを無視し、Java（私は生きるために使用）との私の経験に合った方法を探しました。

だから、私は「新しいユーザー」だと私は断っていませんでした。Javaのように動作するという事実は、私が理解できなかったビットを無視するのに十分な自信を与えました。

（しかし、私がScalaを見ていたのは、仕事でそれを押しつけるかどうかを見極めることの一部でしたが、私はまだそれをやろうとはしていませんでした。変化して、開発されている（私に最も驚いたのはそれがどれだけ素晴らしかったかということではないが、その変化はもう少しだ。）私が言っていることは、限られた資源を最後の状態 - 私は彼らがすぐにこの人気があることを期待していたとは思わない。）

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

私はシンプルな「「 B型のオブジェクトのビルダーを返す型に提供する暗黙のオブジェクトがなければならない」と思うが、 Thatはやや助けになるだろうが、本当にやりたいことが面白いAからBへ。 実際、 Reprのタイプが何であるかわからないので、そうは確かではありませんTraversableのドキュメントは確かに何の手がかりも与えません。

だから、私は2つの選択肢が残っています、どちらも楽しいものではありません：

• 古いマップがどのように動作し、地図が他のほとんどの言語でどのように動作するかを考えてみましょう
• もう少しソースコードを掘り下げてください

私はScalaが基本的にこれらのことがどのように機能するかを明らかにしており、最終的にはこれがoxbow_lakesが何を記述しているかを行う方法を提供していることがわかります。 しかしそれは署名の気を散らすものです。

私は博士号を持っていませんし、CSや数学、あるいは他の分野でも学位を取得していません。 私はScalaや他の似たような言語についての以前の経験はありません。 私は遠隔的に匹敵するタイプのシステムでさえ経験はありません。 実際、タイプシステムを持っているだけの表面的な知識以上の唯一の言語は、洗練されたタイプのシステムでは正確に知られていないパスカルです。 （範囲タイプはありますが、AFAIKには他の言語はほとんどありませんが、ここではあまり関係ありません）私が知っている他の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は引数として2つの関数を使用します？ "
2. 実際に型署名を読むことができる必要があります。 しかし、これまでScalaを見たことがない人でも、これは非常に簡単です。これは、あなたが既に他の言語から知っている型構文の混合物に過ぎないからです。VB.NETはパラメトリック多形性のために角括弧を使用し、戻り値の型と名前と型を区別するコロンは、実際には標準です。
3. ジェネリックプログラミングについては、おおまかに知る必要があります。 （これは、基本的にすべての名前に綴られているので、理解するのは難しいことではありません。文字通り一般的な方法でプログラミングしています）。

これら3つのうちのどれも、専門家でも趣味のプログラマーにも重大な頭痛を与えるものではありません。 mapは、過去50年の間に設計されたほとんどすべての言語で標準的な機能を果たしました。異なる言語が異なる構文を持つという事実は、HTMLとCSSでウェブサイトを設計していて、一般的なプログラミングの利点を説明しているSt. Stepanovの教会からの迷惑なC ++のファンボーイもなく、プログラミングに関連したメーリングリスト。

はい、Scala は複雑です。 はい、Scalaは、Haskell、Miranda、CleanまたはCycloneのような言語を凌駕し、さらにはそれを上回る、最も洗練された型システムのひとつです。 しかし、複雑さがプログラミング言語の成功に対する議論であるならば、C ++はずいぶん前に死んでいただろう。我々はすべてSchemeを書くだろう。 Scalaがうまくいかない理由はたくさんありますが、キーボードの前に座る前に脳を動かさないようにプログラマーを気にすることができないという事実はおそらく主なものにはならないでしょう。

私は安価な「大衆市場」の米国の大学から学士号を取得しているので、私はユーザインテリジェンス（または少なくとも教育）のスケールの中に落ちると言いたいと思います:)私はわずか数ヶ月間Scalaを手に取っています2つか3つの重要なアプリケーションに取り組んできました。

特に今IntelliJがIMHOが現在最も優れたScalaプラグインとなっている優れたIDEをリリースした今、Scalaの開発は比較的簡単です。

• 私はScalaを「セミコロンなしのJava」として使うことができます。つまり、私はJavaでやることと同じようなコードを書いています。型推論によって得られたような構文的簡潔さから少しは利益を得ます。 例外処理は、私がそれをやるともっと便利です。 getter / setterの定型句がなければ、クラスの定義はあまり冗長ではありません。

• たまには、複数行のJavaに相当する1行を書き込むことができます。 可能であれば、地図、折り畳み、収集、フィルターなどの機能的な方法の連鎖は楽しいものです。

• Scalaのより高性能な機能（クローズや部分的な（またはカルト）機能、パターンマッチングなど）のメリットはめったにありません。

初心者として、私は簡潔で慣用的な構文で苦労し続けます。 パラメータを指定しないメソッド呼び出しでは、括弧は必要ありません。 matchステートメントのケースに太い矢印（ => ）が必要ですが、細い矢印（ -> ）が必要な場所もあります。 多くのメソッドは、短いものではなく、 /:や\:ようなあいまいな名前を持っています。マニュアルページを十分に埋めれば、自分のものを得ることができますが、コードの一部がPerlやラインノイズのように見えます。 皮肉なことに、最も一般的な構文上の短縮形の1つが実際には行方不明になっていますIntが++メソッドを定義していないという事実にIntれ続けます。

これは私の意見です：ScalaはC ++の能力とC ++の複雑さと可読性を併せ持っているような気がします。 言語の構文が複雑であるため、APIのドキュメントも読みにくくなります。

Scalaは多くの点で非常によく考えられ 、華麗です。 私は多くの学者がそれをプログラムしたいと思っています。 しかし、それはまた、賢明さと嫌なことでいっぱいです、それはJavaよりもはるかに高い学習曲線を持っており、読むのは難しいです。 私がこのフォーラムをスキャンし、Javaの細かい点でまだ苦労している開発者が何人いるかを見ると、Scalaが主流言語になることは考えられません 。 以前は1週間のJavaコースしか必要としていなかったとき、3週間のScalaコースで開発者を送ることは正当化できません。

Scalaはまったく分かりませんが、数週間前にClojureを読むことができませんでした。今、私はそのほとんどを読むことができますが、最も単純な例を超えて何かを書くことはできません。私はScalaも違うと思う。あなたは学ぶ方法に応じて良い本やコースが必要です。上の地図の宣言を読んだだけで、私はおそらくそれの 1/3 を得ました。

大きな問題は、これらの言語の構文ではなく、日常の生産コードで使用できるようにするパラダイムの採用と内部化です。私にとってJavaは、などパスカルから全く飛躍なかったC、も基本から大きな飛躍ではなかったC ++からの大きな飛躍ではなかった...しかし、Clojureのような関数型言語でコーディングすることである（のための大きな飛躍私とにかく）。Scalaでは、JavaスタイルまたはScalaスタイルでコード化することができます。しかし、Clojureでは、あなたの命令的な習慣をJavaから守るためにかなり混乱を招くでしょう。

私はオックスフォードからも数学の学位を取得しています！新しいコレクションのものを手に入れるのに私はしばらくかかりました。しかし、今私はそれが大好きです。実際、 'map'のタイプは、2.7で私を盗んだ最初の大きなものの1つでした（おそらく最初にコレクションクラスのサブクラスの1つだったので）。

新しい2.8コレクションに関するMartinの論文を読むことは、実際にはimplicitsの使用を説明するのに役立ちましたが、ドキュメント自体は、コアAPIのメソッドシグネチャ内でさまざまな種類のimplicitsの役割を説明するうえで間違いなく必要です。

私の主な関心事はもっとこれです：2.8がリリースされるのはいつですか？バグ報告はいつ来るのでしょうか？彼らは2.8で噛むことができる以上に噛んだスカラーチームを持っている/すぐにあまりにも多くを変更しようとした？

私は本当に2.8の安定版を優先的にリリースしてから、何か新しいものを追加する前に、スカラコンパイラの開発ロードマップの管理方法をいくつか改善できるかどうか疑問に思っています。