Discussion :

[limestrael]

Bluestorm, Jedai : Pour éviter de continuer le HS, j'ai poursuivi la discussion
ici : http://www.developpez.net/forums/d78...l/#post4535205

Comme d'autres l'ont déjà dit, la question de la performance ne se pose pas vraiment pour Oz/Mozart dans le sens où la performance ici c'est d'intégrer harmonieusement plusieurs paradigmes (dont certains à usage assez spécialisé) dans un langage noyau très cohérent.

Dans le cas où Oz te faciliterait la recherche opérationnelle en fournissant de meilleurs outils pour restreindre l'espace de recherche, tu réaliserais vite qu'un facteur 5, 10 ou 20 sur les performances n'est qu'une constante, ça compte toujours moins qu'une exponentielle.

Sinon, dans le cas où tes programmes sont plus calculatoires qu'exploratoires l'intérêt de Oz/Mozart devient plus éducatif que pratique.

Effectivement, au final, Oz me semble pas mal appréciable pour son côté éducatif très important, mais dans ce cas, quid de ses applications Real World ?

[Jedai]

Désolé du lapsus, je voulais dire "utilisé dans l'éducation". Et, pour voir des gens qui utilisent encore Caml Light à grande échelle, je sais que dans l'éducation on reste souvent coincé avec des solutions logicielles du siècle précédent :p

Je sais bien, d'ailleurs je n'ai pas dit qu'Hugs n'était plus utilisé, j'ai dit qu'il n'y avait plus de raison valable de l'utiliser. Et je pleure avec toi l'horrible erreur de conserver Caml Light en classe prépa.

GHCI est quand même inutilisable, dans le sens où on ne peut pas faire de Haskell sérieux dedans. Tu connais sûrement le toplevel OCaml, c'est le jour et la nuit à côté.

Le toplevel OCaml doit impérativement être enrobé d'une interface plus sympathique pour être utilisé confortablement toutefois, en face de ça GHCi est nettement plus utilisable directement.

GHCi est très bien pour demander le type d'une fonction ou la kind d'un type, en gros il joue le rôle de substitut de lambdabot en local, avec cependant beaucoup moins de features. Par contre dès que tu veux déclarer des fonctions et jouer un peu, c'est la fin des haricots.

Je ne suis pas tout à fait d'accord, il fonctionne très bien pour ce que tu décris, c'est juste que tu es dans la monade IO, donc la syntaxe est différente, mais Hugs ne gère pas ça mieux... Par ailleurs, le principal rôle d'une REPL pour moi, c'est de jouer et tester les fonctions déjà écrites, pas d'écrire des nouvelles fonctions de 10 lignes.
Par contre GHCi a d'autres réelles faiblesses : le non support de la totalité des syntaxes d'import (en particulier qualified) et l'impossibilité d'y déclarer des types ou des instances.

D'une part la syntaxe n'est pas la même que dans du code normal (introduction des let, super pour le débutant...), en plus il ne type pas pareil (genre tu te fais rejeter sur des type-classes, tu commences à flipper sur la monomorphism restriction, avant de te rencontre que dans un .hs normal ça type exactement comme tu veux), etc. Pour moi c'est pas utilisable.

Il type pareil, il a juste moins de contexte pour ce faire que dans un .hs normal, donc il doit parfois faire des choix moins optimaux. Désactiver la restriction monomorphique dans GHCi est un bon choix pour éviter de se casser la tête (et dans GHCi, le principal désavantage de ce choix, réduction des performances, n'est pas la préoccupation première.

Par contre je suis d'accord que c'est perturbant pour le débutant de découvrir une syntaxe différente du top level d'un .hs, surtout qu'il ne connaît généralement pas encore la syntaxe dans un do-block à ce stage.

Il ne devrait pas être trop difficile de simuler une syntaxe de top-level par une surcouche cependant, surtout avec l'excellent haskell-src-exts, peut-être que j'essaierais de faire quelque chose dans ce sens d'ici la fin de l'été.

on peut éviter le HS ? parce que Haskell c'est merveilleux, mais ce n'est pas Oz... et donc il va falloir scinder la discussion

Ok, mais comment assurer la transition ?

--
Jedaï

[limestrael]

Ok, mais comment assurer la transition ?

Je viens de le dire, j'ai poursuivi la discussion ici : http://www.developpez.net/forums/d78...l/#post4535205
C'est pas ce qu'on pouvait faire de mieux, mais bon, tant pis...

[Oscar Hiboux]

Punaise ! Qu'est-ce qu'il ne faut pas lire ! Désolé d'intervenir mais j'ai le poil qui vient de se dresser d'un coup en lisant :

[..*]quicksort de 5 ou 6 lignes. Il est classe, abstrait car exprimé d'une manière quasi-humaine et mathématique[...]

Quasi-humaine disais-tu ? Aïe, rassure moi, tu exagérais (BEAUCOUP)...

Je suis tombé au hasard sur ce fil et je trouve la discussion plutôt intéressante. Je ne connais absolument pas Haskell et je n'ai pas envie de le qualifier pour cette unique raison. Par contre, il me semble bien que le but d'un langage de programmation, voire son essence, est quand même bien de rapprocher l'homme de la machine, non ?

Réduire le nombre et la taille des instructions, et symboles, de façon malsaine va complètement à contre-courant ! Un langage de programmation est avant tout au service de l'Homme, pas l'inverse... Savoir comment fonctionne la chaîne de communication entre le cerveau de l'Homme et celui de sa machine, oui. Mais se mettre au service d'un agent de cette chaîne (compilateur par exemple), non. À partir de là, pour moi et certainement pour un certain nombre de programmeurs, il y a un pépin.

En avant dans la lutte contre l'apparition des cheveux blancs !

[Jedai]

Je suis tombé au hasard sur ce fil et je trouve la discussion plutôt intéressante. Je ne connais absolument pas Haskell et je n'ai pas envie de le qualifier pour cette unique raison. Par contre, il me semble bien que le but d'un langage de programmation, voire son essence, est quand même bien de rapprocher l'homme de la machine, non ?

Non ? Pourquoi voudrais-t-on rapprocher l'homme de la machine ? Faciliter la communication des intentions de l'homme vers la machine, certes, rapprocher la machine de l'homme (IA) sans doute, mais rapprocher l'homme de la machine...
Ou alors je ne comprends pas ce que tu veux dire par là, pourrais-tu préciser ta pensée ?

Réduire le nombre et la taille des instructions, et symboles, de façon malsaine va complètement à contre-courant ! Un langage de programmation est avant tout au service de l'Homme, pas l'inverse...

Un homme au service d'un langage ? Tu veux dire mettre l'homme au service de la machine, non ? Dans ce cas les langages fonctionnels sont particulièrement au service de l'homme au contraire puisqu'ils sont de la famille dite déclarative où tu décris ce que tu veux faire plutôt que de dire à la machine quels étapes exactes elle doit effectuer.
Je ne vois pas ce que tu veux dire par réduire le nombre et la taille des instructions de façon malsaine, tu préfèrerais un langage inexpressif qui exige des centaines de lignes pour exprimer le quicksort ? La version Haskell du quicksort est l'une des plus claires du point de vue humain que j'ai jamais vu.

Savoir comment fonctionne la chaîne de communication entre le cerveau de l'Homme et celui de sa machine, oui. Mais se mettre au service d'un agent de cette chaîne (compilateur par exemple), non. À partir de là, pour moi et certainement pour un certain nombre de programmeurs, il y a un pépin.

On peut difficilement dire que les langages fonctionnels se mettent au service du compilateur ou d'une autre partie de cette chaîne : au contraire les langages fonctionnels ont une logique très différente du hardware actuel, donc les compilateurs doivent faire des efforts fous pour obtenir des performances potables à partir d'un programme fonctionnel. Haskell est encore pire que le langage fonctionnel type, avec son évaluation paresseuse...
L'une des raisons de la mauvaise réputation des langages fonctionnels auprès des industriels est que pendant très longtemps les compilateurs obtenaient des résultats déplorables comparés à l'impératif, il y a eu beaucoup de boulot pour arriver à un GHC qui compile des programmes Haskell de haut niveau vers des exécutables comparable à du C à un ordre de magnitude près (et certains programmes avec des performances équivalentes à du C).

--
Jedaï

[limestrael]

Punaise ! Qu'est-ce qu'il ne faut pas lire ! Désolé d'intervenir mais j'ai le poil qui vient de se dresser d'un coup en lisant :


Quasi-humaine disais-tu ? Aïe, rassure moi, tu exagérais (BEAUCOUP)...

Pas tant que ça, figure-toi :

Code :

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

1
2
3
4
5
6
qsort [] = []
qsort (x:xs) =
    qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
    where
        elts_lt_x = [y | y <- xs, y < x]
        elts_greq_x = [y | y <- xs, y >= x]

Ca c'est très proche d'une définition telle que :

Code :

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

1
2
3
4
5
6
7
qsort(liste) = listeVide si liste est vide
               nouvelleListe(qsort(plusPetitQueX), singleton(x), qsort(plusGrandQueX)) si liste n'est pas vide
      tel que : x = tête de liste
                xs = reste de la liste
                plusPetitQueX = y  ∀ y∈xs | y < x
                plusGrandQueX = y  ∀ y∈xs | y >= x

Et ça, c'est la définition matheuse d'un quicksort.

Et en français

Le quicksort d'une liste vide, c'est une liste vide.
Le quicksort d'une liste L non vide, c'est une liste qui est la concaténation du quicksort des éléments de L inférieurs à x, de x lui même, et du quicksort des éléments supérieurs ou égaux à x, sachant que x est le premier élément de L.

Admets qu'il y a quand même de GROSSES similitudes.

Au passage, je me permets de vous signaler qu'on dérive encore et que gorgonite ne va pas aimer ça...

[Oscar Hiboux]

J'imagine qu'avec l'habitude ça doit être plus évident mais avec un regard complètement neuf ça l'est déjà moins. J'admets cependant qu'il y a de bonnes analogies avec la description mathématique. Pour ce qui est du rapprochement avec l'humain je reste très sceptique.

[limestrael]

Pour ce qui est du rapprochement avec l'humain je reste très sceptique.

C'est juste une question de syntaxe, et non de logique.
Relis ma définition du quicksort "littéraire", tu verras qu'elle colle avec le code Haskell.

[Jedai]

J'imagine qu'avec l'habitude ça doit être plus évident mais avec un regard complètement neuf ça l'est déjà moins.

C'est certain, une syntaxe ça s'apprend de toute façon. Mais imagine toi lire un quicksort en C avec un regard complètement neuf, est-ce que tu penses que l'algorithme sous-jacent sera plus ou moins évident que dans la version Haskell ?

--
Jedaï

[Oscar Hiboux]

Faciliter la communication des intentions de l'homme vers la machine, certes, rapprocher la machine de l'homme (IA) sans doute, mais rapprocher l'homme de la machine[...]

Voilà, c'est mieux dit ainsi ! C'est bien la direction Homme - machine dont on parle.

[...]les langages fonctionnels sont particulièrement au service de l'homme au contraire puisqu'ils sont de la famille dite déclarative où tu décris ce que tu veux faire plutôt que de dire à la machine quels étapes exactes elle doit effectuer.

En effet, sur cet aspect on tente de se rapprocher du raisonnement humain, mais essentiellement pour tout ce qui est de la résolution de problèmes logiques / mathématiques, non ?

Je ne vois pas ce que tu veux dire par réduire le nombre et la taille des instructions de façon malsaine, tu préfèrerais un langage inexpressif qui exige des centaines de lignes pour exprimer le quicksort ?

Des centaines de lignes pour un quick-sort ? Allons... J'ai employé le terme "malsain" car en lisant le fragment de code j'ai eu l'impression que l'objectif était d'en dire le plus en le moins de caractères possible, ceci menant à une illisibilité non justifiée. Dans le fond, c'est sans doute une des meilleures manières de l'écrire dans ce langage mais je ne trouve vraiment pas ça lisible.

On peut difficilement dire que les langages fonctionnels se mettent au service du compilateur ou d'une autre partie de cette chaîne

Ce n'est pas ce que j'ai dit. Je soulignais l'inconvénient d'avoir à formuler d'une manière ou d'une autre ses instructions afin de profiter pleinement des performances du compilateur.
Pour le reste, en effet, ça doit être tout un défi d'écrire de tels compilateurs ! Chapeau à ceux qui les développent et les optimisent !

[Oscar Hiboux]

Mais imagine toi lire un quicksort en C avec un regard complètement neuf, est-ce que tu penses que l'algorithme sous-jacent sera plus ou moins évident que dans la version Haskell ?

C'est difficile de répondre objectivement mais je pense que oui, car - arrêtez moi si je me trompe - en Haskell on décrit par des syntaxes proches des mathématiques. Par conséquent, si on ne pense pas à cette syntaxe mathématique (que tout le monde ne maîtrise pas, ou plus très rapidement une fois que l'on arrête de cirer les bancs d'école), on a du mal à suivre l'auteur. En revanche, en C on développe une séquence d'instructions, plus verbeuse, ce qui, je pense, sied à plus de personnes.

C'est juste une question de syntaxe, et non de logique.
Relis ma définition du quicksort "littéraire", tu verras qu'elle colle avec le code Haskell.

Oui, en effet, elle colle bien avec la description mathématique du problème.

[gasche]

Oui enfin avec un raisonnement comme ça on coderait tous en COBOL. Objectivement les manipulations d'indices des implémentations impératives sont beaucoup moins lisibles (et d'ailleurs beaucoup plus efficaces aussi), la définition Haskell est beaucoup plus déclarative (conceptuellement, indépendamment de la syntaxe utilisée, si on remplaçait [x | ...] par (all x such that ...) ce serait ptet plus lisible mais exactement le même programme) donc donne moins de travail au programmeur et plus à l'ordinateur.

Après on peut discuter pendant des années de "quelle est la syntaxe que les gens devinent de manière innée alors qu'ils ont jamais touché à un ordinateur", à mon avis aucune plus qu'une autre, et d'ailleurs les recherches que j'aie vues sur l'apprentissage de la programmation aux débutants convergent vers le fait que l'important c'est pas de deviner ce que les trucs veulent dire (on ne peut pas), mais de comprendre qu'il y a une signification et qu'elle est cohérente tout au long du code.
Pour les aspects pratiques, je pense qu'il y a beaucoup plus de problèmes avec les gens qui se demandent "pourquoi i = 0 ? Et si i n'est pas égale à 0 il se passe quoi ?" en C que sur la notation des compréhensions. Quand on parle de mauvaises notations, utiliser "=" pour l'assignation c'est quand même le summum.

[limestrael]

Post très éclairé, bluestorm

Oui enfin avec un raisonnement comme ça on coderait tous en COBOL.

Ca fait froid dans le dos...

Objectivement les manipulations d'indices des implémentations impératives sont beaucoup moins lisibles (et d'ailleurs beaucoup plus efficaces aussi)

Et surtout plus prédisposées aux bugs. (Oh, ben mince, j'essaie d'accéder à une case de mon tableau qui n'existe pas... Segfault)

la définition Haskell est beaucoup plus déclarative (conceptuellement, indépendamment de la syntaxe utilisée, si on remplaçait [x | ...] par (all x such that ...) ce serait ptet plus lisible mais exactement le même programme) donc donne moins de travail au programmeur et plus à l'ordinateur.

Exact. Il y a des types qui visiblement croient que coller dans un langage des "begin", des "end", en gros tout un tas de tokens qui ne servent à rien pour le compilateur (en tous cas qui ne lui servent pas plus que des accolades ou des points-virgule) rendent le programme plus facile à lire. C'est faux, peut-être que ça rend la syntaxe un tout petit peu plus intuitive au début, mais en tout cas ça l'alourdit violemment, et une fois qu'on s'y est fait, on est bien content de pouvoir simplement taper '|' au lieu de 'foreach' par exemple, ou de ne pas avoir à taper systématiquement des 'end'.

Quand on parle de mauvaises notations, utiliser "=" pour l'assignation c'est quand même le summum.

Yes it is.
+1.

[Oscar Hiboux]

Je ne sais pas trop pourquoi vous parlez de COBOL et j'ai l'impression que l'on s'égare beaucoup. Pour le reste il me manque les rudiments que vous avez en Haskell pour bien saisir de quoi vous parlez, mais tant qu'on en parle, oui, begin / end c'est plutôt immonde...

Pour l'assignation je suis bien d'accord, héhé - les plus "marrants" étant == et ===

Par curiosité, limestrael, en quoi Haskell protège le développeur de faire des accès "illégaux" dans des tableaux ?


(P.S. : mon langage préféré ces temps-ci c'est l'ECMA)

[gasche]

Personellement je n'ai rien contre les begin/end. Les syntaxes purement symboliques ont aussi leur défauts (il est effectivement plus difficile de découvrir leur signification sans se documenter si elles sont trop utilisées, et elles réduisent beaucoup la liberté de choix syntaxique pour les constructions suivantes du langage). Ce que je voulais dire c'est que la syntaxe concrète d'un langage (le fait de savoir si on utilise [ ], { } ou begin end par exemple) reste un artifice assez secondaire, et que si on veut vraiment comparer deux codes différents, il faut se concentrer sur leur contenu, et non leur forme.

Si j'ai cité Cobol c'est parce que c'est un langage qui a fait le pari d'une syntaxe très très verbeuse, pour pouvoir être utilisée par les "non scientifiques" (par opposition aux autres langages de l'époque qui étaient quasi-exclusivement reservés aux applications scientifiques) et qu'il se révèle à l'usage que ce n'est pas tellement agréable à utiliser. Il faut trouver un compromis entre la clarté et la concision de la syntaxe, et optimiser l'une des variables sans considérer l'autre ne peut rien donner de bon.

Pour répondre à ta question : ici on manipule directement des listes à la place des tableaux, donc il n'y a plus de problématique des accès. C'est pas une solution miracle mais effectivement les accès illégaux arrivent moins dans les langages qui encouragent l'utilisation d'autres structures de données.

Après, pour ce qui est de la question spécifique des accès aux tableaux, on peut faire faire ce travail en grande partie par le compilateur, en déployant des techniques de typages très lourdes. Si ça t'intéresse vraiment, tu peux regarder ici, mais c'est assez technique et pas vraiment utilisable dans les langages "mainstream" (Haskell inclus) pour l'instant.