Quelles sont les plus grandes différences entre F # et Scala?

F # et Scala sont des langages de programmation fonctionnels qui n'obligent pas le développeur à utiliser uniquement des types de données immuables. Tous deux prennent en charge les objets, peuvent utiliser des bibliothèques écrites dans d'autres langues et s'exécuter sur une machine virtuelle. Les deux langues semblent être basées sur le ML.

Quelles sont les plus grandes différences entre F # et Scala malgré le fait que F # soit conçu pour .NET et Scala pour la plate-forme Java?

— Jonas
source

Si vous pouvez voter et pensez que cette question est utile ou si vous avez des réponses utiles ci-dessous, votez. Les sites StackExchange ont besoin de votes pour créer une bonne communauté. Vous pouvez donner 30 votes par jour, ne les gaspillez pas. En particulier les utilisateurs avec une réputation élevée et des votes de comptage faibles donnés s'il vous plaît lisez ceci: meta.programmers.stackexchange.com/questions/393/…

— Maniero

functional programming langugages that don't force the developer to only use immutable datatypes- Y a-t-il des langues, sauf peut-être des langues de jouets?

— Ingo

@Ingo, si vous pensez que ML et Ocaml ne sont pas qualifiés de langages de programmation fonctionnels car ils permettent la mutabilité, vous devriez peut-être ajuster votre définition!

— Frank Shearar

+ Frank, vous devez avoir mal compris: je veux dire, même Haskell a des types de données mutables. Par conséquent, j'aimerais toujours savoir quelles langues @Jonas a peut-être en tête qui obligerait à utiliser uniquement des types de données immuables?

— Ingo

Réponses:

Différences majeures:

Scala et F # combinent programmation OO-impérative et programmation fonctionnelle dans un seul langage. Leur approche de l'unification des paradigmes est toutefois très différente. Scala essaie de fusionner les deux paradigmes en un seul (nous l'appelons paradigme objet-fonctionnel), tandis que F # fournit les deux paradigmes côte à côte. Par exemple, les types de données algébriques dans F # sont des constructions purement fonctionnelles, sans OO'ness, alors que les ADT dans Scala sont toujours des classes et des objets normaux. (Remarque: lors de la compilation dans le bytecode CLR, même les F # ADT deviennent des classes et des objets, mais ils ne sont pas visibles par le programmeur F # au niveau de la source.)
F # possède une inférence complète de type Hindley-Milner. Scala a une inférence de type partielle. La prise en charge du sous-typage et de pure-OO-ness rend l'inférence de type de type Hindley-Milner impossible pour Scala.
La scala est un langage beaucoup plus minimaliste que le fa #. Scala a un très petit ensemble orthogonal de constructions qui sont réutilisées dans le langage. F # semble introduire une nouvelle syntaxe pour chaque petite chose, devenant ainsi très lourde en syntaxe par rapport à Scala. (Scala a 40 mots-clés, alors que F # en a 97. Cela devrait vous dire quelque chose. :-)
F # étant un langage Microsoft possède un excellent support IDE sous la forme de Visual Studio. Les choses ne sont pas si bonnes du côté de la Scala. Le plugin Eclipse n'est toujours pas à la hauteur. Il en va de même pour le plugin NetBeans. IDEA semble être votre meilleur choix pour le moment, même si cela n’est même pas proche de ce que vous obtenez avec les IDE Java. (Pour les fans d'Emacs, il y a ENSIME. J'ai entendu beaucoup de bonnes choses à propos de ce paquet, mais je ne l'ai pas encore essayé.)
Scala a un système de type beaucoup plus puissant (et complexe) que F #.

Autres différences:

Les fonctions F # sont currys par défaut. En Scala, le currying est disponible mais n'est pas utilisé très souvent.
La syntaxe de Scala est un mélange de Java, Standard ML, Haskell, Erlang et de nombreux autres langages. La syntaxe F # est inspirée de celles de OCaml, C # et Haskell.
Scala prend en charge les types et classes de types supérieurs. F # ne le fait pas.
Scala est beaucoup plus sensible aux DSL que F #.

PS: J'aime à la fois Scala et Fa # et espère qu’ils deviendront les langues prédominantes de leurs plateformes respectives à l’avenir. :-)

— manquantfaktor
source

Cette réponse perpétue plusieurs idées fausses. Je vais énumérer chacun à son tour. Vous avez dit que "les types de données algébriques dans F # sont des constructions purement fonctionnelles sans OO'ness", mais que les types de données algébriques dans F # ne sont que des classes et, en particulier, ils prennent en charge l'augmentation avec des membres et des propriétés d'instance / statique OO.

— Jon Harrop

Vous dites que "Scala essaye de fusionner les deux paradigmes en un seul (nous l'appelons paradigme objet-fonctionnel)" mais Scala manque d'élimination générale des appels de queue et, par conséquent, de tout code fonctionnel non trivial (y compris presque tous les idiomes fonctionnels conventionnels tels que le dépassement continu les nœuds récursifs) sont susceptibles d’empiler les débordements dans Scala et sont donc pratiquement inutiles.

— Jon Harrop

@JonHarrop: Scala ne traite pas spécialement les TDA. Ils sont traités comme des cours ordinaires. Il Some(2)en Scala a type Some[Int]et non Option[Int]ce qui est indésirable OMI. D'autre part, F # a une syntaxe et un traitement spéciaux pour les ADT, et peut donc déduire correctement le type de Some 2as int option. Le codage en F # des ADT est donc meilleur que celui de Scala (IMO, bien sûr). Je n'ai pas essayé de laisser entendre que c'était inférieur, et je suis désolé si cela se passait ainsi.

— missingfaktor

@JonHarrop: Le manque de coût total de possession dans la JVM n'a pas gêné beaucoup de développeurs Scala. Croyez-moi, ce n'est pas un problème aussi grave que vous semblez le penser. La plupart du temps, nous utilisons des fonctions d'ordre supérieur, au lieu d'une récursion explicite. Et la plupart des fonctions d'ordre supérieur dans Scala sont implémentées en termes de boucles et non de récursivité. Ainsi, le manque de coût total de possession devient presque immatériel.

— missingfaktor

J'ai l'impression que toute cette réponse est un peu biaisée en faveur de Scala. Par exemple, Scala est un langage beaucoup plus minimaliste que F # qui semble aller à l’encontre de son argument / point ultérieur d’un système de types plus complexe.

— Adam Gent

F # est réglé sur des aspects fonctionnels tandis que scala est basé sur des aspects orientés objet.
F # supporte mieux l'IDE avec Visual studio alors que le plug-in eclipse de Scala est destiné à l'IDE open source et est relativement plus lent.
F #, étant plus semblable à ML que Scala, a plus de sensations lambda-calcul minimales qu’il en est avec OCaml, Standard ML et Scheme. F # semble être un langage considérablement plus simple.

— Ayush Goyal
source

"F # semble être un langage considérablement plus simple." << Non, ce n'est pas. C'est beaucoup plus grand que Scala. Je devrais écrire un article sur ce sujet quelque temps.

— missingfaktor

"Scala est basé sur des aspects orientés objet." << Mauvais. Scala tente de fusionner la programmation POO ET fonctionnelle. Personnellement, j'utilise très rarement ses fonctionnalités orientées objet. La plupart de ce que nous faisons est purement fonctionnel.

— missingfaktor

@missingfaktor: "C'est beaucoup plus grand que Scala". Quelle est la taille des grammaires?

— Jon Harrop

Je ne sais pas si les choses ont changé. Scala dans IntelliJ Rock, avec le plugin encore open source.

— Colliot

La licence est un petit point important: Scala est BSD (la licence de logiciel libre la plus permissive qui soit), F # était autrefois "un contrat de licence Microsoft Research Shared Source" mais est un produit commercial de nos jours (selon @Lorenzo ci-dessous, bien que je n’aie pu trouver d’accord de licence plus précis nulle part).

— Joonas Pulakka
source

En fait, F # est maintenant open source et Scala est maintenant un produit commercial de la société Scala Solutions de Martin Odersky.

— Jon Harrop

@Jon Harrop: Je pense que Scala Solutions vend uniquement des outils, des services, des formations, etc. liés à Scala. Le langage lui-même semble toujours être sous licence BSD.

— Joonas Pulakka

@Joonas: Il en va de même pour F #.

— Jon Harrop

@JonHarrop: Scala reste une source ouverte. S'il vous plaît, ne répandez pas de désinformation.

— missingfaktor

@missingfaktor: Je n'ai pas dit que Scala était une source fermée.

— Jon Harrop