Programming Paradigms for Dummies: What Every Programmer Should Know de Peter Van Roy.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Paradigmes de programmation
Programming Paradigms for Dummies: What Every Programmer Should Know de Peter Van Roy.
comme toujours très intéressant
If you want to explore how to use diff erent paradigms in one program, we recommend a multiparadigm language like Oz [34], Alice [38], Curry [4], or CIAO [23]. Each of these four has its own distinctive approach; pick the one you like best!
Si vous voulez explorer ces différents paradigmes dans un même programme, nous recommandons un langage multi-paradigme tel que Oz, Alice, Curry ou CIAO. Chacun d'entre eux possède sa propre approche, choissisez celui qui vous plaira le plus !
J'aimerais rebondir sur un point de leur conclusion pour demander s'il n'est pas surprenant de ne voir que des "langages de niche" dans un tel listing... cela signifie-t-il que vouloir mettre trop d'aspects au sein d'un même langage revient à créer une chimère inutilisable par le développeur lambda ?
Comment peut on trouver de telle perle pas nous même ?
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Dans ce cas, ca vient de http://lambda-the-ultimate.org/ (qu'il me semble avoir déjà cité).Envoyé par Davidbrcz
Juste un type fonctionnel. Parfois j'ai l'impression qu'on cherche à ajouter les closures pour dire qu'on a les closures mais qu'on ne pense pas à ajouter le constructeur de type correspondant ou qu'on l'ajoute mais pas de façon composable. Par exemple il y a le type flèche et le type générique, mais un type flèche n'admet pas d'arguments génériques et/ou un type générique n'admet pas le type flèche comme type réel.
Les types sont là mais ce sont des gadgets, on ne peut pas les utiliser à fond.
Du coup mieux vaut s'en passer plutôt que de se heurter à une limitation.
Un autre écueil c'est d'ajouter l'extension non pas à l'ensemble du langage mais uniquement à la partie qu'on trouve "intéressante", par exemple en Delphi 2009 il y a les types génériques pour les classes, mais pas pour les fonctions. Ça oblige à choisir entre la généricité ou les fonctions.
Plutôt que de vouloir embrasser tous les paradigmes de la création il vaudrait mieux arrêter d'ériger tout plein de barrières invisibles qui sont autant d'entraves.
Merci pour tous ces liens.ça existe partiellement...
Comme tu dis, tout cela est déjà disponible, partiellement, parce qu'on ajoute les fonctionalités tout en oubliant de moderniser les expressions de types en un nouveau langage plus cohérent et plus expressif.
C'est particulièrement vrai pour C et Java. Et ça serait vrai pour Lisp si l'éclatement de la bulle IA n'avait pas tout balayé.
Le parallélisme est une problématique transversale, ça n'est pas un nouveau marché. Dans la même lignée, la POO devait pousser de nouveaux langages (SmallTalk,Eiffel), au final elle n'a fait que mûrrir d'anciens langages (C/Pascal en C++/Object-Pascal). C'est le web qui a poussé Java, pas la POO, le web était un nouveau marché. À mon avis le parallélisme n'a aucun potentiel en matière de promotion et de renouveau des langages, c'est juste une dimension additionnelle dans l'évolution et le marketing des technos déjà existantes.
Algorithmiquement je trouve que les paradigmes ont tendance à se valoir, c'est le système de types qui fait que l'expérience de la programmation est radicalement différente d'un langage à l'autre.
plutôt d'accord... même si je dirais qu'on est passé du stade "Pascal, pas mal utilisé" au stade "Delphi, petite niche pour appli bon marché sur Windows"
faut dire que la politique si généreuse de Borland envers les étudiants avec son Turbo Pascal, a d'un coup basculé au passage à Delphi, et peut expliquer l'absence d'engouement pour Delphi des nouveaux arrivants
là en revanche, je ne suis pas d'accord... je pense au contraire qu'un langage facilitant les migrations des projets existants, et gérant convenablement de façon propre, élégante et LEGERE le parallélisme aurait une chance de percer s'il est appuyé suffisamment pour donner confiance aux gestionnaires (grosse entreprise derrière, forte implication communautaire avec vrai libre, etc)
Si un paradigme n'admets que des structures non mutables, il y a une influence certaine sur les algorithmes possibles et la complexité de leur implémentation...
De plus, un programme est plus qu'une implémentation d'un algorithme et les différents paradigmes diffèrent beaucoup quant à la manière dont les différents composants sont couplés.
Il ne faut pas tout voir à travers le système de type, ce n'est qu'un axe d'analyse. Je ne reprocherai pas à Pierce de ne pas traiter en profondeur les différents paradigmes, je ne reprocherai pas plus à Van Roy de ne pas traiter les types. S'il faut conclure quelque chose de la différence d'importance du traitement des paradigmes chez Pierce et des types chez Van Roy, c'est que les paradigmes sont plus fondamentaux car on peut ignorer beaucoup plus les systèmes de type en traitant les paradigmes que les paradigmes en traitant les types.c'est le système de types qui fait que l'expérience de la programmation est radicalement différente d'un langage à l'autre.
Si on regarde les textes des concepteurs dans les actes de les conférences de 'History Of Programming Languages, on voit que tous accordent une assez grande importance au hasard dans le succès de leur langage, en particulier qu'ils offraient à un moment donné une solution pragmatique à un problème pratique qui se posait à ce moment là. Aussi bons soient ils théoriquement, les autres langages n'ont guère qu'un succès d'estime même s'ils résolvaient mieux les problèmes qu'un langage arrivé pile au bon moment.
Dans ce cadre, je crois que qu'un problème à résoudre -- qui est connu depuis un certain temps -- qui permettra peut-être à un nouveau langage de se faire une belle place, c'est la gestion du parallélisme. Et si aucun ne s'impose relativement rapidement, la chose deviendra de plus en plus dure. Et je ne suis pas sûr que ce soit possible sans le support d'une companie derrière (les deux derniers langages à vocation généraliste qui ont réussit à sortir du lot ont été poussé par des sociétés avec un investissement important).
Dans les langages cités je ne connais un peu que Oz. C'est un langage et un environnement conçu pour l'expérimentation en matière de langages et d'environnement, par des gens faisant une telle expérimentation. Je ne le vois pas s'imposer beaucoup plus largement.
Fondamentalement, et bien que j'apprécie le multi-paradigme (surtout par facilité), je ne crois pas que ce soit le problème central dans la conception des langages les plus répandus.
Selon moi, le problème central dans la conception des langages courants c'est l'entêtement à ne pas améliorer et enrichir le système de types.
L'auteur semble ignorer cette importance capitale du système de types.
Du coup il en arrive à une conclusion assez disqualifiante :
où chaque langage cité est réduit à une caractéristique anecdotique de sorte qu'on se demande bien pourquoi on devrait l'utiliser hors circonstances exceptionnellement exotiques.we recommend Haskell for lazy functional programming, Erlang for message-passing concurrency, SQL for transactional programming, Esterel for discrete synchronous programming, and Oz for declarative concurrency and constraint programming
Les langages modernes devraient assumer leur paradigme plutôt que de pêcher des idées à droite et à gauche pour avoir l'air le plus feature-full. Ils ne le font pas parce qu'améliorer le système de types c'est assurément invalider tout un tas de pratiques hasardeuses. Il est plus consensuel de mal combler des manques imaginaires que de bien corriger des fautes avérées.
Tout à fait d'accord avec toi. L'auteur n'a pas compris pourquoi OCaml ou Haskell sont de bons langages et pourquoi quasiment personne n'utilise Oz ou Alice.
je dirais que même si j'apprécie énormement le typage statique tres fort, je ne pense que ce soit pour autant la panacée, la solution qu'il faut chercher à appliquer à tout prix dans les nouveaux langages. enfin beaucoup de langages existants feraient bien d'y penser, car leur faiblesse de type n'apporte pas forcemment un plus
[troll]
sinon on va finir par tous coder en Coq... il est clair qu'on y gagnera en plus la preuve de son implantation (et je serais au chômage)
[/troll]
effectivement, mais peut-être rêvent-ils encore d'un langage universel, malgré les échecs cuisant de Ada et PL/I en leur temps ?
----------------
perso, ce que je trouve dommage, c'est l'absence de tentative de vulgarisation réelle de l'article... excepté Java et SQL, je pense que 95% des membres de ce forum ignorent tout des autres langages cités
d'ailleurs j'ai survolé rapidement la partie "concurrence" où ils parlent de CSP, mais aucune allusion à CCS (Ada s'en est inspiré je crois, ça fait quand même une application majeure), étrange quand même?
Je pensais à Java/C# ce sont de facto des langages fortement typés, donc la question ne se pose pas de savoir si c'est un bon choix ou pas. La question c'est comment faire évoluer leur système de types pour améliorer le style des programmeurs POO. Or ce n'est pas cette direction qui est prise. La direction qui est prise c'est d'ajouter des featurettes venues d'autres horizons en prétendant que ça améliore l'expressivité.
Heureusement pour toi ça ne risque pas d'arriver.[troll]
sinon on va finir par tous coder en Coq... il est clair qu'on y gagnera en plus la preuve de son implantation (et je serais au chômage )
[/troll]
Je pense à des choses plus bénignes :
- un type générique (ok, ça existe déjà, mais c'est récent)
- un type flèche
- un type paire (notamment pour retourner deux valeurs)
- un type pointeur non-null
Ça bousculerait déjà pas mal de choses, dans le bon sens.
ok en ce qui concerne Java, mais côté C#, je pense qu'un ajout comme la contravariance (pour en savoir plus) et les paramètres nommés sont des ajouts importants... car ils permettent d'introduire "derrière" bien plus de rigueur lorsque c'est bien fait
après, l'ajout des objets dynamiques (pour en savoir plus), est une avancée majeure pour .Net qui s'ouvre ainsi réellement sur les langages dynamiques et évite de juste embarquer un interprète (comme Perl.Net ou les JPython/Ruby)
la généralisation des monades ou juste le "->" des fonctions anonymes ?
je généraliserais aux tuples
ça existe partiellement... cf Spec# pour C# et ceci pour Java
perso, je trouve qu'il est également agréable de disposer d'un préprocesseur "puissant" (pas uniquement des macros à la C, voire même un peu plus que de simples templates à la C++ qui n'arrive à gérer les vtable Qt)
SpiceGuid, je n'ai guère eu le temps que de parcourir le texte, mais je crois que la question du système de type est tout simplement indépendante de l'axe d'analyse dans ce papier. Il me m'a l'air de recommander des langages qu'en tant qu'ils permettent d'explorer un ou une combinaison des paradigmes analysés.
Répondre avec citation
Partager