Michaël a écrit 2935 commentaires

je regarderais si ca fonctionne.
(Fucking qwertz kezboard)

Un clavier qwertz n'oblige pas à mettre des s au futur de l'indicatif — qui appartiennent au conditionnel.

Est-ce que tu pourrais éviter de faire des généralité à partir d'un post (ce que tu fais souvent dans tes commentaires).

Si on n'a plus le droit de faire ça, comment est-ce qu'on va faire pour discuter? Je m'inquiète.

Je n'ai jamais autant ri quand on m'a installé cette bouse à mon précédent boulot.

Quand on t'a expliqué que tu étais obligé de t'en servir pour toutes les communications internes et pour le suivi de projet, cela a dû te calmer un peu non? :)

Il me semblait qu'il était possible de partager de la mémoire entre un processus et son fils—n'est-ce plus le cas? ET de façon indirecte (par exemple mmappant un fichier dans les deux processus?)

J'ai trouvé ça drôle aussi mais avec une petite réserve. Je pense que ce message serait plus à sa place dans le forum linux.debian/ubuntu.

Es-tu plus expérimenté en Ocaml qu'en Python ? Si oui, la comparaison est biaisée de toute les façons ;

Je fais autant de fautes de frappe en OCaml qu'en Python. Dans le premier langage, elles sont trouvées par le compilateur, dans le second, elles ne le sont pas.

Mais c'est vrai que c'est plus facile de se plaindre de son patron que de prouver ses dires (de la seule façon possible, à savoir passer à l'action).

Tu parles de quoi?

Dans l'article dont je cite le titre, les auteurs observent des variations de vitesse avec un rapport 4 dans plusieurs éxécutions du même programme. Cela veut dire qu'à moins d'avoir de sérieuses raison de penser le contraire, voire ton programme A' amélioré tourner 4 fois plus vite que le programme A original est peut-être tout simplement associé à un phénomène aléatoire (une erreur de mesure). Ensuite le problème qu'on a à faire des tests statistiques est que les observations que l'on fait ne sont pas indépendantes les unes des autres (en première approximation, un ordintateur est déterministe) c'est-à-dire que l'hypothèse de base de tout test statistique n'est pas remplie.

Imaginons maintenant que les bugs de type 5 sont ceux qui prennent 99% du temps de debugage (c'est un chiffre sorti de mon chapeau, juste pour relativiser tes propos).

J'ai récemment écrit un programme en Python, qui fait une analyse de réseau routier et de relief pour localiser les tronçons de route qui sont des ponts. Cela m'a pris trois mois à temps plein, en profitant d'une bilbiothèque toute faite pour accéder aux données. J'estime à plus des 3/4 le temps que j'ai passé à debugger des erreurs de frappe, qui n'arrivent pas toujours dans les premières secondes du programme. Si j'avais pu travailler en OCaml j'aurais certainement torché ça en 5–6 semaines en prenant une semaine pour implémenter ou lier la bibliothèque en question.

Cela expliquerait pourquoi les codeurs Ocaml, malgré la supériorité de leur langage, n'arrivent quand même pas à écraser les autres codeurs, en écrivant le même genre de logiciel mais 10 fois plus vite et 10 fois meilleurs (comme certains aimeraient le croire).

C'est parceque les développeurs OCaml sont tous des gentils qui n'aiment pas écraser les autres. De plus les diçaïdeurs sont en majorité des gens allergiques au risque, qui préfèrent travailler avec une technologie peu productives mais bien acceptée (comme C++) que prendre le risque d'introduire une innovation. Ni les supérieurs du diçaïdeur ni ses clients ne leur reprocheront le choix de C++, pour continuer sur cet exemple.

Et comme OCaml est difficile à apprendre, si on ne l'a pas appris à l'université/école d'ingénieur, il est dur de s'y mettre tout seul. Tout le contraire de Python de ce point de vue.

OCaml est peut-être difficile à apprendre mais il est facile à utiliser, car comme tu le dis, le compilateur trouve toutes les erreurs!¹ Au contraire, python est facile à apprendre et difficile à utiliser car l'interpréteur ne trouve aucune erreur. Vu qu'on passe beaucoup plus de temps à utiliser un langage qu'à l'apprendre… pour moi c'est tout vu!

¹ Comme je suis sûr que certains ne me croient pas je détaille. Quand je programme je fais couramment les erreurs suivantes:

1. fautes de frappe;
2. fautes de modèle, je me suis emmêlé les pinceaux dans les structures et essaie de lire un membre qui n'apparaît pas dans une variable;
3. fautes d'algorithme bêtes (les fautes de type de type);
4. fautes d'algorithme protocolaires (les fautes d'invariants), par exemple j'écris dans un fichier que j'ai déjà fermé;
5. fautes d'algorithme intelligentes (l'algorithme est faux).

Le compilateur OCaml trouve toutes les erreurs de type 1, 2, et 3 automatiquement. En travaillant sur la structure de notre programme, on peut faire en sorte que le compilateur trouve aussi toutes les erreurs de tzpe 4. (Il faut exprimer les invariants du programme dans le système des types.) Les seules erreurs que ne trouve pas le compilateur OCaml sont celles de type 5, c'est plutôt bien et beaucoup mieux que ce que font d'autres langanges. Les langages interprétés ne détectent les fautes de type 1, 2, ou 3 que lorsqu'ils essaient de les éxécuter, par exemple. Les langages compilés ne s'en sortent pas tous mieux, par exemple les lanagages à surcharge d'opérateur peuvent accepter des programmes faux qui ont l'air corrects à cause de cette surcharge!

Sans teste, cela ne veut pas dire grand chose.

Même les tests ne veulent pas souvent dire grand chose! (Source How to produce the wrong data without doing anything obviously wrong.)

Ce n'est pas un vrai point Godwin car le mot nazi est utilisé dans l'expression “interface nazis” utilisée par un développeur bien connu pour désigner les codeurs de Gnome.

quand on veut comprendre ce qui ce passe

x86 est une architecture pourrie car incompréhensible! Il est pratiquement impossible de prouver quoique ce soit et les optimisations du compilateur ne portent d'optimisation que le nom — en réalité leur impact sur la rapidité d'éxécution est très incertain.

Si tu aimes avoir peur, tu peux lire ça et ça:

http://compilers.iecc.com/comparch/article/96-02-165
www.multicoreinfo.com/research/papers/2009/asplos09-producing-data.pdf

En bref ils montrent que des variations de rapidité dans un facteur de 1 à 4 peuvent etre liés à l'environnement seul (le programme ne change pas). Cela veut dire que si tu optimises un programme et que la version optimisée tourne 4 fois plus vite, tu ne sais pas si le changement vient de ton programme ou de l'environnement. (C'est désagréable, mais c'est comme ça.)

Pour commencer, évaluer la performance d'un programme dépend de l'architecture. Je vais bêtement supposer que tu es en x86, ce qui est une très mauvaise nouvelle car les heuristiques d'accélération de la puce (prefetch etc.) rendent la performance du code très difficile à prédire. Par exemple, il peut arriver que du code testant les bornes des indices lors de l'accès à des tableaux tourne plus vite que le code sans test correspondant, ce qui n'est pas très intuitif vu qu'il y a plus d'instructions.

Si tu utilises très intensément ta table et que celle-ci est assez petite, il y a de bonnes chances que celle-ci reste dans le cache mémoire du processeur et que le coût d'accès à celle-ci soit minime. Ceci dit si ta fonction est simple (tests, additions, rotations de bits et branchements courts) je m'attends à ce que la vitesse d'exécution soit comparable à celle de la version avec table tandis que si ta fonction contient des instructions plus complexes (divisions, multiplications) la version précalculée sera vraisemblablement plus efficace.

Tandis que s'il n'y a pas de doc, je ne sais pas s'il y en a un et que ce n'est pas indiqué par flemme ou si c'est le comportement normal.

Au travail notre système de documentation est Visual Studio Debugger et c'est pas génial… on passe notre temps à debugger du code qui marche pour comprendre le flot du programme, les invariants, etc. Côté productivité, c'est une pénalité monstrueuse et en plus, c'est souvent très approximatif.

En gros il est quasiment impossible d'apporter des modifications non triviales à un code non documenté.

socialisme (euh, non, ça voulait dire communisme mais ça ne veut plus dire grand chose en fait) ?

Il me semble qu'il y a une nuance, car tous les socialistes ne sont pas collectivistes (alors que les communistes le sont).

Pourquoi tu m'appelles beauté?
Comme si ça se voyait pas!

(que tu pouvais copier/coller vu qu'il apparaissait en descriptif du lien)

Effectivement. C'est dommage que mon libre-arbitre me pousse parfois à des comportements stupides et paresseux!

J'ai quelques remarques sur ton paragraphe à propos de la documentation.

1. Tu aurais pu corriger la faute: “Get the title” Il ne faut pas de s à get puisqu'il s'agit d'un impératif ou d'un infinitif — pour mettre un s il faut un sujet!

2. S'il y a bien un endroit (en fait, le seul!) où le copier-coller est tolérable, c'est la documentation des interfaces. C'est parfois automatisable avec des macros (comme dans les macros MDOC ou MAN pour les pages de man) mais parfois le plus court chemin est le copier-coller.

3. Dans ce cas la clause return … ne sert à rien car elle n'apporte pas de nouvelle information!

4. J'ai souvent lu ce genre de documentation pour du C ou du C++, omet l'information cruciale: la valeur de retour est-elle un alias ou une nouvelle valeur?

Trop pratique ton lien cassé!

Euh, tu changes d'imprimante pour ça ? Désolé, mais je ne vois aucun produit de ma vie quotidienne qui rentrerait dans cette catégorie.

Moi quand mon frigo est vide j'en rachète tout de suite un!

Ce que tu ne veux pas comprendre, c'est que la signature throw() indique que la fonction sur laquelle elle s'applique ne lancera jamais une exception.

Et ça c'est l'exemple du livre, de fonction qui ne lance jamais d'exception, j'ai bon?

void plop() throw() {
   throw std::exception();
}

Ben parceque throw() veut dire cette fonction ne lance aucune, absolument aucune exception, ce qui visiblement n'est pas le case. La définition du langage (en tout cas, Stroustrup) demande de compiler mais de lancer bad_exception dans ce cas… Du coup au lieu d'avoir un message utile à la compilation ­— qui aide à écrire des message corrects, on se retrouve avec une exception lancée pendant l'éxécution, qui ne sait pas d'où elle vient. Pratique.

Si les définitions des fonctions membres ne sont pas dans la même unité de compilation, le compilateur ne pourra pas deviner que People::joke ne lancera jamais d'exception.

Et d'une

void SkinHead::joke() throw()
{
    throw std::logic_error("Racist joke") ;
}

ne devrait pas compiler (si C++ était mieux fichu), et de deux, c'est quoi qui empêche le compilateur d'écrire dans le fichier objet la liste des exceptions lancées par les fonctions de l'unité de compilation? Rien si ce n'est la flemme.

Effectivement les closure font le job… ceci-dit c'est un peu dommage que les concepteurs du D — qui visiblement se sont un peu inspirés du C et du C++ — n'aient pas choisi de supprimer le type void pour le remplacer 1. par un type singleton (unit pour ceux qui parlent l'OCaml) un type qui n'a qu'une seule valeur, ce qui sert d'argument aux fonctions qui n'ont pas d'argument et de retour aux fonctions sans valeur de retour; et 2. par un type pointer qui remplacerait void* (il n'y a aucun rapport entre void et void* en C ou en C++).

Au passage cela aurait été bien de décider entre pointeurs et références, cela ne sert à rien de garder les deux (à part à faire ch*er les programmeurs) ­— je n'ai pas vérifié en détail mais on dirait que D utilsie les deux.

À la différence de C++, le langage OCaml est fait pour la programmtion fonctionnelle…