はい、ヴァージニア、Scalaは複雑です！

まず、私が5年間Scalaの素晴らしいファンであり、サポーターであることを明確にしましょう。 Scalaに関する本や記事を書いています。 また、ScalaとLiftの使用を開始した多くの企業と協力し、膨大な数のScalaプロジェクトのコードレビューを実施しました。 以前は、Scalaは簡単だと思っていました。 これは、多くのJavaの問題の解決策であり、現在も継続しています。 「Javaの複雑な、または不可能なことさえもScalaで非常に単純です」という点では、Scalaは非常に単純な言語です。 コレクションの操作は非常に簡単です。 ビジネスロジックの分離により、プログラムはJavaで作成された場合よりもはるかにサポートされ、信じられないほど簡単になります。
では、なぜScalaは複雑なのでしょうか？ ここに私が思いつく最高のものがあります：

• Scalaはやりすぎています。 これは、Javaスタイルのコードを書き続けることができることを意味します。これは、呪いであり祝福でもあります。 しかし、長期的には、それはまだ呪いだと思います。 オブジェクト指向とFPのコントラストについては、あまりにも多くの議論があります。 このような議論は、あなたが小さなチームであれば受け入れられますが、Scala Javaの書き方を学ぼうとするとき、ひどく悪いです-実際に学習したり変更したくない開発者。 Scalaの驚くべき利点は、FPスタイルで書くと実際に現れ始めますが、オブジェクト指向開発者が独自のスタイルで書きたいと思うまで、OO開発者を引き付けることはほとんど不可能です。 この場合、JavaやRubyなどの言語機能が少なくなり、適応が容易になり、潜在的なソリューションの範囲が絞り込まれます。
• IDEからの貧弱なサポート（常にそうです）。 ScalaのEclipseプラグイン（または今週のScalaと呼ばれるもの）はがらくたです。 彼は、Scalaでの私の5年間の仕事を続けています。 常に「良くなる」と聞いていますが、それでも下手です！ IntelliJによるScalaのサポートは受け入れられます。 しかし、IDEでテンプレートを必要とする人は、Scalaのサポートが十分でないことに気付かないでしょう。 まず、Scalaのテンプレート/パターンは非常に多様で断片化されているため（ミックスによるオブジェクト指向はScalaZの方法です）、本当に信じられないほどの量があります。 Emacs、Vi、またはTextMateでコードを正常に記述した場合、すべてが正常に行われ、IntelliJへの移行がうまくいくように見えます。 しかし、Java IDEから得られるものと同様の「善意」を期待する場合、Scalaの総合的な力のために夢は壊れ、実現することはありません。 また、アカウントに300万人いるTypesafeでさえ、これを保証することはできません。
• Scala型システムは非常に強力ですが、あなたの観点からは、多すぎるかもしれません。 ScalaDocsでは、一部の署名は非常に威圧的に見えます。 見てみましょう
  

  flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That 

  
  そして今、それはあなたの心を吹き飛ばさなかったと私に言ってみてください。 初心者は毎日この方法を使用し、1日に20回使用することもあります。 Scalaのドキュメントには、この複雑さをすべて隠すライブラリが必要です。 flatMapメソッドを非常に強力にする複雑さ。 型システムと関連ドキュメントには、よりシンプルで使いやすい表示モードが必要です。
• より経験豊富なプログラムをサポートする必要がある初心者開発者は、コードのイディオムとパターンを理解する必要があります。 Scalaはビジネスロジックを最前線に持っているという事実にもかかわらず（多くのforループや複雑なif式を介して拡散するのではなく）、使用されているイディオムによっては、コードはまだ明白で読みにくいです。 そして、1日の終わりに、チームに参加して、Scalaによって記述されたコードと、使用されたすべてのテクニックについて議論することをお勧めします。 これはRuby on Railsにも当てはまります。Rubyon Railsでは、ハッシュマップがすべてのプログラミングパラダイムを事実上置き換えることができます。 しかし、Railsの世界では、パラダイムは統一されており（型チェックに基づくものではありません）、読みやすいです。 Javaでは、同じパターンがすでにIDEに埋め込まれているため、開発者は「成長中」にそれらを学習し、定義できるようになります。 しかし、残念なことに、このアプローチはScalaに存在する場所がなく、チームや使用するフレームワークに応じてあまりにも多様なイディオムがあります。

Java、Ruby、または他の言語よりも間違いなくScalaが優れたオプションであるいくつかのタイプのコマンドがあります。 Twitterは素晴らしい証拠です。 明確で、タイプセーフで、高性能な言語と環境が必要です。 そして、Scalaはそれらすべてを提供しました。 Foursquareは、フィルタリングメカニズムにScalaの複雑さを使用しています。 Scalaを習得し、Foursquareで成功するには、十分な能力が必要です。
しかし、平均に近いスキルを持つチームがある場合、Scalaは最良の選択ではないかもしれません（管理に依存します...チームをフィルタリングおよび改善するためにScalaの難しい特性を使用する必要がありますか？）トレーニングの観点から、Scalaは既存の開発者、パターンの欠如を放棄する費用がかかります。 パターンを設計するには、本やIDEから隔離するのではなく、強力なCTOまたはアーキテクトが必要です。 控えめに言っても、かなり強力なテクニカルディレクターまたはアーキテクトを擁するこのような中規模企業の数は少数です。
それで、Scalaがあなたの組織に簡単に適応できるかどうかをどのように見つけますか：

• あなたの会社にはJavaOne、OSCON、Strange Loop、QConのスピーカーがいます-Scalaは簡単です
• 開催中のディスカッションには、通常の開発者からシニアに移行するための基準が含まれています-Scalaは難しいでしょう
• 必要に応じて、開発者はメモ帳でコードを記述できます-シンプル
• 開発者は無関心であるか、「Zed Shaw」という名前を聞いたときに3つの「Hail Marys」と言います。Scala== Hard
• 開発者の投票はTwitterのDean Wamplerでフォローしています：Scalaはシンプルです
• あなたの開発者は9.15に働きに来て、メールをチェックせずに6時まで去ります-難しい

もちろん、あなたはこの主題についてあなた自身の考えを持っているかもしれません。 しかし、私はScalaが平均的なチームにとって複雑であるという声明に間違いなく同意します。 そして、それは複雑なだけでなく、近い将来にも将来的にも利点をもたらさないかもしれません。 95％のスキルを持つ参加者で構成されるチームをもたらすことができるもの。
そして、さらにいくつかの考え：

• はい、Scalaの型システムは非常に強力であり、Scalaコレクションのようにコードの美しさを高めることができます。
  stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-the-the-longest-suicide-note-in-histoおよびwww.scala-lang.org/docuをご覧ください/files/collections-api/collections-impl.html
  しかし、言語/ライブラリ設計者と中規模開発者のニーズには違いがあります。 また、Scalaにこのような分離がないため、Scalaには困難が伴います。 個人的に、私はLiftでアイデアを他の言語でこれほど明確かつ強力に表現できるとは思いません。 したがって、ライブラリデザイナーとして、私はScalaが大好きです。 しかし、私のように、Scalaを難しいと思わない人の多くは、普通の人ではありません。 また、Scalaについて書いている11歳の子供も途中ではありません。
• はい、「シンプル」および「アーキテクチャ」表示を提供するScalaDocsの改善は大きな勝利になる可能性があります。 しかし、これはまだ出発点にすぎず、終わりではありません。
• 「優れた、そしてより専門的な開発者を見つける」という議論を明確に拒否します。 「Scala is hard」の問題を解決するには、開発者全体の能力を向上させるよう努力する必要があります（タイプシグネチャを読み取れる人、数学的なアプローチを使用してプログラムを表現できる人など）。しかし、本質からは距離を置いています。 そして、最終的には、Scalaはトレーニング、教育、または雇用の革命を開始するのに適していないということです。それは、彼にとって難しいことをやめるために、平均的な開発者のプロ意識を高めるためです。
• この記事や私のTwitterを読んでいる人は誰でも平均的な開発者であり、Paul Snivelyだとは思えません。