est F # pour IronPython / IronRuby comme C # est à VB.NET?

Question

Je viens d'écouter podcast de Chris Smith parle de F # dans lequel il parle de la façon dont F # est un langage qui vous permet de problèmes d'approche d'une manière différente que dans C # / VB.NET, soit au lieu de « pousser morceaux autour de » vous « chaîne ensemble données transformations », et que la façon dont F # sera « devenir comme XML », quelque chose que vous utilisez en plus de langue de votre choix (C # ou VB.NET) afin de résoudre certains problèmes d'une manière plus efficace manière.

m'a fait penser sur la relation entre les langages .NET, voici comment je les comprends:

• C # et VB.NET sont syntaxiquement mais pas substantiellement différent , à savoir un programmeur C # n'apprendraient pas VB.NET afin de « d'aborder les problèmes d'une manière nouvelle »
• cependant, un C # ou VB.NET programmeur apprendrait F # afin de "problèmes de programmation d'approche de manière fonctionnelle "

Mais qu'en est- IronPython et IronRuby ? Chris a mentionné que « F # a beaucoup appris de Ruby et Python » Je pense donc que F # a une relation similaire à IronRuby / IronPython et C # VB.NET doit. Cependant, un peu googler me dit autour de cette IronRuby et IronPython sont tous deux construits sur le DLR, mais F # est pas .

Comment sont les relations entre F #, IronRuby et IronPython pour être mieux compris?

Answer 1

F # et IronPython / IronRuby sont à des années-lumière du point de vue linguistique. F # est un langage compilé fonctionnel, très typé. IronRuby / IronPython sont typé dynamiquement, langages interprétés.

Je crois IronPython ne supporte plus la compilation mais je ne suis pas sûr à 100%, et moins sur rubis.

La relation entre VB.Net et C # est beaucoup plus proche.

Answer 2

À bien des égards F # et Ruby / Python sont en apparence similaires. Les trois langues vous permettent d'exprimer de manière concise des idées sans encombrer votre code avec de nombreux types. Cependant, F # est en fait très différent de Ruby et Python, puisque F # est un langage statiquement typé, alors que Ruby et Python sont dynamiquement typés. Code idiomatiques F # mentionne rarement les types, mais le compilateur infère types et des erreurs de type sera signalé par le compilateur lors de la compilation. Pour Ruby et Python, en utilisant une valeur au mauvais type seulement générer des erreurs lors de l'exécution. Le dynamisme de Ruby et Python signifie que les deux sont plus disposés à metaprogramming que F # est (types peuvent être modifiés lors de l'exécution, par exemple). D'autre part, F # va être plus performant pour la plupart des tâches (comparables à C #), et offre de nombreuses belles abstractions fonctionnelles telles que les syndicats discriminés avec correspondance de motif. Il est certainement vrai que l'apprentissage d'une de ces langues bien vous conduire à réfléchir sur les problèmes différemment que vous faites en C # ou VB.NET, mais votre approche sera probablement beaucoup varier entre F # et Python / Ruby ainsi.

Answer 3

Je dirais que F # a appris beaucoup plus de OCaml qu'il a fait de Ruby et Python combiné. La seule comparaison réelle est que F # est apporte ML à .NET de la même manière que IronPython / Ruby apporter Python / Ruby à .NET.

Answer 4

F # est plus d'une langue « outil » où il y a des problèmes spécifiques qui sont mieux combattues par une approche fonctionnelle. F # est pas thread à sécurité intrinsèque qui donne de l'espoir qu'il sera utile à l'échelle d'une application à utiliser plusieurs processeurs. Je vois F # utilisé pour construire des composants qui seront utilisés dans VB.NET ou C # pour traiter des problèmes spécifiques.

Answer 5

Il y a des aspects de F # qui sont semblables à des langages dynamiques; Cependant, la réponse de JaredPar résume vraiment. F # est dans sa propre catégorie de programmation fonctionnelle où que IronRuby et IronPython sont des langages dynamiques et C # / VB OO Langues. Ils peuvent tous faire les mêmes choses et ne dépend que de la façon dont vous voulez le faire. Chacun a ses avantages et les inconvénients pour un problème donné.

Answer 6

NOTE: Ceci est la plupart du temps une compilation de mes réflexions et observations sur le sujet. Je suis un programmeur C # par jour et Python par nuit.

Ouais je suis d'accord avec certaines des choses qui a été dit, mais j'ai un peu de temps et se sentir comme l'élaboration et le partage de mes pensées.

F # est un langage fonctionnel. Ce qui signifie que vous êtes vraiment plus préoccupés par les verbes pour ainsi dire. Il est toujours typé statiquement et fonctionne sur le CLR, mais vous structurez votre code différemment et fonctionnent différemment par les problèmes. Habituellement, les gens pensent que les langages fonctionnels sont plus mathématiques dans la structure et plus facile à prouver formellement. Bien sûr, qui est généralement considéré comme la plupart du temps universitaire.

C # et d'autres langages OO statiquement typés sont vraiment plus axé sur les noms à d'autres mon analogie. Donc, vous structurez votre code et travailler par des problèmes en ce qui concerne cela. Bien sûr, il y a aussi des problèmes naturels avec le maintien de l'état et ayant des méthodes non déterministes sur les objets qui ont tendance à venir dans les langues OO plus souvent.

Et bien sûr, F # a des caractéristiques et des idées empruntées aux langages OO en C # a des idées et de traits empruntés à fonctionnel.

En comparant Python et C # est plus sur la différence entre le typage dynamique et statique (bien que python offre quelques fonctionnalités que C # ne fonctionne toujours pas). typage dynamique étant généralement beaucoup plus facile à manipuler l'introspection / activités de réflexion et de modification d'exécution tout en ajoutant le risque d'erreurs d'exécution en raison de fautes de frappe ou d'objets incorrects utilisés dans le code « régulier ».

langues statiques ont généralement certains frais généraux de développement que les langages dynamiques n'ont pas. Les frais généraux semble être généralement en raison d'avoir à créer des couches à des choses abstraites loin et de créer des hiérarchies d'héritage et les interfaces pour travailler avec le besoin / voulait abstraction. Puisque vous essayez d'éviter les dépendances aux types.

Il semble que les langues peuvent être beaucoup statics plus facile à gérer dans les grandes équipes. De plus, vous obtenez les avantages de refactoring très facilement avec toutes les vérifications et les outils là-bas.