1) Les langages fonctionnels conviennent-ils au développement d'applications Web?
2) Les langages fonctionnels sont-ils adaptés aux applications de type entreprise / ERP / CRM ?
Réponses
Trop de publicités?
Les langages fonctionnels du type que vous décrivez sont des langages de programmation, ils sont utilisés pour toutes sortes de choses, y compris les applications web et les applications d'entreprise. (J'utilise Haskell).
Comme gabor implique, en fin de compte, il revient à l'bibliothèques. Scala est un framework web: ascenseur. Haskell a happstack, ainsi que 2100 4400 (de 2010 à 2012) des bibliothèques sur le Hackage pour toutes sortes de thiings.
Il n'en est pas tellement une question de la langue, comme l'ensemble des outils, lors de l'examen particulier des domaines spécialisés.
Vincent Ramdhanie
Points
46265
Les langages fonctionnels sont bons pour quelque chose que vous aimeriez utiliser pour.
Cependant, le développement d'applications de ces jours ne sont pas aussi simple que l'utilisation d'un langage de programmation. L'avantage de Java, C#, etc. c'est qu'ils viennent avec de grandes bibliothèques d'environnement et d'autres subtilités qui sont absolument nécessaires lorsque vous créer des logiciels d'entreprise. La plupart des langages fonctionnels n'ont pas qu'un grand soutien (encore?).
F# pourraient être prometteurs, puisque c'est dans l' .NET de l'environnement et pouvez profiter des outils disponibles (corrigez-moi si je me trompe).
Cet article décrit comment Lisp, un langage fonctionnel, a été utilisé pour créer une application web avec succès.
Alex Dean
Points
3997
2) Sont des langages fonctionnels adaptés pour l'entreprise/ERP/CRM type d'applications?
Pour aborder le deuxième point à propos de l'entreprise/ERP/CRM applications: personnellement, je ne voudrais pas mettre en œuvre ces "pure", un langage fonctionnel comme Haskell, ou une dynamique fonctionnelle de la langue comme Clojure. D'autre part, je suis actuellement à la mise en œuvre d'un ERP en Scala, qui est bien sûr hybride de la programmation orientée objet/FP et compilés statiquement.
La raison pour laquelle je dis cela c'est qu'une application d'entreprise comme un ERP est fondamentalement document axé sur: il y a un schéma de données exprimant les différents types d'enregistrements et de l'application de la logique est alors conçu presque exclusivement autour de CRUDing ces documents et de l'application de la coutume d'affaires des flux de travail pour eux. Et fondamentalement, je ne crois pas que ce genre d'entreprise basée sur les données des applications sont un grand ajustement pour le modèle fonctionnel.
Les gens peuvent parler de la programmation orientée objet-relationnel incompatibilité de tout ce qu'ils aiment, mais en fin de compte à la fois de la programmation orientée objet et les bases de données d'enregistrement sont-orienté: un langage de programmation orientée objet avec une bonne ORM vous permet de mapper les différents modèles de données dans votre code, puis fixez le code pour gérer chacun des modèles. Le fait d'avoir ce type statique (idéalement avec un typage fort ORM comme Scala squeryl) massivement réduit les chances d'une erreur d'exécution ou, par exemple, une modification à l'un des modèles de données ne sont pas correctement appliquées par le code.
Ne vous méprenez pas, je suis un grand fan de la FP (je suis en train de faire de plus en plus de mes systèmes de programmation Haskell), mais pour moi, le document axé sur l'approche de la programmation orientée objet a plus de sens que la fonction de l'approche axée sur des FP pour des querelles les objets de données d'une entreprise, ERP ou similaire. (Scala est une belle exception à la règle parce que vous avez à utiliser le paradigme de la programmation orientée objet avec la qualité de l'Orm pour l'enregistrement de la manipulation, mais aussi le FP de la bonté de votre application de programmation.)
Flinkman
Points
4821
