Duplicaté possible:
Quels sont les avantages de l'utilisation de C # vs f # ou f # vs c #Mon équipe utilise actuellement C # .NET pour développer des applications d'entreprise pour notre société. Nous avons une histoire de Winforms Dev, mais nous passons maintenant vers Silverlight.
Mon patron a récemment vu une vidéo sur F # et pensais que ça avait l'air assez excitant et il m'a demandé de vérifier. Ma question est la suivante: quels avantages un langage fonctionnel (comme F #) donnent-ils sur une langue oo (comme c #) dans le domaine du développement des applications d'entreprise?
Je veux vraiment voir s'il y a des raisons impérieuses de commencer à contempler un quart de travail. Certains code de comparaison F # et C # peuvent être agréables à voir aussi.
3 Réponses :
Je viens de commander le Manning ' Programmation fonctionnelle du monde réel ' qui fait un travail fantastique d'explication Tous les coins et recoins de la programmation f #, de la programmation fonctionnelle, et surtout comment il se compare à C #, et oop
Ce que je suis descendu, c'est que la programmation fonctionnelle en général augmente la «rigueur» de vos programmes, en supposant que vous êtes conforme aux principes des fonctions libres d'effet secondaire et de l'immuabilité.
En outre, il semble y avoir des avantages pour réfléchir au code de manière déclarée, plutôt qu'un sens impératif. Dans OOP, j'ai tendance à penser aux mesures qu'il faut pour accomplir quelque chose, mais à la FP, cela semble être plus préoccupé par la manière dont vous souhaitez appliquer des fonctions aux données pour obtenir des résultats.
Vous pouvez exprimer beaucoup de concepts beaucoup plus concis dans une langue fonctionnelle comme F #.
Les fonctions sont des objets de première classe et peuvent être appliqués directement aux collections pour effectuer des transformations / filtrage beaucoup plus efficacement.
L'immuabilité est encouragée dans des langages fonctionnelles, ce qui rend (par exemple) le code multi-threadé beaucoup plus fiable (vous savez que les structures de données ne changent pas sous vous).
En étant capable d'écrire du code multi-threadé de manière plus fiable et plus facilement, il est beaucoup plus facile de tirer parti de plusieurs processeurs / cœurs (de plus en plus important, la loi de Moore ne s'applique pas autant).
Notez que vous pouvez utiliser vos objets C # existants dans F #. En tant que tel, vous voudrez peut-être écrire certaines parties de votre code en F # et d'autres parties de C #. Vous devriez être capable de mélanger et de faire correspondre en fonction de vos besoins et de l'adéquation de chaque approche.
+1 La multithreading est triviale sans effets secondaires. Après tout, si vous n'écrivez pas l'état, il n'est pas nécessaire de verrouiller quoi que ce soit.
Tout d'abord, vous demandez "la langue fonctionnelle (comme F #) donner sur une langue oo (comme c #) i" F # est à la fois fonctionnelle et oo. Toute chose que vous écririez en C # peut être directement traduite à F #. F # est une langue multi-paradigme, mais l'avantage vient de la partie fonctionnelle à mon avis. F # et autres languettes fonctionnels sont un gagnant clair lorsqu'il s'agit d'écrire des applications multi-filetées en raison des possibilités plus élevées pour le compilateur afin de raisonner sur ce qui peut être exécuté en toute sécurité en parallèle.
En ce qui concerne le développement Web F # a une trousse à outils très cool qui vous permet d'écrire tout code (comme dans le côté serveur et côté client) dans la même langue aka f #. Le côté client sera traduit en JavaScript par la boîte à outils Web.
Bien que les deux modes d'utilisation soient pris en charge, F # est une langue fonctionnelle avec des caractéristiques impératives et C # est une langue impérative avec des fonctionnalités fonctionnelles. Il serait extrêmement fastidieux de mettre «mutable» dans chaque déclaration. En outre, la programmation impérative inhibe la capacité de F # à faire la correspondance de motif et de l'inférence de type.
@Joel bien selon Don Syme L'un des principaux architectes de F # My Déclarez à propos de F # Être multiparadigm est vrai. Je suis simplement paraphraser son expert du livre F # et votre imcochar sur le mutable, vous n'avez pas besoin de cela pour faire OO en F # uniquement si vous souhaitez que les choses mutables et que vous soyez également erroné sur la correspondance des motifs. Oo in f # peut être associé à la correspondance de motif. L'un des buts de courrier de F # était de combiner les mondes de OO et de FP et d'inférence de type BTW fonctionne même avec des classes non f #.
La recommandation de votre patron n'est pas suffisamment convaincante pour le vérifier? :)
Une chose à garder à l'esprit, en fonction de la taille et de l'expérience de votre équipe: ne sous-estimez pas la productivité initiale du succès que vous allez passer à partir d'une langue et d'approche l'équipe sait à un doit apprendre. Il ne s'agit pas simplement d'apprendre la syntaxe, de la comprendre à un niveau profond, en l'appliquant correctement à la structure générale, etc. Ne disant pas que cela n'en vaut pas la peine (je ne sais rien à propos de F #, en fait), ce qui passe à partir d'une collision basée sur la classe à fonctionnement. La programmation ou le prototype OOP (tel que JavaScript) est un effort non trivial qui nécessite une analyse de rentabilisation non triviale.
@ T.J. Crowder - secondé. Le tout impératif au changement de mentalication fonctionnel ne devrait pas être sous-estimé.
@ T.J. Crowder, et @brian Agnew - convenu ++, mais ne sous-estimez pas les avantages à long terme et les améliorations de la manière dont vous pensez des problèmes après avoir effectué ce changement.
@John - Oui. J'essaie de passer de Java à Scala. Il y a des avantages définis. C'est juste que mon code initial Scala a l'air / lit comme, eh bien, java :-)
Accepté avec Crowder. Je commence sur F #, et à moins que votre équipe ait une expérience antérieure avec des langues fonctionnelles, attendez-vous à une courbe d'apprentissage escarpée.
@Brian agnew - sonne comme mon f # et c # :)
@Brian: Je ne peux pas parler sur Scala, mais re: F # vs c #, il est quelque peu possible d'écrire un code F # dans le style C # - mais il n'y a pas beaucoup de point dans la commutation ... La partie difficile est de Acceptez que vous devez tout repenser et embrasser une approche fonctionnelle.
@Mathias - absolument. Ce commutateur est la partie difficile :-) Désolé. C'est le point que j'essayais de faire.