Si vous connaissez déjà LISP, pourquoi voudriez-vous aussi apprendre le f #?

StackOverflow https://stackoverflow.com/questions/126790

  •  02-07-2019
  •  | 
  •  

Question

Quelle est la valeur ajoutée de l'apprentissage du F # lorsque vous connaissez déjà LISP?

Était-ce utile?

La solution

Beaucoup de ces développements sont relativement récents dans le monde des langages de programmation. C'est quelque chose que vous verrez dans F # que vous ne verrez pas dans Lisp, en particulier Common Lisp, car la norme F # est encore en développement. En conséquence, vous constaterez qu'il y a beaucoup à apprendre. Bien sûr, des éléments tels que les ADT, la recherche de motifs, les monades et le curry peuvent être construits comme une bibliothèque en Lisp, mais il est plus agréable d'apprendre à les utiliser dans une langue où ils sont intégrés de manière pratique.

Le principal avantage de l'apprentissage de F # pour une utilisation réelle est son intégration à .NET.

Autres conseils

Comparer Lisp directement à F # n’est pas vraiment juste, car en fin de journée, avec suffisamment de temps, vous pourriez écrire la même application dans les deux langues.

Toutefois, vous devez apprendre le F # pour les mêmes raisons que celles qu'un développeur C # ou Java devrait connaître - car cela permet une programmation fonctionnelle sur la plate-forme .NET . Je ne suis pas parfaitement au courant de Lisp, mais je suppose qu'il pose les mêmes problèmes qu'OCaml en ce qu'il ne prend pas en charge les bibliothèques stellaires. Comment faites-vous accès à la base de données dans Lisp? Qu'en est-il des graphiques haute performance?

Si vous souhaitez en savoir plus sur "Pourquoi .NET", consultez cette question SO .

Si vous connaissiez F # et Lisp, vous auriez trouvé cette question plutôt étrange à poser.

Comme d'autres l'ont souligné, Lisp est typé dynamiquement . Plus important encore, la particularité de Lisp est qu’il est homoiconique: le code Lisp est un type de données Lisp fondamental (une liste). Le système de macros tire parti de cela en vous permettant d’écrire un code qui s’exécute au moment de la compilation et modifie un autre code .

F # n’a rien de tel - c’est un langage statiquement typé qui emprunte beaucoup d’idées à ML et Haskell et l’exécute sur .NET

Ce que vous demandez s'apparente à "Pourquoi dois-je apprendre à utiliser une cuillère si je sais utiliser une fourchette?"

Étant donné que LISP est typé de manière dynamique et que F # est typé de manière statique, je trouve ces comparaisons étranges.

Si je passais de Lisp à F #, c’était uniquement parce que j’avais une tâche entre les mains qui bénéficiait énormément d’une librairie .NET uniquement.

Mais ce n'est pas mon cas, donc je ne le suis pas.

Argent. Le code F # a déjà plus de valeur que le code Lisp et cet écart s’élargira très rapidement car F # est de plus en plus adopté.

En d’autres termes, vos chances de gagner un revenu stable avec F # plutôt qu'avec Lisp.

Salut, Jon Harrop.

F # est une langue très différente de la plupart des dialectes Lisp. Donc, F # vous donne un angle de programmation très différent - un angle que vous n’apprendrez pas de Lisp. La plupart des dialectes Lisp sont mieux utilisés pour le développement incrémental et interactif de logiciels symboliques. Dans le même temps, la plupart des dialectes Lisp ne sont pas des langages de programmation fonctionnels, mais plutôt des langages à paradigmes multiples - différents dialectes accordant un poids différent aux fonctions FPL prises en charge (sans effets secondaires, structures de données immuables, types de données algébriques, ...). Ainsi, la plupart des dialectes Lisp manquent de typage statique ou n’y mettent pas beaucoup d’importance.

Donc, si vous connaissez un dialecte Lisp, apprendre le F # peut avoir beaucoup de sens. Ne croyez pas que votre connaissance de Lisp s’applique beaucoup à F #, car F # est une langue très différente. Même si une programmation impérative utilisée en C ou en Java nécessite de désapprendre certaines idées lors de l'apprentissage de Lisp, il est également nécessaire de désapprendre les habitudes de Lisp (pas de types, d'effets secondaires, de macros, ...) lors de l'utilisation de F #. F # est également piloté par Microsoft et tire parti du framework .net.

F # présente l’avantage que le développement .NET (en général) est très largement adopté, facilement disponible et plus commercialisé en masse.

Si vous voulez coder en F #, vous pouvez obtenir Visual Studio, que de nombreux développeurs disposeront déjà ... par opposition à la mise en place de l'environnement LISP.

De plus, les développeurs .NET existants sont beaucoup plus susceptibles d’utiliser F # que LISP, si cela vous dit quelque chose.

(Cela vient d'un développeur .NET qui a codé et aimé LISP pendant ses études).

Je ne sais pas si vous le feriez? Si vous trouvez F # intéressant, ce serait une raison. Si vous travaillez le nécessite, ce serait une raison. Si vous pensez que cela vous rendrait plus productif ou vous apporterait une valeur ajoutée par rapport à vos connaissances actuelles, ce serait une raison.

Mais si vous ne trouvez pas F # intéressant, si votre travail ne l'exige pas et si vous pensez qu'il ne vous rendrait pas plus productif ni ne vous apporterait une valeur ajoutée, pourquoi le voudriez-vous?

Si, par contre, la question est de savoir ce que F # donne à ce que Lisp ne le fait pas, tapez l'inférence de type, la correspondance de modèle et l'intégration avec le reste du framework .NET doivent être pris en compte.

Je sais que ce fil est ancien, mais depuis que je suis tombé par hasard sur celui-ci, je voulais seulement commenter mes raisons. J'apprends le F # simplement pour des opportunités professionnelles, car .NET a beaucoup de poids dans une catégorie d'entreprises qui dominent mon domaine. Le paradigme fonctionnel est de plus en plus utilisé par les entreprises plus quantitatives et axées sur les données, et je voudrais être l’un des pionniers de cette tendance. Il n'existe actuellement aucun langage fonctionnel fort qui s'intègre de manière complète et en toute sécurité à la bibliothèque .NET. J'ai en fait essayé de porter du code .NET à partir de Lisp et c'est vraiment pénible, car la FFI ne prend en charge que les primitives C et l'interopérabilité .NET nécessite une construction d'interface et même si je sais comment faire cela en C, c'est vraiment un énorme douleur. Ce serait vraiment très bien si Lisp faisait un effort supplémentaire dans son prochain standard et nécessitait une classe c ++ (y compris les fonctions virtuelles avec vtables) et un type d'interface de style C # dans son FFI. Peut-être même ajouter un type de style d'interface Java aussi. Cela permettrait une interopérabilité complète avec la bibliothèque .NET et ferait de Lisp un concurrent sérieux en tant que langage à grande échelle. Cependant, cela dit, le fait de venir de Lisp a rendu l’apprentissage du F # plutôt facile. Et j'aime bien la façon dont F # a fait un effort supplémentaire pour fournir des types que vous verriez couramment comme un travail de type quantitatif. Je pense que F # a été créé avec un travail mathématique à l’esprit et qu’il a de la valeur par rapport à Lisp.

Une façon de voir cela (la question initiale) est de faire correspondre le langage (et les outils et plates-formes associés) à la tâche immédiate. Si la tâche nécessite un pourcentage écrasant de code .NET, et si elle nécessitait moins d'attaque dans une langue que dans une autre, elle prendrait le chemin de la moindre résistance (F #). Si vous n’avez pas besoin des fonctionnalités .NET, que vous êtes à l'aise avec LISP et qu’il n’est pas difficile de s’éloigner de lui, continuez à l’utiliser.

Ce n’est pas très différent de comparer un marteau avec une clé. Choisissez l'outil qui convient le mieux au travail. Essayer de choisir un outil qui est objectivement "meilleur" est un non-sens. Et dans tous les cas, dans 20 ans, tous les "chauds" actuellement les langues pourraient être obsolètes de toute façon.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top