Discussion :

[gorgonite]

C'est justement ce que je reproche à Qi, c'est que son système de type nécessite un Doctorat, alors que celui de Caml ne nécessite qu'un master :-p

comme la majorité des langages académiques... ils ont incontestablement énormement d'avantages, mais ont le gros défaut d'être trop compliqués pour un utilisateur lamba

nb : le niveau moyen d'un codeur serait plutot vers BTS/DUT/Licence

[alex_pi]

comme la majorité des langages académiques... ils ont incontestablement énormement d'avantages, mais ont le gros défaut d'être trop compliqués pour un utilisateur lamba

C'est justement là mon problème, c'est que je conteste le fait que le système de type de Qi, extremmement complexe, ait le moindre avantage.
Après, le reste de Qi apporte sans doute beaucoup à Lisp, mais vu que je ne connais pas ce dernier, je ne saurais juger.

[Jedai]

Ce qui me gène dans ce que dit Alex_pi, c'est que ce système de type ne semble pas appuyé sur une fondation solide... Autrement dit on peut lui faire dire n'importe quoi !
Le système de type de Coq est très complexe, mais au moins on ne peut pas lui faire dire des bétises, plus exactement on ne pourra jamais écrire un programme de type "True -> False" en Coq, alors que le système de Qi ne semble pas limité ainsi.
Autrement dit, dès qu'on commence à essayer de l'utiliser, on est obligé de prouver nous même qu'on n'est pas en train de casser tout.

S'il en est ainsi, je préfère encore programmer en Lisp et faire quelques preuves informelles là où j'en ai besoin.

# la majorité des codeurs n'ont pas un Doctorat en Info, et il conviendrait que les langages qu'ils utilisent ne demandent pas de tels pré-requis

Soyons sérieux une minute : OCaml ne demande pas un doctorat en Info, il ne demande même pas une license ! La plupart des programmeurs ont tout de même au moins un niveau license en fin d'études, ils ont parfaitement le temps d'apprendre OCaml, ou les moyens de l'apprendre par eux-même.

--
Jedaï

[gorgonite]

Soyons sérieux une minute : OCaml ne demande pas un doctorat en Info, il ne demande même pas une license ! La plupart des programmeurs ont tout de même au moins un niveau license en fin d'études, ils ont parfaitement le temps d'apprendre OCaml, ou les moyens de l'apprendre par eux-même.

ben regardes le niveau moyen des TP caml ou des TIPE en fin de spé... ça laisse souvent songeur

je pense clairement que si l'on veut utiliser correctement OCaml, il faut un background théorique sur les foncteurs et l'inférence de type... et clairement ce n'est pas du niveau licence.
après il est clair qu'on peut coder des hello world en caml dès le lycée, mais je doute que ça justifie une embauche dans une boite comme JaneStreet

[gasche]

je pense clairement que si l'on veut utiliser correctement OCaml, il faut un background théorique sur les foncteurs et l'inférence de type... et clairement ce n'est pas du niveau licence.

Je n'ai pas de background théorique (autodidacte sur le tas) et je m'en sors raisonnablement bien. En particulier l'inférence est en fait assez intuitive : avec un peu de pratique, on se crée facilement soi-même un système de pensée sur "comment ça marche" (en gros, "bouh il choisit le type le plus général possible"), parfois on a des petites surprises (par exemple les contraintes du genre (1 : 'a), et le polymorphisme de second ordre par annotations), mais ça marche bien.

Pareil pour les foncteurs, "ça prend un module en paramètre et ça renvoie un module", c'est quand même pas sorcier et ça demande pas de formation théorique. Après je dis pas, je me suis jamais trop intéressé aux modules récursifs et je les ai vu employés pour faire des trucs que je ne comprends pas, mais je n'en ai jamais eu besoin non plus.

Bref le background théorique, je ne suis pas convaincu.
J'ai essayé de toucher à Coq, et j'ai bien compris ce que c'est que "ne pas avoir les bases théoriques nécessaires". Je ne pense pas que ce soit le cas avec Caml.

Même en Haskell d'ailleurs, il y a un grand nombre de gens qui absorbent des choses délicates comme les monades sans aucun background théorique. Il y a aussi des gens qui savent faire le lien et c'est très intéressant, mais ce n'est pas "nécessaire" pour une utilisation non-gurutique du Haskell (même si le problème se pose certainement plus vite qu'en OCaml). Si les gens ont du mal à comprendre les monades, c'est parce que c'est une notion non-triviale, et pas (à mon avis) parce qu'il manque un background théorique.

après il est clair qu'on peut coder des hello world en caml dès le lycée, mais je doute que ça justifie une embauche dans une boite comme JaneStreet

L'argument est clairement biaisé : pour supporter ta thèse (no pun intended) qu'une licence ne suffit pas, tu choisis une boîte qui embauche principalement après un doctorat.

Bon, il se trouve que c'est aussi la principale (comprendre "la seule qui le fait aussi bruyamment", il y en a bien d'autres) boîte recrutant sur OCaml. Mais ça reste biaisé dans le sens où quand tu choisis des boîtes aussi spécialisées et exigeantes, forcément tu auras des prérequis élevés. Ce n'est pas parce que les boîtes gagnant leur croûte avec de la programmation fonctionnelle travaillent dans des domaines aussi avancés que Jane Street (ou Galois, etc.) qu'on ne pourrait pas faire des choses raisonnables avec un niveau raisonnable, comme la plupart des programmeurs dans la plupart des langages.

ben regardes le niveau moyen des TP caml ou des TIPE en fin de spé... ça laisse souvent songeur

C'était ton exemple d'environnement où les gens « ont parfaitement le temps d'apprendre OCaml, ou les moyens de l'apprendre par eux-même » ?

[HanLee]

Matinal le bluestorm (ou nocturne... ).

Je n'ai pas de background théorique (autodidacte sur le tas) et je m'en sors raisonnablement bien. En particulier l'inférence est en fait assez intuitive : avec un peu de pratique, on se crée facilement soi-même un système de pensée sur "comment ça marche" (en gros, "bouh il choisit le type le plus général possible"), parfois on a des petites surprises (par exemple les contraintes du genre (1 : 'a), et le polymorphisme de second ordre par annotations), mais ça marche bien.

Pareil pour les foncteurs, "ça prend un module en paramètre et ça renvoie un module", c'est quand même pas sorcier et ça demande pas de formation théorique. Après je dis pas, je me suis jamais trop intéressé aux modules récursifs et je les ai vu employés pour faire des trucs que je ne comprends pas, mais je n'en ai jamais eu besoin non plus.

Bref le background théorique, je ne suis pas convaincu.
J'ai essayé de toucher à Coq, et j'ai bien compris ce que c'est que "ne pas avoir les bases théoriques nécessaires". Je ne pense pas que ce soit le cas avec Caml.

Même en Haskell d'ailleurs, il y a un grand nombre de gens qui absorbent des choses délicates comme les monades sans aucun background théorique. Il y a aussi des gens qui savent faire le lien et c'est très intéressant, mais ce n'est pas "nécessaire" pour une utilisation non-gurutique du Haskell (même si le problème se pose certainement plus vite qu'en OCaml). Si les gens ont du mal à comprendre les monades, c'est parce que c'est une notion non-triviale, et pas (à mon avis) parce qu'il manque un background théorique.

Je plussoie, zéro background théorique, ça ne m'empêche pas de l'enjoyer pleinement sur la partie intéressante d'OCaml.

Et les foncteurs, tu peux trouver plein d'analogies dans d'autres langages.

C'est comme une classe template en C++ (pas mal de fois avec la STL, tu te sens obligé de fournir un foncteur C++ en paramètre du type pour std::set<> ou std::map<>, pour spécialiser le comportement).

Le module en argument, c'est aussi comme un objet qui implémente une interface en POO classique.

[InOCamlWeTrust]

Le gros avantage de ces langages-là, c'est que bien maîtrisés, ils apportent une sûreté incomparable aux programmes.

Le C ????

[...]

Ca va finir par se voir là, la mauvaise foi :-p[

Ben moi je dirais, à simple vue de nez, que tu n'as jamais fait du C sérieusement...

Le C est très rustique et ne comporte aucun mécanisme d'exceptions. En d'autres termes, quand une fonction de librairie (librairie standard LibC ou non) échoue, il y a toujours un moyen clairement documenté pour traiter n'importe quelle erreur, qu'elle soit grave, pas grave, ou qu'elle soit un simple avertissement (Warning) ! Tu n'as rien de similaire en OCaml. Souvent, les fonctions dans les langages soft buguent, lancent une exception qui est dans 99% des cas irrécupérable car ou non documentée ou critique, et puis font lamentablement planter (non pardon, terminer) ton programme et tu te retrouves comme une poule avec un cure-dents !

Je vais te donner un exemple.

L'année dernière, alors que je compilais une librairie que j'avais faite (en C) avec gcc, je me rends compte que la compilation s'arrête brutalement.

gcc avait fait un segfault !

Cependant, les programmeurs de gcc ainsi que les mainteneurs chez Mandriva, qui ne sont pas nés de la dernière pluie, semble-t-il, ont eu la clairvoyance d'enregistrer dans le programme un handler de signal SIGSEGV (le signal qui est levé par l'OS quand il y a un segfault) afin d'afficher dans le terminal, avant que le programme termine mais après qu'il ait segfault'é, l'e-mail de la personne/groupe à contacter dans ce cas-là ainsi que l'origine du bug (un segfault).

Ici, clairement, on est face à de bonnes pratiques de programmation qui permettent indéniablement de renforcer un programme et le rendre résistant à beaucoup de choses.

Avec OCaml ou Haskell, je pense que l'on aurait eu une lamentable phrase ésotérique pour la personne qui n'a pas forcément envie d'y connaître quelque chose à son compilateur : Uncaught exception: Array_out_of_bounds, puis la main rendue à l'utilisateur.

Tu auras remarqué qu'en C POSIX, on peut tout à fait se passer des segfault, les rattrapper et ainsi poursuivre les calculs ! Tu ne feras tout simplement jamais ça avec Java !

Uncaught exception: void pointer
Uncaught exception: void pointer
Uncaught exception: void pointer
Uncaught exception: void pointer

Sans parler de la portabilité du C : ben oui, seul le C ANSI est portable ! Sur toutes les machines et tous les OS correctement faits : Windows, Linux, tous les BSD, Solaris, HP-UX (on en avait encore à GAMMA !), etc...

Quand j'étais à GAMMA l'année dernière, on demandait que tous les programmes

1- suivent scrupuleusement les normes, car ils étaient compilés et exécutés sous les systèmes/CPU/OS les plus classiques comme les plus exotiques (et surtout ceux-là)

2- puissent être compilés sans Makefile avec une seule commande du genre cc *.c ou encore f77 *.f

[Jedai]

Cependant, les programmeurs de gcc ainsi que les mainteneurs chez Mandriva, qui ne sont pas nés de la dernière pluie, semble-t-il, ont eu la clairvoyance d'enregistrer dans le programme un handler de signal SIGSEGV (le signal qui est levé par l'OS quand il y a un segfault) afin d'afficher dans le terminal, avant que le programme termine mais après qu'il ait segfault'é, l'e-mail de la personne/groupe à contacter dans ce cas-là ainsi que l'origine du bug (un segfault).

Ici, clairement, on est face à de bonnes pratiques de programmation qui permettent indéniablement de renforcer un programme et le rendre résistant à beaucoup de choses.

Avec OCaml ou Haskell, je pense que l'on aurait eu une lamentable phrase ésotérique pour la personne qui n'a pas forcément envie d'y connaître quelque chose à son compilateur : Uncaught exception: Array_out_of_bounds, puis la main rendue à l'utilisateur.

C'est ridicule ton histoire... En bref quelqu'un avait pensé à installer un handler sur SIGSEGV ? Et tu crois que c'est parce qu'on était en C ? Tous les langages corrects savent faire ça (oui Haskell aussi, je ne doute pas qu'OCaml le fasse également), tous les langages corrects te permette également de capturer n'importe quelle exception ou alors une exception quelconque (Haskell ou OCaml savent le faire). Tout ce que ton histoire prouve c'est la prudence et le professionnalisme de certains développeurs de gcc, rien à voir avec le langage... Et puis tu m'excuseras, mais personnellement, j'ai du mal à comprendre que tu puisses te glorifier d'un segfault dans une application aussi mature que GCC, est-ce que ça ne prouve pas que C est par nature un langage non-sûr ? Entre un segfault et un "array_out_of_bounds", tu préfères quoi ? Le segfault qui peut trahir une faille exploitable par un assaillant dans ton application, ou l'exception qui au pire indique une erreur d'index ou une faille qui ne peut être utilisé que pour tuer l'application ?

--
Jedaï

[LLB]

Je n'ai pas vraiment envie de débattre de la sûreté de C dans ce thread (mais pourquoi pas dans un autre ?). Mais :

1) le segfault n'est pas systématique. Faire un mauvais accès peut te renvoyer une valeur quasi-aléatoire.

2) c'est quand même plus simple de poursuivre l'exécution après avoir rattrapé une exception qu'après un segfault.

[gorgonite]

bon j'arrête de parler dans ce thread... ça va finir en pugilat

C'était ton exemple d'environnement où les gens « ont parfaitement le temps d'apprendre OCaml, ou les moyens de l'apprendre par eux-même » ?

c'est un exemple de ce que des élèves de niveau licence (car la licence à la fac vaut certainement un MP contrairement à ce que certains voudraient faire croire ), n'ont absolument pas ce qui faut pour faire des programmes corrects... rares sont les projets avec un code utilisant des fonctionnalités avancées, et bien structurés

[alex_pi]

Cette discussion n'est notoirement pas dans le bon thread...

Ben moi je dirais, à simple vue de nez, que tu n'as jamais fait du C sérieusement...

Je ne dirai pas le contraire...

Le C est très rustique et ne comporte aucun mécanisme d'exceptions. En d'autres termes, quand une fonction de librairie (librairie standard LibC ou non) échoue, il y a toujours un moyen clairement documenté pour traiter n'importe quelle erreur, qu'elle soit grave, pas grave, ou qu'elle soit un simple avertissement (Warning) !

C'est quoi le rapport entre le première et la deuxième phrase ? "Puisqu'il n'y a pas de moyen propre de signaler que quelque chose s'est mal passé, c'est toujours bien fait" ? Tu trouve honnettement que la valeur de retour d'une fonction qui dénote par en entier l'erreur qui s'est produite, c'est bien ? Ou mieux encore, que dans certain cas il faille aller regarder si le contenu d'une variable a changé entre avant et après l'appelle pour s'avoir si la fonction a écrit quelque chose dedans, signalant qu'une erreur s'est produite ?

Tu n'as rien de similaire en OCaml. Souvent, les fonctions dans les langages soft buguent, lancent une exception qui est dans 99% des cas irrécupérable car ou non documentée ou critique, et puis font lamentablement planter (non pardon, terminer) ton programme et tu te retrouves comme une poule avec un cure-dents !

Là tu parles d'habitude de programmation, absolument pas de la valeur intrinseque du langage. Et je doute *grandement* qu'une proportion ne serais ce que non négligeable de codeur C soit aussi minutieux dans leur documentation que tu le prétends...
Si une exception est lancée et non ratrappée, effectivement, mon programme termine. Si une erreur est produite par une fonction C, mais que le programmeur n'a pas vérifiée la valeur de retour de la fonction, l'erreur est totalement silencieuse, le reste du programme continue à s'exécuter, alors qu'il a été pensé par un programmeur qui a oublié que la fonction pouvait échouer. Les pires choses peuvent maintenant se passer.

Je vais te donner un exemple.

L'année dernière, alors que je compilais une librairie que j'avais faite (en C) avec gcc, je me rends compte que la compilation s'arrête brutalement.

gcc avait fait un segfault !

La morale ? Que même des gens avec une maitrise suffisante du C pour en écrire un compilo ne peuvent pas écrire un programme de taille conséquence sans segfault.

Cependant, les programmeurs de gcc ainsi que les mainteneurs chez Mandriva, qui ne sont pas nés de la dernière pluie, semble-t-il, ont eu la clairvoyance d'enregistrer dans le programme un handler de signal SIGSEGV (le signal qui est levé par l'OS quand il y a un segfault) afin d'afficher dans le terminal, avant que le programme termine mais après qu'il ait segfault'é, l'e-mail de la personne/groupe à contacter dans ce cas-là ainsi que l'origine du bug (un segfault).

Ici, clairement, on est face à de bonnes pratiques de programmation qui permettent indéniablement de renforcer un programme et le rendre résistant à beaucoup de choses.

Euh, en quoi afficher un message avec un mail renforce le programme ? Un segfault, c'est soit un pointeur non initialisé (donc ton programme ne fera pas ce que tu attends de lui, cacher l'erreur en ratrappant le signal n'initialisera pas ton fameux pointeur), soit, beaucoup plus grave, un dépassement de tableau. Avec un peu de chance, ce dépassement peut être déclanché par une entrée utilisateur, qui peut alors faire ce qu'il veut avec ton programme, soit le faire planter (cas peu grave), soit faire de l'injection de shellcode. (un poil plus génant...)

Avec OCaml ou Haskell, je pense que l'on aurait eu une lamentable phrase ésotérique pour la personne qui n'a pas forcément envie d'y connaître quelque chose à son compilateur : Uncaught exception: Array_out_of_bounds, puis la main rendue à l'utilisateur.

Qu'est ce qui t'empeche, en Caml par exemple, d'entourer ton main par un

Code :

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

1
2
3
let _ = try main () with
  | _ -> (prerr_endline "Si tu lis ce message, envois \"Kikoo lol\" par sms au 4269"; exit 1)

?

Tu auras remarqué qu'en C POSIX, on peut tout à fait se passer des segfault, les rattrapper et ainsi poursuivre les calculs !

Arghl ! Et c'est toi qui parlais de "bonne habitudes de programmation" ? Cacher l'erreur sous le tapis, tenter de reprendre le cours des calculs (qui sont évidement érroné puisqu'avant de provoquer une erreur, tu as très probablement fait n'importe quoi dans ta pile ou dans ton tas), en espérant eventuellement que l'utilisateur ne se rendra compte de rien, et ne tentera donc pas d'exploiter la faille (dommage que ptrace existe) ? Tu appelles ça de bonnes habitudes ?

[tool69]

Juste pour signaler que QiII vient juste de sortir aujourd'hui.
La page de nouveautés : What's new

[LLB]

In a month I will be packing to go to India; this time for an extended
period. But its also a goodbye to Qi and computing. At some point
you have to acknowledge that Qi doesn't pay its way. It was fun
though and I'm not sad about it.

Qi has been a journey that began nearly 20 years ago when I was a very
different person and worked for a university. But the book on Qi II
marks a natural watershed. I need to move on. By September I will be
gone.

http://groups.google.com/group/Qilan...62017d87?pli=1