Version imprimable
Bonjour tout le monde, je debute dans la programmation fonctionelle et j'ai besoin de votre aide, si vous le pouvez bien sur, sur quelque chose. J'aimerai avoir un tableau comparatif complet entre ces Scheme, Ocaml, lips et prolog, SVP. Si quelqu'un a un lien interessant, ca sera sympa de me le passer.
Un trés grand merci d'avance à tout le monde.
Déjà Prolog n'est pas un langage de programmation fonctionnel, mais logique, ce qui est complètement différent (le seul point commun ou presque c'est que ce sont tout deux des paradigmes de programmations qui ne sont pas bien connus du "grand public" des programmeurs au jour d'aujourd'hui).
Tu devrais peut-être considérer Haskell également dans tes choix de langage fonctionnel.
--
Jedaï
Tout dépend de ce que tu veux faire.
Veux-tu simplement jouer avec ? Changer de langage de programmation et en faire ton premier langage ? Apprendre sans en être u expert ?
Si tu n'as pas d'obligation de travail avec Lisp ou Scheme, je te conseille de les oublier : leurs concepts sont assez lointains de ceux de Haskell et OCaml (entre autres, le typage).
OCaml et Haskell sont les deux seuls langages qui aujourd'hui bénéficient d'un soutien suffisant pour programmer une application entière (de la tête aux pieds j'entends).
OCaml est un langage fonctionnel strict fortement typé, avec lequel on peut aussi faire de la programmation impérative, objet-impérative, et (beaucoup plus rare) objet-tout-fonctionnelle. Sa force réside dans le fait qu'il est multi-paradigmes, et il est donc rare pour un nouveau venu de s'y perdre.
Haskell est fonctionnel pur, paresseux et fortement typé au sens des classes de types Haskell (un truc propre à ce langage). Il est extrêmement intéressant, théoriquement parlant, mais plus difficile à apprendre, notament à cause des concepts de classes de types et des monades. Cependant, il possède un avantage par rapport à OCaml : il est plus petit, et on peut raisonnablement espérer l'avoir appris en quelques mois, voire quelques semaines... ce qui n'est absolument pas le cas d'OCaml, si tu as envie de le maîtriser à fond !
Concernant les implantations de ces langages, OCaml est un langage à implantation unique : c'est l'équipe GALLIUM de l'INRIA qui s'en charge désormais. Haskell, par contre, est implanté par de nombreuses équipes et parmis elles, les universités les plus prestigieuses anglo-saxones : Glasgow avec GHC, Yale avec Yhc, Nottingham avec Nhc, et autres... De tous, GHC l'emporte haut la main, bien que Hugs soit meilleur pour apprendre le langage (car beaucoup plus simple).
De façon générale, on peut dire que, quelque soient les implantations de Haskell, l'implantation du langage OCaml est beaucoup plus mature ; entre autres, son système de Garbage Collector est envié de tous, l'architecture des compilateurs est bien meilleure (car ils peuvent compiler vers beaucoup d'architecture différentes, ce qui n'est pas le cas de Haskell, x86-minded), et les performances supérieures.
Le gros avantage de Haskell est aujourd'hui sa communauté, anglo-saxone (mais combien sommes-nous de Français sur le Haskell-wiki, 10 ? 20 ?), très dynamique et surtout très sympathique.
C'est un reproche très vif que je fais-là envers OCaml, dont la communauté est quasi-inexistante, ou alors constituée de deux ou trois normaliens ne regardant que la théorie et ne prêtant pas attention au noble Art de la programmation.*
Voilà, si tu veux en savoir plus...
Citation:
Envoyé par InOCamlWeTrust
je ne suis pas totalement d'accord, il existe de nombreuses librairies et projets en haskell dont les performances sont proches (et même parfois supérieures) à ce qu'un code c++ tout à fait correct réussit à faire... et haskell est bien plus concis ;)
en caml, on obtient souvent des bonnes performances, en passant une partie des opérations en impératif, et en utilisant des structures de données modifiables sur place... même si le coeur du programme est fonctionnel, toutes les parties critiques pour les performances ne le sont pas toujours :?
En fait, je veux concevoir et implementer un nouveau moteur d'inference, c'est pour ca qu'avant tout je dois etudier ce qui existe deja pour prendre une petite idée de depart.Citation:
Envoyé par InOCamlWeTrust
Encore merci de m'avoir parlé de haskell car je le connaissais pas avant.;)
Citation:
Envoyé par ThE_LaSt
un moteur d'inférence... ben au choix ocaml ou haskell
tu veux te recoder un prolog ? ou un système de types ?
Pas du tout d'accord.Citation:
Envoyé par InOCamlWeTrust
D'abord le fait que les concepts de Scheme puissent être lointain de ocaml (par exemple, ceux sur quoi je ne suis pas complètement d'accord non plus) n'implique absolument pas le fait qu'il faille oublier Scheme.
Ensuite, il existe bien des choses en Scheme qui permettent de dire qu'il a un soutien important et qu'il peut permettre de programmer une application complète. Les compilateurs sont devenus très performants d'ailleurs.
Stalin par exemple est même devenu quasiment plus performant que ocaml sur certaines parties
(ici on parle de ray tracer source)Citation:
Static type information greatly facilitates optimization. The OCaml, C++ and Standard ML languages all expose static type information to the compiler, resulting in much faster programs. The Stalin Scheme compiler goes to great lengths to infer static type information, resulting in faster programs at the cost of vastly slower compile times.
Finalement le langage de macro de Scheme est un plus qui n'existe pas dans ocaml ou Haskell (à ma connaissance en tout cas). La facilité et la puissance d'utilisation des macros sont incomparables à tout ce que je connais ailleurs.
Bon je ne vais pas faire un exposé de 100 lignes, mais disons qu'il est simplement faux de dire que ocaml permet de faire des applications sérieuses et est meilleur que scheme. Il y a certes des différences, des points faibles à l'un et à l'autre, mais les deux sont fortement intéressants car leurs points forts méritent le détour.
Connais tu vraiment Scheme mon cher IOCWT ?
Sinon tu ne devrais pas être aussi expéditif à son égard.
Ou alors, tu te ranges dans la même catégorie de ceux qui juge vite ocaml sans le connaître.
Ou Scheme -_-Citation:
Envoyé par gorgonite
Le livre de Chazarin (Programmer avec Scheme) en a même une partie sur les systèmes experts et la programmation logique qui pourrait t'aider.
Cependant si tu veux faire un système dans ce genre pourquoi ne pas simplement utiliser du Prolog ?
C'est marrant, j'ai exactement l'impression inverse !Citation:
Cependant, il possède un avantage par rapport à OCaml : il est plus petit, et on peut raisonnablement espérer l'avoir appris en quelques mois, voire quelques semaines... ce qui n'est absolument pas le cas d'OCaml, si tu as envie de le maîtriser à fond !
D'une part, j'ai l'impression que la transition <langage impératif> -> OCaml est assez "simple" : il "suffit" d'apprendre les bases de l'approche fonctionnelle et des langages typés (récursivité, structures non mutables privilégiées, types algébriques, composition de fonctions (s'habituer à manipuler map/fold/filter par exemple)...), et on maîtrise les concepts principaux de Caml (bon, il reste des aires de richesse à explorer, comme l'Objet, les modules, et d'autres trucs, mais on a vraiment saisi le principal à mon avis).
Si on passait directement d'un langage impératif à Haskell, j'ai l'impression que la transition serait beaucoup plus violente : on se retrouve à devoir assimiler au moins tous les concepts que j'ai cité plus haut, avec en plus l'évaluation paresseuse, et le fonctionnel pur, donc les monades (bonjour le "Hello World" en Haskell...).
Dans l'ensemble, je trouve les règles du Haskell plus complexes que celles du Caml. Il suffit de regarder par exemple les règles du filtrage de motif, il y a tout un tas de subtilités (la gestion de la paresse, de la divergence, etc...), de questions qui ne se posent pas en OCaml.
Enfin, la différence de "taille" entre les langages est difficile à comparer. Si on se limite à Haskell 98 ce n'est pas si énorme en effet (bien que déjà conséquent je pense, par rapport à Caml Light), mais dès qu'on entre dans les extensions de GHC/Hugs, l'enfer commence. Types algébriques généralisés, Phantom types, toute la magie autour du système de typage (au moins les camliens essaient de conserver l'inférence de type, ce qui les limite un peu niveau expérimentations de typage complètement dingues),
SYB, Arrows...
Rien que comprendre et assimiler les types classes dans l'ensemble, et les monades en particulier, ça prend sûrement (à une personne un peu normale) plus que quelques semaines.
En bref, je ressens plutôt une complexité plus forte du côté Haskell.
J'ai beaucoup appris de vous les gars ! Mais, svp, est ce que personne n'aurait un lien comparatif complet sur ces differents language ?
Citation:
Envoyé par bluestorm
C'est difficile ça ?Code:
2
3
On n'est pas obligé de tout comprendre d'un coup, utiliser la monade IO sans la comprendre n'est pas très difficile. D'ailleurs les monades ne sont pas si dures à comprendre, ce qui est difficile c'est de se mettre à "raisonner monade". Une bonne introduction aux monades ne demande vraiment pas d'être un master en Informatique Théorique.
L'évaluation paresseuse est très intéressante mais elle n'empêche pas d'écrire les mêmes programmes qu'avec l'évaluation stricte, on peut se familiariser progressivement avec elle et étendre ses horizons.
Bien sûr le contact avec le fonctionnel pur peut se révéler rude pour un vétéran de l'impératif, mais au moins avec Haskell il est forcé de s'y mettre vraiment, il ne peut pas écrire du petit-nègre de fonctionnel avec de gros bout d'impératif comme en OCaml (je ne dénigre pas OCaml : pour les connaisseurs du langage le multi-paradigme offre d'innombrables opportunités mais pour un débutant qui essaye d'apprendre le fonctionnel en venant de l'impératif, ça peut-être un inconvénient...).
Bof...Citation:
Dans l'ensemble, je trouve les règles du Haskell plus complexes que celles du Caml. Il suffit de regarder par exemple les règles du filtrage de motif, il y a tout un tas de subtilités (la gestion de la paresse, de la divergence, etc...), de questions qui ne se posent pas en OCaml.
Ca par contre c'est incontestable, le nombre d'extension du système de type en Haskell est effarant ! Et un peu difficile à avaler en une fois... Mais on n'y est pas obligé non plus.Citation:
Enfin, la différence de "taille" entre les langages est difficile à comparer. Si on se limite à Haskell 98 ce n'est pas si énorme en effet (bien que déjà conséquent je pense, par rapport à Caml Light), mais dès qu'on entre dans les extensions de GHC/Hugs, l'enfer commence. Types algébriques généralisés, Phantom types, toute la magie autour du système de typage (au moins les camliens essaient de conserver l'inférence de type, ce qui les limite un peu niveau expérimentations de typage complètement dingues),
SYB, Arrows...
C'est quoi une personne "un peu normale" ? Je n'ai pas l'impression que la mécanique des type class ou des monades soit si compliquée qu'il faille plus d'une petite semaine pour les comprendre. Après, apprendre à raisonner avec, à repérer les endroits où ces concepts vont énormément nous simplifier la vie ou même à comprendre certains des codes qui les utilisent, certes cela prendra bien plus de temps (et le "bien plus que quelques semaines" est sans doute optimiste si on se place dans cette optique).Citation:
Rien que comprendre et assimiler les types classes dans l'ensemble, et les monades en particulier, ça prend sûrement (à une personne un peu normale) plus que quelques semaines.
En bref Haskell98 ne me paraît pas si compliqué à apprendre, apprendre à l'utiliser à plein et comprendre ses diverses extensions est par contre beaucoup plus difficile et lent.
--
Jedaï
Est ce que vous avez ce livre en version numerique svp ? Si oui, vous pourriez me l'envoyer ? MerciCitation:
Envoyé par Garulfo
Citation:
Envoyé par Garulfo
perso, j'ai lu le Structure and Interpretation of Computer Programs de Adelson & Sussman, et j'ai à l'époque fait pas mal d'essais avec ce langage (des petits trucs certes, mais pas mal quand même... :roll:)
je suis aujourd'hui convaincu de la supériorité d'Haskell et OCaml sur Scheme (mais ce n'est que mon opinion ;))
par ailleurs, j'ai entendu beaucoup de biens sur les performances de la compilation par Stalin, et beaucoup de mal quand à sa lenteur... qui le rendrait inutilisable sur un projet un peu ambitieux :aie:
Citation:
Envoyé par Garulfo
faire un moteur d'inférence en prolog revient à l'utiliser normalement, ou à faire de la méta-programmation pour spécifier l'ordre d'évaluations des clauses dans son solveur perso ;)
j'ai déjà fait... c'est rapide, mais pas très instructif sur le fonctionnement d'un moteur d'inférence ;)
Oui : c'est comme celui qui implante du lambda-calcul en OCaml...
En France, j'ai rarement vu des gens programmer intensivement en Scheme... si j'avais dû donner un conseil à un anglo-saxon, j'aurais dit l'inverse.Citation:
Envoyé par Garulfo
OCaml est plus adapté à faire une application entière car de par sa conception, il est tout-terrains : analyse de langages, preuves formelles, programmation mathématique, interfaces graphiques (même si ça reste encore un tout petit peu son talon d'Achile), etc... Scheme, par contre, n'est pas un 4x4... Je ne dénigre par Scheme, au contraire : je pense qu'il faut simplement utiliser les choses pour ce à quoi elles sont destinées.Citation:
Envoyé par Garulfo
C'est pourquoi je disais qu'il était petit par rapport à OCaml qui, lui, est un mastodonthe si on considère tout ce qu'il peut faire (même sans CamlP4, ça fait peur). Ensuite, c'est sûr, par rapport à GHC, les extensions font énormément grossir le langage... mais les extensions ne sont pas portables...Citation:
Envoyé par Jedaï
... et là le bât blesse grièvement, car avec OCaml tu fais des choses 100% portables (tous OS et tous processeurs, pratiquement), alors qu'avec Scheme ou Haskell, le nombre important d'implantations différentes fait qu'il est difficile d'écrire du code portable, et tu auras ainsi le vieux spectre de la portabilité, bien connu en C et C++, derrière ton dos ! Comme quoi, le C c'est le paradis à côté d'autres langages (mais si, mais si, croyez-moi !) !
Je crois que l'on trouve cette phrase dans le manuel de GHC :Citation:
Envoyé par gorgonite
There are plenty of hand-optimized libraries written in C or C++. Do not try to compete with them : link with them instead.
C'est également un reproche que j'ai à l'encontre de Haskell : ou commence-t-il et ou termine la programmation en C ? Sans parler (et ça c'est inacceptable... à moins que je ne l'ai pas vu, mais j'ai réellement cherché dans les librairies fournies avec GHC) du fait que Haskell ne peut pas communiquer sur Internet !
Oui, enfin bon... Si tu veux faire une application complète en OCaml tu risques de te trouver confronté au problème de librairies graphiques et là... ce n'est pas plus portable que pour Haskell.Citation:
Envoyé par InOCamlWeTrust
Haskell lui-même a effectivement plusieurs implémentations mais tu peux te limiter à GHC si tu veux être à peu près tranquille, ce sera moins portable qu'OCaml mais pour toutes les plateformes classiques ça marchera très bien et tu auras accès à la plus grosse partie de l'effort de développement pour Haskell.
En bref sauf si tu as l'intention de faire un truc très généraliste Haskell conviendra tout autant qu'OCaml du point de vue portabilité.
Euh... Network fait partie des bibliothèques distribuées en standard avec GHC et prend en charge toute la communication par socket de façon multiplateforme. Network.HTTP est une librairie pour gérer le protocole HTTP compatible avec au moins GHC et Hugs...Citation:
Envoyé par InOCamlWeTrust
Les librairies écrites en C pour Haskell sont toutes des librairies qui travaillent directement sur la mémoire ou les aspects bas-niveau qu'il faut bien faire en C (en Ocaml également les librairies de bas-niveau ont été écrites en C), la plus grande partie des librairies distribuées avec GHC est en Haskell et traite de problème bien plus haut niveau.
Comprenons nous bien : je pense qu'OCaml est actuellement le langage le plus "mature" des propositions, néanmoins Haskell est un choix tout à fait viable et présente certains avantages qui permette d'écrire des programmes puissants, clairs et élégants en peu de lignes (le nombre de ligne n'est pas une mesure de qualité en soi, mais à mon humble avis, entre un code en C de 30 000 ligne et un code équivalent en Haskell de 1000 lignes, le code en Haskell est plus facile à maintenir et à aborder (pour quelqu'un qui connait bien les deux langages bien sûr !)...).
Un exemple récent de véritable application en Haskell : xmonad.
--
Jedaï
Je suis entièrement d'accord avec toi sur tous les points, là il n'y a pas de problèmes.
Pour ce qui est de Network, je re-regarderai la version que j'ai à la maison (6.6 normalement)... c'est vrai que ne pas avoir trouvé de librairie permettant de communiquer sur internet m'avait choqué.
Pour toi le support, c'est uniquement en Français et avec des personnes de visu? Car dans ce cas tu as raison ^_^Citation:
Envoyé par InOCamlWeTrust
Garuflo, tu ne m'a pas repondu si t'avais le livre de charazin en version numerique ou pas ?;)
Sinon, je pense que pour mon moteur d'inference, je vais l'implementer en Scheme ou Ocaml. Vous en dites koi ?
Moi je pencherai pour scheme :lol:
Non il faut l'acheter.Citation:
Envoyé par ThE_LaSt
Moi je te dirais Scheme aussi, ayant plusieurs fois à faire avec ce genre de problème. Cependant, si tu ne t'imposes pas de prog. fonctionnelle, le Prolog serait un meilleur choix a priori puisque c'est exactement le but du langage que de programmer des systèmes de déductions.
Et maintenant, ma fonction retourne une liste de strings, et je veux toutes les afficher. Je fais comment, il est où le "iter putStrLn" ?Citation:
Envoyé par Jedai
Paf.
Citation:
Bof...Citation:
Dans l'ensemble, je trouve les règles du Haskell plus complexes que celles du Caml. Il suffit de regarder par exemple les règles du filtrage de motif, il y a tout un tas de subtilités (la gestion de la paresse, de la divergence, etc...), de questions qui ne se posent pas en OCaml.
Citation:
Envoyé par gentle haskell 98
pas convaincant ton exemple... avec une petite monade tu peux t'amuser à appliquer la dite fonction a tous les éléments d'une liste ;)Citation:
Envoyé par bluestorm
Paf ? Peut-être devrais-tu retirer tes oeuillères :Citation:
Envoyé par bluestorm
(mapM_ peut paraître ésotérique comme nom, mais c'est juste un map sur Monade, où on jette le résultat des applications (le _ est une convention pour dire ça) )Code:
2
3
4
5
6
Quant à ton second exemple, il est où le problème ? Effectivement il y a une subtilité, c'est le prix à payer pour exploiter le pouvoir de l'évaluation paresseuse, mais dans un langage strict, ça n'aurait effectivement aucune importance dans quel ordre tu mets tes deux premiers motifs : ça divergerait dans les deux cas montrés en dessous !! Au moins dans Haskell tu pourras utiliser des listes infinies (avec take ou take1 d'ailleurs)... En bref la complexité rajouté est invisible si tu ne fais pas usage du pouvoir en plus d'Haskell, et ne pose pas problème habituellement (pour la plupart des usages les deux versions sont équivalentes, même avec des listes infinies).
J'ai l'impression que tu tapes sur Haskell sans l'avoir exploré plus que ça...
--
Jedaï
"Paf" dans le sens où tu ne pourras plus faire croire que l'entrée-sortie c'est tout con, il suffit d'utiliser putStrLn dans main et puis voilà.
C'est pour montrer que l'argument "on peut très bien montrer sans expliquer/ faire comprendre au début" n'est pas très convaincant, à mon avis. Tu voudrais balancer MapM_ au débutant en lui disant "mais t'inquiètes pas, tu comprendras plus tard" ? À mon avis, ce n'est pas jouable.
Autant pour PutStrLn, le débutant peut gober, autant dès qu'il essaiera d'expérimenter un peu autour par soi-même (par exemple en voulant afficher une liste de chaines de caractère), il se prendra forcément les monades dans la gueule.
Ce que j'ai dit, c'est que les règles sont plus complexes. Effectivement, la complexité vient avec des avantages intéressants, mais ça reste plus complexe, il y a un "prix à payer" comme tu dis.Citation:
Quant à ton second exemple, il est où le problème ? Effectivement il y a une subtilité, c'est le prix à payer pour exploiter le pouvoir de l'évaluation paresseuse
Dans l'ensemble, cela étaie donc mon propos initial, qui est qu'à mon avis il est plus long et difficile d'avoir un bon [aperçu/socle de base/point de vue d'ensemble] du Haskell que du Caml (sous-entendu, quand on vient d'un langage impératif, je ne traite pas le cas du débutant complet, parce que je n'y connais pas grand chose).
Je ne connais pas bien Haskell. Je n'en suis pas un défenseur ou un détracteur, mais ton exemple ne me convainc pas du tout. Ça me paraît très simple à faire. Faire un map sur une liste d'élément pour tous les afficher est le moyen le plus naturel en programmation fonctionnelle. Par contre, utiliser un moyen itératif n'est pas naturel et montre une méconnaissance des techniques fonctionnelles. Enseigner à un étudiant à afficher tout le contenu d'un tableau de chaînes de caractères n'est pas du tout simple non plus. Pour qqun qui ne connait rien à l'informatique apprendre à utiliser un application map est aussi simple/complexe qu'apprendre à utiliser une boucle itérative while ou for.Citation:
Envoyé par bluestorm
Mais je suis d'accord par contre que le filtrage peut être une réel épine dans le pied. C'est effectivement gênant de devoir réfléchir à la méthode d'évaluation pour qqch d'aussi simple.
Oh, mais tu n'y réfléchis pas, ou plutôt le débutant n'y réfléchit pas, ça viendra avec l'expérience, et les deux implémentations marchent aussi bien l'une que l'autre dans la très très grande majorité des cas.Citation:
Envoyé par Garulfo
--
Jedaï
Ce qui fait que le débutant pourrait avoir de mauvaise surprise.Citation:
Envoyé par Jedai
Personnellement je pense que l'évaluation paresseuse est une bonne chose. Donc je ne critique pas trop -_-
Je ne pense pas qu'il ait vraiment trop de mauvaises surprises, entendons-nous bien : L'une comme l'autre de ces versions marchent parfaitement avec des listes infinies en arguments, c'est uniquement dans les cas où l'un ou l'autre des argument diverge immédiatement que la question se pose. Je ne pense pas qu'un débutant en Haskell soit choqué si un programme dans lequel il y a une boucle infinie ne fonctionne pas, il sera plutôt surpris quand l'un d'entre eux marchera.Citation:
Envoyé par Garulfo
--
Jedaï
C'est amusant. Car vu ce commentaire tu sous-entends que ton étudiant connaît l'informatique et la programmation ^_^Citation:
Envoyé par Jedai
Je t'assure que beaucoup d'étudiants en math se laisse avoir et crois qu'une boucle infinie peut fonctionner. Quand je parle à des étudiants de math qui n'ont jamais programmé de faire des suites infinies (en scheme) cela leur semble d'une évidence incroyable. Menfinbon c'est un autre débat.
Je ne suis pas d'accord, lorsque je parle de boucle infinie ici, il s'agit bien d'un programme qui ne peut jamais finir, je ne parles pas de listes infinies. Effectivement programmer avec des structures de données infinies ne pose pas vraiment de problème à des matheux, mais ils sont plutôt d'accord avec toi lorsque tu leur expliques que le programme :Citation:
Envoyé par Garulfo
ne peut pas te donner de résultat... qu'il diverge.Code:until (< 3) (+ 1) 4
--
Jedaï
Tu n'es peut être pas d'accord mais pourtant c'est bien ce qu'il y a dans leur tête.Citation:
Envoyé par Jedai
Bien sûr quand tu leur expliques ils s'en rendent compte. Mais je t'assure que pour beaucoup de matheux faire une boucle qui ne finit pas n'a rien de stressant en soi la première fois. Ceci est général pour beaucoup de débutant, mais je posais une anedocte par rapport à ton commentaire. Le commentaire que tu as fait sur la boucle infinie est donc faux d'après mon expérience : de nombreux étudiants sont « choqués » qu'une boucle infinie ne fonctionne pas. La notion d'algorithme n'est pas innée. Tu es dans un contexte où les étudiants sont de très bons étudiants. Ce n'est pas le cas de la majorité des étudiants qui rentre en info, et qui font de l'info. L'exemple que tu donnes est numérique. C'est autre chose quand c'est des prédicats plus « abstraits », comme un filtrage récursif sur une liste.
Oui, tu as peut-être bien raison, il est vrai que je n'ai pas eu énormément de contact avec des étudiants "moyens" en informatique.
Quel est leur attente habituellement ? Ils pensent que ma fonction va renvoyer +\infty ?
--
Jedaï
Effectivement. Il y en a qui (avec un an d'informatique) ne savent toujours pas qu'un algorithme doit être fini. Menfinbon, une collègue en école d'ingénieur en France me disait qu'ils ont constaté que des étudiants ingénieurs réussissaient à avoir leurs diplômes sans avoir jamais codé une seule fois. En tout cas, on sort du cadre du sujet ...Citation:
Envoyé par Jedai
Dans le sujet, je reconnais les vertus de l'évaluation paresseuse. C'est un concept que j'apprécie énormément car, comme je l'avais mentionné sur un autre fil, il permet dans certains cas d'allier plus facilement la partie analyse et la partie conception. Bien sûr ça a d'autre avantage.
Les types me laissent plus perplexes par contre. Si d'un côté, il y a un apport « sécurité » bien réel, d'un autre, enseigner sans type c'est imposer de bien réfléchir avant coup à sa conception. Sinon, on risque de ne jamais réussir à débugger son programme. Par la suite, le sans type offre une souplesse d'emploi bien agréable.
C'est pourquoi dans les langages, je ne suis pas convaincu que ocaml ou haskell ait un réel avantage sur scheme. Les bibliothèques et le support est très présent en Scheme et les compilateurs sont extrêmement efficaces maintenant. Il est aisé de faire de l'évaluation paresseuse, bien que, comme pour ocaml, elle doit être explicite. Le plus de Scheme, à mes yeux, c'est la puissance de son langage de macro qui permet de tout refaire. En fait, il est possible de tout refaire (curryfication automatique, évaluation paresseuse par défaut etc.) à l'aide du langage de macro très simple et puissant.
Haskell a-t'il un bon langage de macro ?
Citation:
Envoyé par Garulfo
etant étudiant en école d'ingénieurs en France, je peux confirmer cela... il y a d'ailleurs plusieurs techniques :
+ se mettre en binome avec quelqu'un de bon, et se taper tout le sale boulot
+ pour les projets en groupe plus importants, passer son temps à communiquer entre ceux qui bossent vraiment pour maintenir l'illusion, tout en ne faisant rien d'utile
+ s'il n'y a que des gens comme soi, s'arranger pour que personne ne rende rien, et aller se plaindre au prof pour que l'épreuve soit changée
j'ai personnellement été écouré par mon cursus en école, car selon moi, près de 80% de la "promo informatique" utilisait ces techniques ; au final ils auront le même diplôme que moi, et étant surtout des "tchacheurs" ils auront plus facilement au poste intéressant que moi
mais ce n'est qu'un petit aparté... :piou:
Ils ont instauré un examen final de programmation. Si tu n'as jamais codé, tu ne le réussira jamais.Citation:
Envoyé par gorgonite
Citation:
Envoyé par Garulfo
ou cela ? y a pas de cela dans mon école 8O (et je suis en 3ème année)
C'est l'art du pipotage, qui est aussi très cher à de nombreux Centraliens :yaisse2:Citation:
Envoyé par gorgonite
Je ne pense vraiment pas que l'évaluation paresseuse soit un plus pour apprendre l'informatique : ce n'est tout simplement pas naturel. L'homme raisonne naturellement de façon stricte, avec effets de bords, du moment que l'on convient que la machine possède une mémoire dont on peut en modifier l'état, et il est ainsi naturel d'écrire des boucles, des affectations et autres.
Pour ce qui est de ça...
Tout le monde le sait bien : écrire des programmes, c'est facile, c'est le sale boulot, ça n'a aucun intérêt intellectuel, et donc les étudiants en info sont naturellement mauvais !Citation:
Envoyé par Garulfo
Qui ça ils ? Je ne vois vraiment pas d'où tu peux tenir celà ! De plus, chaque école d'ingénieurs est indépendante, donc chacun fait ce qu'il veut chez soi !Citation:
Envoyé par Garulfo
Pour ce qui est des mecs qui ont un diplôme sans n'avoir jamais codé, je dirais même plus que l'on trouve des gens qui auront après trois ans un bout de papier où il y aura écrit "Diplôme d'ingénieur" et qui n'auront même jamais touché à une ligne de commande, ou encore des personnes ne faisant pas la différence entre :
et :Code:
2
3
4
5
6{ char *string; /* ... */ }
Le niveau baisse malheureusement de façon dramatique. Chez nous, où l'on trouve deux majeures, Maths et Info, on peut se rendre très clairement compte des méfaits de la programmation tout Java et du tout MATLAB. Les étudiants sont pour la plupart désorientés lorsqu'ils n'ont plus soit Eclipse soit MATLAB. Utiliser un vrai compilateur est devenu un exercice périlleux pour certains, et je ne parle même pas des Makefile, dont certains, les meilleurs, doivent peut-être se souvenir du seul principe...Code:
2
3
4
5
6{ char string[N]; /* ... */ }
Les écoles d'informatique et de mathématiques appliquées sont en train de devenir des Java Schools et des MATLAB Academies, et il y a fort à parier que l'on en subira les conséquences dans quelques années, voire même que l'on fera marche arrière et que l'on reviendra à des méthodes plus traditionnelles (C, FORTRAN, le Makefile et la ligne de commande), tout simplement car c'est ce qui se fait dans la vraie vie ! Le nombre d'applications nécessitant le C ou le FORTRAN est toujours aussi important, et il faut bien maintenir, voire ré-écrire ces programmes qui font marcher nos ordinateurs (les OS et autres outils), compilent et exécutent nos programmes (la JVM, faite en C ++, rien que ça), ou encore font du calcul scientifique haute performance (et ça, je suis bien placé en ce moment pour le confirmer !).
Ce sujet a complètement dérivé... Néanmoins pour en revenir à la question, Haskell a un langage de macro, est-il "bon" ? Il est en tout cas assez puissant (puisqu'il s'agit d'Haskell...). Il s'agit de Template Haskell (qui aurait peut-être été mieux nommé Meta Haskell).Citation:
Envoyé par Garulfo
--
Jedaï