Quels sont les avantages de l'utilisation de C # vs F # ou F # vs C #? [fermé]
93
Je travaille pour une entreprise de technologie qui fait plus de prototypage que d'expédition de produits. Je viens 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 #.
J'utilise le langage depuis un certain temps maintenant et je l'adore donc je pourrais facilement parler des excellentes fonctionnalités de F # mais je n'ai pas l'expérience en C # pour dire pourquoi nous devrions utiliser l'un sur l'autre.
Quels sont les avantages de l'utilisation de C # vs F # ou F # vs C #?
Il me semble qu'il y a déjà pas mal de questions sur le SO qui répondent au moins partiellement à votre question. Avez-vous essayé de rechercher en utilisant "[F #] mot clé" au lieu de "f # mot clé"? ("[f #] avantages", par exemple)
Benjol
Réponses:
86
Avantages généraux de la programmation fonctionnelle par rapport aux langages impératifs:
Vous pouvez formuler de nombreux problèmes beaucoup plus facilement, plus proches de leur définition et plus concis dans un langage de programmation fonctionnel comme F # et votre code est moins sujet aux erreurs (immuabilité, système de type plus puissant, algorithmes récurrents intuitifs). Vous pouvez coder ce que vous voulez dire au lieu de ce que l'ordinateur veut que vous disiez ;-) Vous trouverez de nombreuses discussions comme celle-ci lorsque vous le googlez ou même le recherchez chez SO.
Avantages spéciaux F #:
La programmation asynchrone est extrêmement simple et intuitive avec async {}-expressions - Même avec ParallelFX, le code C # correspondant est beaucoup plus grand
Intégration très facile des compilateurs de compilateurs et des langages spécifiques au domaine
Les avantages du C # sont qu'il est souvent plus précis pour les applications "impératives" (interface utilisateur, algorithmes impératifs) qu'un langage de programmation fonctionnel, que le .NET-Framework qu'il utilise est conçu impérativement et qu'il est plus répandu.
De plus, vous pouvez avoir F # et C # ensemble dans une seule solution, vous pouvez donc combiner les avantages des deux langages et les utiliser là où ils sont nécessaires.
Ils se combinent de manière très étrange. Par exemple, vous pouvez surcharger l'opérateur> dans F #. Les développeurs C # peuvent ensuite l'utiliser. Cependant, les développeurs F # ne peuvent pas. C'est vrai, F # peut émettre des surcharges d'opérateur qu'il ne peut pas consommer.
Jonathan Allen
Le lien "this document" est rompu ...
Eduardo Brites
36
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 y a des tâches qui sont difficiles et chronophages en c # mais faciles en f # - comme essayer de battre 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 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) qu'une interface utilisateur avec état complexe est plus facile en OO (c #) que fonctionnelle (f #). (Il y aurait probablement des gens qui ne seraient pas d'accord avec cela car c'est "cool" en ce moment de "prouver" à quel point il est facile de faire quoi que ce soit en F #, mais je le maintiens). Il y en a d'innombrables autres.
Si tout ce que vous avez est un marteau, tout ressemble à un clou. -Maslow
Charlie Salts
20
Je ne vais pas voter pour cela parce que cela ne donne pas de détails réels, à l'exception d'un exemple de données. Je sais que ce sont des outils différents. Je demande à quels emplois ces deux outils sont les meilleurs et les pires par rapport à l'autre. Je sais qu'un Philips est souvent le meilleur outil pour le travail, même si une petite tête plate fonctionnera.
gradbot
3
S'il refuse de vous voter, je le ferai. : P +1
Spencer Ruport
14
Si tout ce que vous avez est un marteau, tout ressemble à un pouce.
Ed Power le
6
Je suis d'accord avec gradbot, c'est une bonne réponse, donc pas de vote négatif de ma part, mais cela ne rentre pas vraiment dans les détails des questions originales. Cette réponse n'est qu'une vague explication conceptuelle, mais manque vraiment le point de répondre exactement à la question.
À propos de F # ayant de meilleures performances que C # pour les mathématiques: Apparemment, ce n'est pas vrai. Voir thinkfulcode.wordpress.com/2010/12/30/…
Joh
3
@Joh: inlineest un exemple évident de quelque chose qui peut fournir des améliorations de performances massives en F # que C # ne peut pas exprimer.
JD
@Jon Harrop: Je faisais spécifiquement référence à l'entrée de blog de Rinat. Il semble que les délais en faveur de F # qu'il a obtenus étaient dus à un code C # sous-optimal.
Joh le
27
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 seulement «fonctionnel contre OO». C'est "Fonctionnel + OO contre OO". Les fonctionnalités fonctionnelles de C # sont assez rudimentaires. Les F # ne le sont pas. Pendant ce temps, F # fait presque toutes les fonctionnalités OO de C #. Pour la plupart, F # finit comme un sur-ensemble des fonctionnalités de C #.
Cependant, il existe quelques cas où F # n'est peut-être pas le meilleur choix:
Interop. Il existe de nombreuses bibliothèques qui ne seront tout simplement pas trop à l'aise avec F #. Peut-être qu'ils exploitent certaines choses C # OO que F # ne fait pas de même, ou peut-être qu'ils s'appuient sur des composants internes du compilateur C #. Par exemple, Expression. Bien que vous puissiez facilement transformer une citation F # en une expression, le résultat n'est pas toujours exactement ce que C # créerait. Certaines bibliothèques ont un problème avec cela.
Oui, l'interopérabilité est un réseau assez gros et peut entraîner un peu de friction avec certaines bibliothèques.
Je considère que l'interopérabilité doit également être incluse si vous avez une grande base de code existante. Cela n'a peut-être pas de sens de commencer à écrire des parties en F #.
Outils de conception. F # n'en a pas. Cela ne veut pas dire qu'il ne pouvait pas en avoir, mais pour le moment, 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 actuellement pas IntelliSense. Ainsi, vous devez soigneusement considérer où seront vos limites pour le code généré. Sur un tout petit projet qui utilise presque exclusivement les différents concepteurs, cela ne vaut peut-être pas la peine d'utiliser F # pour le "glue" ou la logique. Sur les projets plus importants, cela pourrait devenir moins un problème.
Ce n'est pas un problème intrinsèque. Contrairement à la réponse de Rex M, je ne vois rien d'intrinsèque à propos de C # ou F # qui les incite à faire une interface utilisateur avec beaucoup de champs mutables. Peut-être faisait-il référence à la surcharge supplémentaire de devoir écrire «mutable» et d'utiliser <- au lieu de =.
Dépend également de la bibliothèque / du concepteur utilisé. Nous adorons 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 inline" ASPX réel entre C # et F #, en fonction de ce dont nous avons besoin sur cette page. (IntelliSense par rapport aux types F #.)
D'autres outils. Ils peuvent simplement s'attendre à C # et ne pas savoir comment gérer les projets F # ou le code compilé. De plus, les bibliothèques de F # ne sont pas livrées dans le cadre de .NET, vous avez donc un peu plus à expédier.
Mais le problème numéro un? Gens. Si aucun de vos développeurs ne veut apprendre F #, ou pire, a de sérieuses difficultés à comprendre certains aspects, alors vous êtes probablement toast. (Bien que, je dirais que vous portez un toast de toute façon dans ce cas.) Oh, et si la direction dit non, cela pourrait être un problème.
Quant à 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 leur base de marché. Et vu à quel point la syntaxe est presque identique à OCaml, cela n'a vraiment pas demandé beaucoup d'efforts de leur part.
Bien que je pense que votre réponse générale est correcte, la vraie question concerne la comparaison des paradigmes de programmation et non des langages, je pense que la réponse à la question à laquelle vous faites référence est un peu superficielle.
Jeroen Huinink
N'hésitez pas à proposer une autre question si vous en avez une meilleure. C'est celui que j'ai trouvé le mieux noté lors d'une recherche Google.
Spencer Ruport le
1
Je pense qu'il essayait d'être gentil avec toi, en disant que F # ne demandait pas beaucoup d'efforts de la part de Micrsoft.
Matthew Whited
+1 pour le commentaire de base du marché. Simple et a une part de vérité.
gradbot
1
Je n'achète pas cet autre lien pour répondre à ma question. C # prend en charge de nombreuses constructions fonctionnelles dans les versions plus récentes.
gradbot
5
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 (par rapport 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. que les fonctions sont des citoyens de première classe. Vous pouvez passer des fonctions en tant que paramètres à d'autres fonctions aussi facilement que d'autres valeurs.
Les langages de programmation impératifs et fonctionnels ont leurs utilisations. Bien que je n'ai pas encore fait de travail sérieux en F #, nous implémentons actuellement un composant de planification dans l'un de nos produits basé sur C # et allons faire une expérience en codant le même planificateur en F # également pour voir si l'exactitude du l'implémentation peut être validée plus facilement qu'avec l'équivalent C #.
-1. F # est un langage multi-paradigme (OO + FP). Seuls les langages purement fonctionnels n'ont pas d'effets secondaires (comme Haskell), mais F # n'est pas pur.
Mauricio Scheffer le
5
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 jeté par-dessus le runtime .NET de telle manière qu'il apporte également 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 valeurs nulles de référence. Cela signifie que si vous avez une option, vous devez d'abord vérifier si elle est "Aucune", alors vous devez vérifier si elle est "Some (null)".
F # est comme l'ancien clone Java J #, juste un langage bâtard juste pour attirer l'attention. Certaines personnes l'adoreront, quelques-unes l'utiliseront même, mais au final, c'est encore un langage vieux de 20 ans collé au CLR.
+1, C'est peut-être la dure vérité, mais je suis toujours assez heureux de pouvoir utiliser un langage fonctionnel dans VS avec .NET
gradbot
1
Je suis d'accord que Nullable <T> devrait demander au compilateur de faire un alias magique pour nous. Je ne suis pas sûr que rendre "Some null" équivalent à None fonctionnerait toujours - certains codes d'interopérabilité pourraient en s'appuyer. Mais référence null? Comment allez-vous contourner un trou majeur dans .NET? Enveloppez chaque type de référence dans une option? En pratique, cela ne semble être un problème que dans certains scénarios d'interopérabilité.
MichaelGG
12
FWIW, j'ai codé professionnellement en F # pendant plusieurs années (plus longtemps que presque n'importe qui d'autre dans le monde) et je n'ai jamais vu ce problème ou le code Some nulldans aucun code F # nulle part. De toutes les choses à propos desquelles les gens pourraient se plaindre, cela doit figurer sur la liste ...
JD
1
Comparer F # à C ++ est un peu farfelu. De nombreuses parties de C ++ ont une sémantique non définie ou peu claire, F # est simple et bien défini. La qualité du runtime .NET ne peut pas être tenue pour F #, car tout langage .NET aura les mêmes problèmes.
Joh
1
En plus de 2 ans de programmation professionnelle F #, comme @Jon, je n'ai jamais vu de problème lié à 'Some null'. D'un autre côté, j'ai énormément profité des fonctionnalités du framework .Net.
Marc Sigrist
5
Les génériques sont l'un des aspects de .NET que j'aime le plus. Même si vous écrivez du code procédural en F #, 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 effectuer 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 à programmer en F # et C #, je trouve 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 donc aussi plus réutilisable. Je manque de nombreuses opportunités 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, selon les goûts et le 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 pas se permettre en raison de l'inférence de type.
Réponses:
Avantages généraux de la programmation fonctionnelle par rapport aux langages impératifs:
Vous pouvez formuler de nombreux problèmes beaucoup plus facilement, plus proches de leur définition et plus concis dans un langage de programmation fonctionnel comme F # et votre code est moins sujet aux erreurs (immuabilité, système de type plus puissant, algorithmes récurrents intuitifs). Vous pouvez coder ce que vous voulez dire au lieu de ce que l'ordinateur veut que vous disiez ;-) Vous trouverez de nombreuses discussions comme celle-ci lorsque vous le googlez ou même le recherchez chez SO.
Avantages spéciaux F #:
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 compilateurs et des langages spécifiques au domaine
Extension de la langue selon vos besoins: LOP
Unités de mesure
Syntaxe plus flexible
Des solutions souvent plus courtes et plus élégantes
Jetez un œil à ce document
Les avantages du C # sont qu'il est souvent plus précis pour les applications "impératives" (interface utilisateur, algorithmes impératifs) qu'un langage de programmation fonctionnel, que le .NET-Framework qu'il utilise est conçu impérativement et qu'il est plus répandu.
De plus, vous pouvez avoir F # et C # ensemble dans une seule solution, vous pouvez donc combiner les avantages des deux langages et les utiliser là où ils sont nécessaires.
la source
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 y a des tâches qui sont difficiles et chronophages en c # mais faciles en f # - comme essayer de battre 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 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) qu'une interface utilisateur avec état complexe est plus facile en OO (c #) que fonctionnelle (f #). (Il y aurait probablement des gens qui ne seraient pas d'accord avec cela car c'est "cool" en ce moment de "prouver" à quel point il est facile de faire quoi que ce soit en F #, mais je le maintiens). Il y en a d'innombrables autres.
la source
la source
inlineest un exemple évident de quelque chose qui peut fournir des améliorations de performances massives en F # que C # ne peut pas exprimer.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 seulement «fonctionnel contre OO». C'est "Fonctionnel + OO contre OO". Les fonctionnalités fonctionnelles de C # sont assez rudimentaires. Les F # ne le sont pas. Pendant ce temps, F # fait presque toutes les fonctionnalités OO de C #. Pour la plupart, F # finit comme un sur-ensemble des fonctionnalités de C #.
Cependant, il existe quelques cas où F # n'est peut-être pas le meilleur choix:
Interop. Il existe de nombreuses bibliothèques qui ne seront tout simplement pas trop à l'aise avec F #. Peut-être qu'ils exploitent certaines choses C # OO que F # ne fait pas de même, ou peut-être qu'ils s'appuient sur des composants internes du compilateur C #. Par exemple, Expression. Bien que vous puissiez facilement transformer une citation F # en une expression, le résultat n'est pas toujours exactement ce que C # créerait. Certaines bibliothèques ont un problème avec cela.
Oui, l'interopérabilité est un réseau assez gros et peut entraîner un peu de friction avec certaines bibliothèques.
Je considère que l'interopérabilité doit également être incluse si vous avez une grande base de code existante. Cela n'a peut-être pas de sens de commencer à écrire des parties en F #.
Outils de conception. F # n'en a pas. Cela ne veut pas dire qu'il ne pouvait pas en avoir, mais pour le moment, 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 actuellement pas IntelliSense. Ainsi, vous devez soigneusement considérer où seront vos limites pour le code généré. Sur un tout petit projet qui utilise presque exclusivement les différents concepteurs, cela ne vaut peut-être pas la peine d'utiliser F # pour le "glue" ou la logique. Sur les projets plus importants, cela pourrait devenir moins un problème.
Ce n'est pas un problème intrinsèque. Contrairement à la réponse de Rex M, je ne vois rien d'intrinsèque à propos de C # ou F # qui les incite à faire une interface utilisateur avec beaucoup de champs mutables. Peut-être faisait-il référence à la surcharge supplémentaire de devoir écrire «mutable» et d'utiliser <- au lieu de =.
Dépend également de la bibliothèque / du concepteur utilisé. Nous adorons 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 inline" ASPX réel entre C # et F #, en fonction de ce dont nous avons besoin sur cette page. (IntelliSense par rapport aux types F #.)
D'autres outils. Ils peuvent simplement s'attendre à C # et ne pas savoir comment gérer les projets F # ou le code compilé. De plus, les bibliothèques de F # ne sont pas livrées dans le cadre de .NET, vous avez donc un peu plus à expédier.
Mais le problème numéro un? Gens. Si aucun de vos développeurs ne veut apprendre F #, ou pire, a de sérieuses difficultés à comprendre certains aspects, alors vous êtes probablement toast. (Bien que, je dirais que vous portez un toast de toute façon dans ce cas.) Oh, et si la direction dit non, cela pourrait être un problème.
J'ai écrit à ce sujet il y a quelque temps: Pourquoi PAS F #?
la source
Vous demandez une comparaison entre un langage procédural et un langage fonctionnel. Je pense donc que vous pouvez répondre à votre question ici: Quelle est la différence entre la programmation procédurale et la programmation fonctionnelle?
Quant à 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 leur base de marché. Et vu à quel point la syntaxe est presque identique à OCaml, cela n'a vraiment pas demandé beaucoup d'efforts de leur part.
la source
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 (par rapport 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. que les fonctions sont des citoyens de première classe. Vous pouvez passer des fonctions en tant que paramètres à d'autres fonctions aussi facilement que d'autres valeurs.
Les langages de programmation impératifs et fonctionnels ont leurs utilisations. Bien que je n'ai pas encore fait de travail sérieux en F #, nous implémentons actuellement un composant de planification dans l'un de nos produits basé sur C # et allons faire une expérience en codant le même planificateur en F # également pour voir si l'exactitude du l'implémentation peut être validée plus facilement qu'avec l'équivalent C #.
la source
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 jeté par-dessus le runtime .NET de telle manière qu'il apporte également 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 valeurs nulles de référence. Cela signifie que si vous avez une option, vous devez d'abord vérifier si elle est "Aucune", alors vous devez vérifier si elle est "Some (null)".
F # est comme l'ancien clone Java J #, juste un langage bâtard juste pour attirer l'attention. Certaines personnes l'adoreront, quelques-unes l'utiliseront même, mais au final, c'est encore un langage vieux de 20 ans collé au CLR.
la source
Some nulldans aucun code F # nulle part. De toutes les choses à propos desquelles les gens pourraient se plaindre, cela doit figurer sur la liste ...Les génériques sont l'un des aspects de .NET que j'aime le plus. Même si vous écrivez du code procédural en F #, 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 effectuer 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 à programmer en F # et C #, je trouve 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 donc aussi plus réutilisable. Je manque de nombreuses opportunités 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, selon les goûts et le style de programmation.
la source