Quels sont les avantages de l'utilisation de C # vs F # ou F # vs C #? [fermé]

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 #?

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

• 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.

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.

• F # a de meilleures performances que C # en mathématiques
• 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 vraiment bon pour l'exécution parallèle (il est plus facile de faire exécuter du 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 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 #?

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.

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 #.

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.

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.