Développement de logiciels axé sur le modèle Vs. Haskell

Question

Il suffit de lire l'article Wiki (allemand) sur le développement SW entraîné par le modèle (MDSD). Résumer la définition wiki:

• MDSD concerne le principe sec (ne vous répétez pas)
• Le MDSD concerne la conception des DSL (langues spécifiques au domaine) et des générateurs
• Une description plus concise des problèmes (à travers le niveau d'abstraction supérieur des DSL respectifs) est possible par le MDSD.

Puisque je connais et utilise une programmation fonctionnelle d'ordre supérieur, je me demande, et ma question réelle est: le MDSD n'est-il rien qu'une tentative désespérée d'injecter (une partie de) les fonctionnalités de programmation fonctionnelle de l'ordre supérieur dans les langages de programmation / paradigmes qui manquent intrinsèquement de l'ordre. ces fonctionnalités?

(Ou ai-je mal compris et que le MDSD pourrait même être utilisé pour soutenir considérablement la programmation fonctionnelle d'ordre supérieur?)

Answer 1

Je préfère le regarder l'inverse. OOP, MDSD, TDD, conception axée sur le domaine et les nombreux autres paradigmes ne sont que des paradigmes. Ce sont des moyens d'examiner la tâche de développement logiciel que les gens ont développé pour traiter les choses qu'ils percevaient manquant de tout ce qui les précédente. Il s'avère que la programmation fonctionnelle fait la même chose - elle donne au programmeur des pouvoirs d'abstraction qui ne sont pas élégants dans les langages qui n'ont pas de fonctions de première classe. Je ne dirais donc pas que le MDSD est une tentative désespérée de donner des fonctionnalités non fonctionnelles des fonctionnalités fonctionnelles autant que je dirais que ce sont des gens qui arrivent au même problème sous une perspective différente.

Certaines des réponses à cette La question récente a donc une façon différente de le dire. Shreevatsar dit: "Presque tout ce que vous pouvez faire avec les macros que vous pouvez faire avec une fonction d'ordre supérieur". Matthias Benkard dit: "Le manque de macros est quelque peu atténué par des concepts plus élaborés ... comme les monades et les flèches." D'autres commentaires font également écho au même thème. Vous mentionnez que l'un des principes du MDSD est les générateurs. Les macros sont des générateurs de compilation. Je traduireais donc leurs déclarations comme un argument selon lequel le MDSD est intrinsèquement facile dans les langages fonctionnels.

Answer 2

Il y a une différence majeure entre la fabrication d'un DSL (Langue spécifique au domaine) (FP) et créant tout un tas de Objets de domaine (OOP) (avec logique métier à l'intérieur des objets).

FP peut subir le même problème (et les avantages) que les langues procédurales: Séparation du comportement et des données. Les langues OOP découragent cela. Cette séparation est connue sous le nom Modèle de domaine anémique.

Cette "séparation" peut rendre la modification de vos données très difficile (et peut-être encore pire avec un DSL) voir mon message: Gestion des changements de modélisation de données incrémentielles dans la programmation fonctionnelle

Cependant, sur le comportement de changement de revers et avoir les choses sans état dans tous les domaines, il y a une douleur dans le cul avec une conception pilotée par le domaine OOP. Cependant avec des choses comme AOP ITD, et Méta-programmation Cela devient moins un problème.

Scala et Ruby sont un bel exemple d'un mélange des deux techniques.