Discussion :

[Jean-Marc.Bourguet]

Programming Paradigms for Dummies: What Every Programmer Should Know de Peter Van Roy.

[gorgonite]

comme toujours très intéressant

If you want to explore how to use different 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 ?

[Davidbrcz]

Comment peut on trouver de telle perle pas nous même ?

[SpiceGuid]

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 :

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

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.

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.

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 ?

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.

[gorgonite]

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 :

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]

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.

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 ?

[SpiceGuid]

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é.

[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]

Heureusement pour toi ça ne risque pas d'arriver.

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.

[Jean-Marc.Bourguet]

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 ?

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.

[gorgonite]

Je pensais à Java/C# ... La direction qui est prise c'est d'ajouter des featurettes venues d'autres horizons en prétendant que ça améliore l'expressivité.

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)

[*]un type flèche

la généralisation des monades ou juste le "->" des fonctions anonymes ?

[*]un type paire (notamment pour retourner deux valeurs)

je généraliserais aux tuples

[*]un type pointeur non-null

ç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)

[Jean-Marc.Bourguet]

Comment peut on trouver de telle perle pas nous même ?

Dans ce cas, ca vient de http://lambda-the-ultimate.org/ (qu'il me semble avoir déjà cité).

[Jean-Marc.Bourguet]

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.

[SpiceGuid]

la généralisation des monades ou juste le "->" des fonctions anonymes ?

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.

un type pointeur non-null

ça existe partiellement...

Merci pour tous ces liens.

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.

ils offraient à un moment donné une solution pragmatique à un problème pratique qui se posait à ce moment là.

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é.

Dans ce cadre, je crois 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.

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.

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 m'a l'air de recommander des langages qu'en tant qu'ils permettent d'explorer un ou une combinaison des paradigmes analysés.

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.

[gorgonite]

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é.

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

À 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.

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)

[Jean-Marc.Bourguet]

Algorithmiquement je trouve que les paradigmes ont tendance à se valoir,

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.

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.

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.

[gorgonite]

Si un paradigme n'admets que des structures non mutables, il y a une influence certaines sur les algorithmes possibles et la complexité de leur implémentation...

tout à fait, mais dans pas mal de cas, on a surtout une modification de la complexité spaciale, mais pas de la complexité temporelle (mergesort vs quicksort), voire uniquement un "basculement" de la complexité temporelle en complexité spaciale (packrat)

[alex_pi]

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...

Complexité dans quel sens du terme ? La complexité en temps de l'algo, ou la difficulté à l'implémenter ? Parceque *très souvent*, l'implem d'une structure en fonctionnel est largement simplifiée par rapport à une implem en impératif. Y a qu'à regarder le code d'un arbre rouge noir

[Jean-Marc.Bourguet]

tout à fait, mais dans pas mal de cas, on a surtout une modification de la complexité spaciale,

Ce qui, en passant, n'est pas quelque chose a negliger (je ne dis pas que tu le negliges, mais le "mais" que tu emploies peut donner l'impression que ce n'est pas important). Meme un facteur constant relativement faible en complexite spaciale peut faire la difference entre etre capable de traiter des donnees et ne pas etre capable de le faire sans se mettre a swapper de maniere inacceptable. Ce comportement est similaire au probleme des performances dans les systemes temps reels: tant qu'il est assez bon, on s'en fout plus ou moins, des qu'il n'est plus assez bon, c'est la cata.

[alex_pi]

Ce qui, en passant, n'est pas quelque chose a negliger

De même qu'il ne faut pas négliger l'avantage considérable à avoir une structure persistante et donc partageable à l'envie, sans avoir besoin de la recopier. Quand on "compare" les structures de données impératives ou fonctionnelles (j'emploie ces mots pour dire "mutable" et "non mutable", même si ce n'est pas forcément un bon choix), on pense généralement à une utilisation linéaire de la structure, c'est à dire que quand on obtient une nouvelle version, l'ancienne est perdu (par exemple si j'ai un ensemble E, que j'y ajoute un élément, j'ai accès à E' = E + {x}, mais plus à E lui même). Dans ce cas là effectivement, une structure mutable à de bonne chance d'être plus efficace. Mais si je veux conserver E, je suis obligé de dupliquer, alors qu'une structure fonctionnelle tentera généralement de maximiser le partage. Et là, il y a potentiellement énormément de place à gagner !

Comme toujours, aucune des solutions n'est adaptée à tous les problèmes, et il faut bien se garder de jeter trop rapidement les structures fonctionnelles, même quand on a des impératif de vitesse et d'usage mémoire.

[SpiceGuid]

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.

Avec l'habitude on peut tout exprimer à l'aide des types, les types sont bien plus proches des besoins. Il y a les types somme, les types produit, les types extensibles et les types non extensibles.

En Objective-Caml ça donne 4 possibilités avec diverses implantations :

1. variants (types somme)
2. tuples,records (types produit)
3. variants polymorphes (types somme extensibles)
4. classes,modules (types produit extensibles)

Le mot important c'est implantation, je ne veux pas savoir si c'est de la POO, de la programmation modulaire ou fonctionnelle, si conceptuellement c'est un type somme alors je pars sur des variants plutôt que sur des classes.

Parceque *très souvent*, l'implem d'une structure en fonctionnel est largement simplifiée par rapport à une implem en impératif.

C'est parce que ces langages t'obligent à utiliser un type produit extensible même quand un type somme serait plus indiqué. Quand tu ajoute de la mutabilité à un TAD immutable tu t'aperçois qu'en fait la modification est complètement mineure.

Version immutable :

Code OCaml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  type tree =
    node option
  and node =
    {
    left: tree; right: tree; height: int;
    item: item;
    }

  let rec add x = function
    | None ->
        {left = None; height = 1; right = None; item = x}
    | Some n -> 
        match Ord.compare x n.item with 
        | c when c < 0 ->
          let l = add x n.left in
          if l.height = height n.left then {n with left = Some l}
          else balanced (Some l) n n.right
        | c when c > 0 ->
          let r = add x n.right in
          if r.height = height n.right then {n with right = Some r}
          else balanced n.left n (Some r)
        | c ->
          {n with item = x}

Version mutable :

Code OCaml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  type tree =
    node option
  and node =
    {
    mutable left: tree; mutable right: tree; mutable height: int;
    mutable item: item;
    }

  let rec insert x = function
    | None ->
        {left = None; height = 1; right = None; item = x}
    | Some n -> 
        match Ord.compare x n.item with 
        | c when c < 0 ->
          let l = insert x n.left in
          if l.height = height n.left then (n.left <- Some l; n)
          else balance (Some l) n n.right
        | c when c > 0 ->
          let r = insert x n.right in
          if r.height = height n.right then (n.right <- Some r; n)
          else balance n.left n (Some r)
        | c ->
          n.item <- x; n

Evidemment, l'impact de la modification est majeure sur l'utilisateur du code. Toutefois, en terme d'implantation on voit bien que la différence est insignifiante pourvu qu'on ait pas la phobie de la récursion.

Ça n'est pas plus agréable en OCaml parce que OCaml est "fonctionnel" (ce qui ne veut rien dire). C'est plus agréable en OCaml parce qu'en Java tu n'as qu'une seule sorte de type là où en OCaml tu en as 4. Ça n'a pas de rapport avec l'(im-)mutabilité. Et je pourrais dire la même chose de Scala, il a beaucoup plus de types que Java, c'est ça qui lui donne ce parfum plus "fonctionnel".

La différence entre OCaml et Haskell ce n'est pas que Haskell a la paresse et que OCaml ne l'a pas. OCaml possède la paresse et le filtrage parresseux, ce que OCaml n'a pas ce sont les types co-récursifs, sans lesquels la paresse ne sert (presque) à rien.