Quels sont les avantages d'utiliser C # vs F # ou F # vs C #?
Je travaille pour une entreprise de technologie qui fait plus de prototypage que d’expédition de produits. On vient de me demander quelle est la différence entre C # et F #, pourquoi MS a-t-il créé F # et quels scénarios serait-il meilleur que C #?.
Cela fait un moment que j'utilise le langage et j'adore le faire afin de pouvoir parler des fonctionnalités intéressantes de F #, mais je manque d'expérience en C # pour dire pourquoi nous devrions utiliser l'un plutôt que l'autre.
Quels sont les avantages d'utiliser C # vs F # ou F # vs C #?
Avantages généraux de la programmation fonctionnelle par rapport aux langages impératifs:
Vous pouvez formuler beaucoup de problèmes beaucoup plus facilement, plus près de leur définition et plus concis dans un langage de programmation fonctionnel tel que F # et votre code est moins sujet aux erreurs (immuabilité, système de type plus puissant, algorithmes récursifs intuitifs). Vous pouvez coder ce que vous voulez dire au lieu de ce que l’ordinateur veut que vous disiez ;-) Vous trouverez beaucoup de discussions de ce type lorsque vous le recherchez sur Google ou même le recherchez à l’aide de SO.
Spécial F #-avantages:
La programmation asynchrone est extrêmement simple et intuitive avec
async {}_ expressions - Même avec ParallelFX, le code C # correspondant est beaucoup plus grandIntégration très facile des compilateurs de compilateur et des langages spécifiques à un domaine
Étendre la langue selon vos besoins: LOP
Syntaxe plus souple
Des solutions souvent plus courtes et plus élégantes
Regardez ce document
Les avantages du C # sont qu’il est souvent plus précis qu’un langage de programmation fonctionnel pour les applications "impératives" (interface utilisateur, algorithmes impératifs), que le .NET-Framework qu’il utilise est conçu de manière impérative et qu’il est plus répandu.
De plus, vous pouvez combiner F # et C # dans une solution unique, ce qui vous permet de combiner les avantages des deux langues et de les utiliser à la demande.
C'est comme demander quel est l'avantage d'un marteau sur un tournevis. À un niveau extrêmement élevé, les deux font essentiellement la même chose, mais au niveau de la mise en œuvre, il est important de sélectionner l'outil optimal pour ce que vous essayez d'accomplir. Il existe des tâches difficiles et longues en c # mais faciles en f # - comme essayer d’enfoncer un clou avec un tournevis. Vous pouvez le faire, c'est sûr - ce n'est tout simplement pas idéal.
La manipulation des données est un exemple que je peux personnellement indiquer là où f # brille vraiment et où c # peut potentiellement être difficile à manier. D'un autre côté, je dirais (d'une manière générale) que l'interface utilisateur à états complexe est plus facile dans OO (c #) que fonctionnel (f #). (Certaines personnes seraient probablement en désaccord avec cela depuis il est "cool" en ce moment de "prouver" à quel point il est facile de faire n'importe quoi en fa #, mais je m'en tiens à cela). Il en existe d'innombrables autres.
- F # a une meilleure performance que C # en math
- Vous pouvez utiliser des projets F # dans la même solution avec C # (et appeler de l'un à l'autre)
- F # est vraiment bon pour la programmation algorithmique complexe, les applications financières et scientifiques
- F # est logiquement très bon pour l'exécution parallèle (il est plus facile de faire exécuter le code F # sur des cœurs parallèles que C #)
Pour répondre à votre question telle que je la comprends, pourquoi utiliser C #? (Vous dites que vous êtes déjà vendu sur F #.)
Tout d'abord. Ce n'est pas juste "fonctionnel versus OO". C'est "Fonctionnel + OO versus OO". Les fonctionnalités de C # sont plutôt rudimentaires. F # ne sont pas. Pendant ce temps, F # exécute presque toutes les fonctionnalités de C # OO. Dans la plupart des cas, F # finit par être un sur-ensemble de la fonctionnalité de C #.
Cependant, il existe quelques cas où F # peut ne pas être le meilleur choix:
Interop. Il y a beaucoup de bibliothèques qui ne vont tout simplement pas être trop à l'aise avec F #. Peut-être exploitent-ils certains C # OO choses que F # ne fait pas de même, ou peuvent-ils s’appuyer sur les composants internes du compilateur C #. Par exemple, Expression. Vous pouvez facilement transformer une citation F # en En tant qu’expression, le résultat n’est pas toujours exactement ce que C # créerait, ce qui pose problème à certaines bibliothèques.
Oui, l'interopérabilité est un très gros réseau et peut entraîner des frictions avec certaines bibliothèques.
Je considère interop pour inclure également si vous avez une grande base de code existante. Cela n’a pas de sens de commencer simplement à écrire des parties en fa #.
Outils de conception. F # n'en a pas. Cela ne veut pas dire que ne pouvait pas en avoir, mais pour l'instant, vous ne pouvez pas créer une application WinForms avec F # codebehind. Même là où il est pris en charge, comme dans les pages ASPX, vous n’obtenez pas actuellement d’IntelliSense. Vous devez donc examiner avec soin les limites de votre code généré. Sur un très petit projet qui utilise presque exclusivement les différents concepteurs, il ne vaut peut-être pas la peine d'utiliser F # pour la "colle" ou la logique. Sur des projets plus importants, cela pourrait devenir moins un problème.
Ce n'est pas un problème intrinsèque. Contrairement à la réponse du Rex M, je ne vois rien de intrinsèque à C # ou à F # qui les incite à faire mieux une interface utilisateur avec beaucoup de champs mutables. Peut-être qu'il faisait allusion à la surcharge supplémentaire d'avoir à écrire "mutable" et à utiliser <- au lieu de =.
Cela dépend également de la bibliothèque/du concepteur utilisé. Nous aimons utiliser ASP.NET MVC avec F # pour tous les contrôleurs, puis un projet Web C # pour obtenir les concepteurs ASPX. Nous mélangeons le "code en ligne" ASPX actuel entre C # et F #, selon ce dont nous avons besoin sur cette page. (Types IntelliSense versus F #.)
Autres outils Ils attendent peut-être uniquement C # et ne sachent pas comment gérer les projets F # ou le code compilé. De plus, les bibliothèques de F # ne sont pas fournies avec .NET, vous avez donc un peu plus à offrir.
Mais le problème numéro un? Gens. Si aucun de vos développeurs ne veut apprendre le F #, ou pire, a de la difficulté à comprendre certains aspects, alors vous êtes probablement grillé. (Bien que, dans ce cas, je dirais que vous portez un toast de toute façon.) Oh, et si la direction dit non, cela pourrait poser problème.
J'ai écrit à ce sujet il y a quelque temps: Pourquoi NOT F #?
Vous demandez une comparaison entre un langage procédural et un langage fonctionnel. Je pense donc qu'on peut répondre à votre question ici: Quelle est la différence entre la programmation procédurale et la programmation fonctionnelle?
Pour répondre à la question de savoir pourquoi MS a créé F #, la réponse est simple: la création d’un langage fonctionnel avec accès à la bibliothèque .Net a simplement élargi sa base de marché. Et vu que la syntaxe est presque identique à OCaml, cela ne leur a vraiment pas demandé beaucoup d’efforts.
F # est essentiellement le C++ des langages de programmation fonctionnels. Ils ont presque tout gardé d'Objective Caml, y compris les parties vraiment stupides, et l'ont ajouté à l'exécution .NET de manière à générer toutes les mauvaises choses de .NET.
Par exemple, avec Objective Caml, vous obtenez un type de null, l'option <T>. Avec F #, vous obtenez trois types de null, l’option <T>, Nullable <T> et les nulls de référence. Cela signifie que si vous avez une option, vous devez d'abord vérifier si elle est "Aucune", puis vous devez vérifier si c'est "Some (null)".
F # est comme l'ancien Java clone J #, juste un langage bâtard pour attirer l'attention. Certaines personnes vont l'adorer, quelques-unes l'utiliseront même, mais au final Un langage de 20 ans a été ajouté au CLR.
F # n'est pas encore un autre langage de programmation si vous le comparez à C #, C++, VB. C #, C, VB sont tous des langages de programmation impératifs ou procéduraux. F # est un langage de programmation fonctionnel.
Les deux principaux avantages des langages de programmation fonctionnels (comparés aux langages impératifs) sont 1. qu'ils n'ont pas d'effets secondaires. Cela facilite beaucoup le raisonnement mathématique sur les propriétés de votre programme. 2. ces fonctions sont des citoyens de première classe. Vous pouvez transmettre des fonctions en tant que paramètres à d'autres fonctions aussi facilement que vous pouvez utiliser d'autres valeurs.
Les langages de programmation impératifs et fonctionnels ont leurs utilisations. Bien que je n’aie pas encore effectué de travail sérieux en F #, nous implémentons actuellement un composant de planification dans l’un de nos produits à base de C # et nous allons faire une expérience en codant le même planificateur en F # afin de déterminer si le l'implémentation peut être validée plus facilement qu'avec l'équivalent C #.
L’un des aspects de .NET que j’aime le plus, ce sont les génériques. Même si vous écrivez un code de procédure en fa #, vous bénéficierez toujours de l'inférence de type. Cela facilite l'écriture de code générique.
En C #, vous écrivez du code concret par défaut et vous devez faire un travail supplémentaire pour écrire du code générique.
En F #, vous écrivez du code générique par défaut. Après avoir passé plus d'un an en programmation en F # et C #, je constate que le code de bibliothèque que j'écris en F # est à la fois plus concis et plus générique que le code que j'écris en C #, et qu'il est donc également plus réutilisable. Je manque de nombreuses occasions d’écrire du code générique en C #, probablement parce que je suis aveuglé par les annotations de type obligatoires.
Il existe cependant des situations où l’utilisation de C # est préférable, en fonction des goûts et du style de programmation.
- C # n'impose pas d'ordre de déclaration parmi les types et n'est pas sensible à l'ordre dans lequel les fichiers sont compilés.
- C # a des conversions implicites que F # ne peut se permettre en raison de l’inférence de type.