ScalaはJavaよりも悪いです。 Javaプロジェクトの少なくとも半分

そのため、私の投稿（ バージニア州、はい、Scalaは複雑です！ ）で、ほとんどのJava開発者にとってScalaは複雑すぎることに同意しました。 その投稿は多くの議論を引き起こし、そのほとんどがその意味を歪めました。 今、私はもう一度書いています。私が実際に話したことと、なぜこれがすべて必要なのかを明確にしたいと思っています。



しかし、最初に私について。 私の名前はデビッド・ポラックです。 2006年11月からScalaコミュニティの積極的なメンバーになっています。 私はLiftプロジェクトの創設者です。

言及する価値があるいくつかのより重要な点：

• 私はEPFL以外の誰よりも長い間Scalaコードを継続的に書いています（おおよそ、Scalaはローザンヌ工科大学で開発中です）。 [更新- @propensiveとBill Wennersは、私より長い間Scalaコミュニティに参加しています。]
• 2008年に最初のScalaカンファレンス、 Scala Lift Offを開催し、今日も開催し続けています。
• 地球上の誰よりも多くのコード行をScalaで書きました（250K以上）。
• 人気のある本、Scalaの紹介：Beginning Scalaを書きました。
• 過去5年間、ScalaとLiftに直接関連するトピックについて、ScalaとLiftのフォーラムで10,000回以上執筆しています（これは、膨大な数の開発者と話をしたことを示唆しています）。
• Lift Webフレームワークプロジェクトを設立し、コアAPIの設計など、その重要な部分を書きました。 Liftは、最も人気のあるScalaベースのフレームワークの1つであり、最初に広く知られている Scalaライブラリです。
• 過去1年間にScalaで50万行以上のコードをレビューしました。
• 私は主にScalaとLiftのコンサルティングで生計を立てており、多くのプロジェクトに積極的に参加しています。
• 過去5年間でScalaとLiftについて25を超えるプレゼンテーションを開催しました。
• 小さなチームでScalaとLiftを使用する方法を数百人に教えました。
• TypeSafeホームページに掲載されている消費者の半数以上（およそ、Per。Xerox 、Siemens、Sony、その他のクジラ ）に、直接的または間接的にScalaを代表しました。

上記のすべてを要約すると、「Scalaでのコーディング、Scalaの指導、さまざまな人々や組織へのScalaのプレゼンテーションでかなりの経験があります。 「Scalaを使用している、またはScalaの成功要因を分析するために大量のデータを蓄積するためにこれを行うことを計画している十分な人々と話しました。」 これは、私が正しいと信じているという意味ではなく、他のすべての人が間違っているということです。 しかし、これは、それにもかかわらず、個性への移行を議論としてレトリックを使用する人々は、この議論に重みがないことを示唆しています。 [更新： fogusの投稿を読んだ後...私はそれを誤解しました。 霧と私は同じ結論に達しました。 私はそれが究極の真実であると宣言するのではなく、自分の意見のままです。 しかし、 フォグスの剛性と彼の投稿について謝罪します！]



この準備をすべて終えた後、結論を述べさせてください。

• Scalaは、ほとんどのJava開発者にとって不適切な言語であり、Javaの代替と見なすことはできません。Java開発者の少なくとも半数にとって、Scalaの複雑さはその強みを打ち消すからです。

この声明は、以下よりも議論の余地はありません。

• JavaはほとんどのPHP開発者にとって不適切な言語であり、PHP開発者の少なくとも半数にとってJavaの複雑さがそのメリットを否定するため、PHPの代替と見なすことはできません。

以前の投稿で「Scalaは一部の開発者にとって難しい」と言っていましたが、今回はもっと具体的に説明します。 Scalaが複雑だと言っているわけではありません。 しかし、私はScalaが複雑な多くの開発者に会い、彼の推論をこことここで紹介しました 。 このクラスの開発者にとって、Scalaのコストはその利点を上回ります。

議論

私が特に苦手なことの1つは、スペルです。 私の脳は言葉のつづりを覚えていないだけです。 私が学生新聞の編集者だったとき、ジャーナリストの1人が、怠け者だけがスペルを知らないというフレーズを私の顔に投げました（それは1985年...スペルチェッカーの前でした）。 積分をチョークボードに書き（これはホワイトボードの前にありました）、解決するように依頼しました。 彼女は言った：「これは数学です...それは複雑です...そして私はスペルのような単純なことについて話しているのです。」 まあ、私にとって、私は夢の中で積分を解くことができます、そして、たとえ私の人生がそれに依存していても、私は単語を正しく綴ることができません。 人によってスキルは異なります。



人によって価値は異なります。 コンピューターを愛し、コードを書くのが大好きな人たちがいます。 私はその中にいます。 そして、お気に入りのアクティビティのトップ5にプログラミングを入れない人たちがいます。



ソフトウェア開発のキャリアを選んだプログラマーはたくさんいますが、生来の能力と欲望の組み合わせを持っていません。 これらの能力を開発し、モチベーションを提供する学校があります。 しかし、ブログや自慢はそれを変えることはできません。

生まれつきのコーディング能力と個人の成長に興味がない人にとって、Scalaは面倒です。 そして、Scalaにそのような負担が多すぎる場合（読み取り-失敗したScalaプロジェクト）、Scalaは成長を停止します。これは、$ 600,000を超える投資をした私のような人々にとって深刻な準最適な状況（概算です。 Scalaエコシステムに。 投稿の最後に動機付けについて詳しく説明します。



私のバージニア州の投稿に対する重要な議論の1つは、すべてのJava開発者をそのまま使用するべきだということでした。 私は自分自身を引用します：

• 「では、最高のプログラマーを見つけましょう」という議論を拒否します。開発者の全体的な品質を向上させることでScalaの複雑さの問題を解決できました（タイプシグネチャを理解している人、プログラムを数学的に説明できるなど）問題は、Scalaがトレーニング、教育、採用に革命を引き起こすほど良くないため、平均的な開発者の質を変えて、この開発者がアクセスできるようにすることです。

Scalaを学ぶことができるとPaul Snivelyに同意します。 だからこそ、私は長年Scalaを積極的に宣伝してきました。 問題は、Scalaが特定の種類の人々によって研究されていることです。 このビューには、学習したくない人やこれを行う能力のない人は含まれていません（PHPでコードを書くことはできますが、Javaでプログラミングできない人がいるように）。



私が話していることの本質は、 Scalaが適さないクラスのプログラマーがいるという事実であり、私はほぼ4年間、それについて話してきました...おそらくもっと長いですが、これは私が見つけることができる最も古い投稿です。 その時点での私の立場は、Scalaに切り替えると生産性が低下する開発者のトレーニングと解雇という、今日の多くの人たちとあまり変わりません。 さらに、少なくとも過去3年間Scalaで作業できなかった純粋なJavaプログラマーのグループがあることは、私にとって非常に明白です。 このように、私の立場はここ何年も変わっていません。



私の理解が変わったのは、プログラマーが就業日の初めに現れ、数回の会議に参加し、数行のコードを書いて帰宅する企業が非常に多いことに気づいたことです。 過去1年間、このタイプの3つの会社で働いた経験があります。 Scalaで書き直されたJavaコードの問題、開発者の検索、社内の内部抵抗などにも関わらず、Scalaを実装し、懸命に戦い、すべてを正しく行おうとします。 他の人は、Scalaを実装しないことに決めます（マニュアルでは知らないScalaコードがいくつかありますが、このコードは、ScalaがJavaよりはるかに優れている1人の人によってサポートされています）。 さらに、開発者の半分を交換し、残りの25％を高価なコースに送信し、プロジェクトの一部を外部委託することを拒否する組織コストが、Scalaがチームの3人の最高のプログラマーに与えるすべての利点を上回るため、ScalaからJavaに戻ることを決めました。



私たちは、平均的な開発者が年間3250行 （1日あたり約20 行）のコードを書く世界に住んでいます。 これは、開発環境によって提案された場所でコードを置換して「give me the X template」ボタンをクリックすることにより、Eclipseで発生します。 その後、いくつかの集会への旅行。 そして彼らはそれを営業日と呼んでいます。 これらすべての開発者を解雇することはできません。 私たちは彼らがより良くなるように訓練することはできません。 これは中間の農民です。 これらの開発者は、ディルバートに関する漫画のヒーローになることができます（およそ。オフィスプランクトンに関するユーモラスなテープごと）。 しかし、あなたは何を知っていますか？ これらはまさにJavaを使用する人たちです。 他に何を知っていますか？ そのようなプログラマーには、生まれつきの能力と良くなるという願望の同じ組み合わせはありません。 しかし、これはそれだけではなく、プログラマーに対する管理のチェーン全体が状況を変える能力も意志も持っていません。 私たちはこの山を移動することはできません...または、より具体的には、Scalaは生産性の低い開発者の50％を却下するほど良くありません。

したがって、最適な方向と動きは次のとおりです。

• 3倍効率的なプログラマーとプロジェクトに焦点を当て、Scalaを使用してください。 または;
• 中年のプログラマー向けにScalaを改善する（これは、Scalaが革新的な研究言語になるまで起こりません）

やる気

「だから何だ？」と尋ねます。「Scalaが成功しておらず、困難でもないことを証明するためにたくさん書きましたか？」



ほぼ5年前にこの言語に出会って以来、私はScalaのサポーターおよびファンでした。 Scalaに引っ越して来て、私より長く彼女と一緒に仕事をしている人はほんのわずかです。 私は、成功し続けるためにScalaとLiftに強い関心を持っています。



また、Scalaにはいくつかの素晴らしい成功事例があります。 引用と記事、そしてScalaの周りで何か珍しいことの一般的な感覚-これはすべて深刻であり、すべてこれに値する。 Scalaは素晴らしい言語です。 シンプルで日常的なものから最も複雑なものまで、幅広いタスクを解決するための普遍性という点で、現代のプログラミングでは同等の言語ではありません。



しかし、Scalaは万能薬ではありません。 Scalaは、優秀なプログラマーを雇った場合にのみ成功します。 このようなプログラマーは、Scalaを使用して、Javaや他のほとんどの言語での作業と比較して、能力を高めることができます。 しかし、経験の浅い人、さらに悪いことに、Scalaに満足していない人の手では、ScalaはJavaよりも悪くなります。 これは、チームの争いと競合につながり、このタイプのチームは多くの場合受動的で攻撃的であるため、締め切りに間に合わず、最終的にはプログラミング言語が責任を負うことになります。



Scalaが成長を続けるためには、成功し続ける必要があり、最小限の問題のあるプロジェクトをそれに関連付けなければなりません。 これは、ScalaとLiftに適切なアプリケーションを選択するために、 Scalaの長所と短所について話すときに、率直で正直でなければならないことを意味します。 Scalaの成長のためには、Scalaで素晴らしいものを作成するスキルと欲求の適切な組み合わせを持っているまさにそのタイプのプログラマーに提供される必要があります。

Scalaは、コマンドラインユーティリティ、CRUD、およびデータベースフロントエンドでJavaを置き換えるものではないことを受け入れる必要があります。 ORMを書くためのScalaの力（ごめん、Max ... Squerylは本当にクールです）は、リアルタイムシステム、分散、並列アプリケーションの開発のためのScalaの価値よりもはるかに低いです。 ただし、ほとんどの場合、ORM、CRUD、ユーティリティ、およびその他のデータをfill-form-and-save-in-styleのスタイルで実行します。 それはほとんどの開発者がいる場所であり、お金はどこにあります。 タフな男たちは巨大でファジーで、イベント駆動型で、メガハイパー、スーパー、スーパー、リアルタイム、スーパー、ブラーブラーを開発していますが、ほとんどのプログラマーは、データベースからデータを移動したり、Oracle / SQLは、これに最適なメカニズムを提供します。



コミュニティとして、Scalaの弱点を受け入れなければなりません。 Scalaを利用する開発者を引き付ける必要があります（多くの開発者がいます）。 また、実際に失敗する可能性がある場合、Scalaの使用を積極的に阻止する必要があります。 「Scala is complex」または「Scala for really good Programmers」というブランドは、「Scalaは時々失敗につながるリスクです」よりもはるかに優れています。



この投稿を書いた私の動機は、開発者の頭の中に私が言ったことの認識を植え付けたいという願望でした。 来年、Scalaで5,000の新しいプロジェクトが見られ、そのうち4,000が成功すると、50,000の新しいプロジェクトが見られ、そのうち10,000だけが成功します。 Scalaの能力と傾向を備えたプログラマーは、言語の実験に成功した後、おそらく私の投稿を読んで、私が何を話しているのかわからないと言うでしょう。 他の開発者は結論を繰り返し（「岩は複雑すぎます」）、それを使用しません。 そして、そのような結果はScalaを成功に導く可能性がはるかに高いです。 それが完了するまで、それは中間の小作人にアクセス可能になります。 これはScalaとLiftにとって最良の方法です。



ああ...そして、すべて、あなたが境界を押し広げている怒っている賢い人々（または私は彼らがすぐに押すと確信しています）、メガイベント駆動のリアルタイムギズモで、あなたはScalaが実現した夢であることがわかります、それと似たものはありません（Haskellを除く）。 だから、Scalaでクールなものを作成して、それがうまくいくようにしてください。