F＃とScalaの最大の違いは何ですか？

F＃とScalaはどちらも関数型プログラミング言語であり、開発者が不変のデータ型のみを使用することを強制しません。どちらもオブジェクトをサポートしており、他の言語で記述されたライブラリを使用して、仮想マシンで実行できます。どちらの言語もMLに基づいているようです。

F＃は.NETとJavaプラットフォーム用のScala向けに設計されているという事実にもかかわらず、F＃とScalaの最大の違いは何ですか？

— ジョナス
ソース

投票して、これが有用な質問であると思う場合、または以下に有用な回答がある場合は、投票してください。StackExchangeサイトは、優れたコミュニティを構築するために投票が必要です。1日に30票を投じることができます。無駄にしないでください。特に評価が高く、投票数が少ないユーザーは、こちらをお読みください。meta.programmers.stackexchange.com

— 393

functional programming langugages that don't force the developer to only use immutable datatypes-おもちゃの言語を除いて何かありますか？

— インゴ

@ Ingo、MLとOcamlが可変性を許容するために関数型プログラミング言語として適格でないと思われる場合、定義を調整する必要があるかもしれません！

— フランクシェラー

+率直に言って、あなたは誤解しているに違いありません：つまり、Haskellでさえ可変データ型を持っています。したがって、@ Jonasが不変のデータ型のみを使用することを強制する可能性があることを念頭に置いている言語をまだ知りたいですか？

— インゴ

回答:

主な違い：

ScalaとF＃はどちらも、オブジェクト指向命令型プログラミングと関数型プログラミングを1つの言語に結合します。しかし、パラダイムの統一に対する彼らのアプローチは大きく異なります。Scala は2つのパラダイムを1つに融合しようとします（オブジェクト機能パラダイムと呼びます）が、F＃は2つのパラダイムを並べて提供します。たとえば、F＃の代数データ型は、オブジェクト指向のない純粋に機能的な構造体ですが、ScalaのADTは通常のクラスとオブジェクトです。（注：CLRバイトコードへのコンパイルの過程で、F＃ADTでさえクラスおよびオブジェクトになりますが、ソースレベルではF＃プログラマには見えません。）
F＃には、完全なHindley-Milnerスタイルの型推論があります。Scalaには部分的な型推論があります。サブタイピングと純粋なオブジェクト指向性のサポートにより、Hindley-Milnerスタイルの型推論がScalaで不可能になります。
ScalaはF＃よりもはるかにミニマルな言語です。Scalaには、言語全体で再利用される非常に小さな直交構造のセットがあります。F＃はあらゆる小さなものに新しい構文を導入するようであるため、Scalaと比較して構文が非常に多くなります。（Scalaには40のキーワードがありますが、F＃には97があります。それは何かを伝えるはずです。
Microsoft言語であるF＃は、Visual Studioの形式で優れたIDEをサポートしています。Scala側では物事はそれほど良くありません。Eclipseプラグインはまだ限界に達しています。NetBeansプラグインについても同様です。IDEAは現時点では最善の策であるように見えますが、Java IDEで得られるものには近づきさえしていません。（EmacsファンにはENSIMEがあります。このパッケージについて多くの良いことを聞いたことがありますが、まだ試していません。）
Scalaには、F＃よりもはるかに強力な（そして複雑な）型システムがあります。

その他の違い：

F＃関数はデフォルトでカリー化されています。Scalaでは、カリー化は使用できますが、あまり頻繁には使用されません。
Scalaの構文は、Java、標準ML、Haskell、Erlang、および他の多くの言語の構文を組み合わせたものです。F＃構文は、OCaml、C＃、およびHaskellの構文に触発されています。
Scalaはより高い種類と型クラスをサポートしています。F＃はサポートしていません。
ScalaはF＃よりもDSLにはるかに適しています。

PS：ScalaとF＃の両方が大好きで、将来それぞれのプラットフォームの主要言語になることを願っています。:-)

— 行方不明の
ソース

この答えは、いくつかの誤解を永続させます。それぞれを順番に列挙します。「F＃の代数データ型は、オブジェクト指向のない純粋に機能的な構造体」とおっしゃいましたが、F＃の代数データ型は単なるクラスであり、特に、OOインスタンス/静的メンバーとプロパティによる拡張をサポートしています。

— ジョンハロップ

「Scalaは2つのパラダイムを1つに融合させようとします（オブジェクト機能パラダイムと呼びます）」と言いますが、Scalaには一般的なテールコールの除去がなく、その結果、非自明な機能コード（継続渡しなどのほぼすべての従来の機能イディオムを含む）スタイルと再帰的な結び目を解く）は、Scalaでオーバーフローをスタックする傾向があるため、実際には役に立たない。

— ジョンハロップ

@JonHarrop：ScalaはADTを特別に扱いません。通常のクラスと同様に扱われます。Thereofre Some(2)Scalaの中には、型を持つSome[Int]とないOption[Int]IMO好ましくない。一方、F＃にはADTの特別な構文と処理があるため、Some 2asの型を正しく推測できint optionます。そのため、ADTのF＃エンコーディングはScalaのエンコーディングよりも優れています（もちろん、IMO）。私はそれが劣っていることをほのめかそうとしませんでした。

— missingfaktor

@JonHarrop：JVMのTCOの欠如は多くのScala開発者を悩ませていません。私を信じてください、それはあなたが考えているほど大きな問題ではありません。ほとんどの場合、明示的な再帰ではなく、高階関数を使用しています。また、Scalaのほとんどの高階関数は、再帰ではなくループの観点から実装されています。そのため、TCOの不足は重要ではなくなります。

— missingfaktor

この答え全体がScalaに少し偏っていると感じます。たとえば、ScalaはF＃よりもはるかにミニマルな言語であり、より複雑な型システムの彼の議論/後のポイントに反するようです。

— アダム・ゲント

F＃は機能的な側面に基づいていますが、scalaはオブジェクト指向の側面に基づいています。
F＃はVisual Studioでより優れたIDEをサポートしていますが、 ScalaのeclipseプラグインはオープンソースIDE用であり、比較的低速です。
F＃は、ScalaよりもMLに似ていますが、OCaml、Standard ML、およびSchemeのように、最小限のラムダ計算の感覚があります。F＃はかなり単純な言語のようです。

— アユシュ・ゴヤル
ソース

「F＃はかなり単純な言語のようです。」<<いいえ、そうではありません。Scalaよりもずっと大きいです。このテーマに関する記事をしばらく書く必要があります。

— missingfaktor

「Scalaはオブジェクト指向の側面に基づいています。」<<間違っています。Scalaは、OOPと関数型プログラミングの融合を試みます。個人的には、オブジェクト指向機能をほとんど使用しません。私たちが行うことのほとんどは、純粋に機能的です。

— missingfaktor

@missingfaktor：「Scalaよりもずっと大きい」。文法の大きさは？

— ジョンハロップ

状況が変わったかどうかはわかりません。IntelliJのScalaは、プラグインがまだオープンソースである点で優れています。

— コリオ

小さいけれど重要な点の1つはライセンスです。ScalaはBSD（最も寛容なフリーソフトウェアライセンス）であり、F＃は「Microsoft Research Shared Sourceライセンス契約」でしたが、現在は商用製品です（以下の@Lorenzoによると、より具体的なライセンス契約はどこにも見つかりませんでしたが）。

— ジョナス・プラッカ
ソース

実際、F＃は現在オープンソースであり、ScalaはMartin Oderskyの会社Scala Solutionsの商用製品です。

— ジョンハロップ

@Jon Harrop：Scala SolutionsはScala関連のツール、サービス、トレーニングなどを販売しているだけだと思います。言語自体はまだBSDライセンス下にあるようです。

— ジョナスプラッカ

@Joonas：まさに、F＃についても同じことが言えます。

— ジョンハロップ

@JonHarrop：Scalaはオープンソースのままです。誤報を広めないでください。

— missingfaktor

@missingfaktor：Scalaがクローズドソースであるとは言いませんでした。

— ジョンハロップ