lasher a écrit 2732 commentaires

Je participe pas mal à des sous-communauté de reddit (ocaml et haskell en particulier) qui sont très agréables. La mailing-list OCaml est aussi très agréable.

J'attendais que quelqu'un cite Reddit dans cette conversation. J'aime bien Reddit, j'y passe un certain temps chaque semaine. Mais c'est typiquement le site qui recueille le pire et le meilleur du net (sans descendre jusqu'à du /b/ sur 4chan) : /r/funny qui est très généraliste n'a clairement pas la même fréquentation en termes de personnes que /r/ocaml. Et le premier est bien plus généraliste que le deuxième, et rassemble nécessairement plus de monde, car moins spécialisé (oui, je fais une redondance dans cette phrase car je pense qu'il faut insister).

Linuxfr.org est un site globalement consacré à l'informatique libre pour les nouvelles. Ça en fait quelque chose de très généraliste dans le domaine de l'info malgré tout. Les contributeurs du site (je parle des utilisateurs en général) sont pour beaucoup des gens dont le métier est lié à l'info. Le niveau, malgré ce que certains pensent ici, est assez haut au final, comparé à des sites parlant d'informatique plus généraliste.

Je ne connais pas /r/ocaml, mais je suppose que tout comme sur Usenet auparavant, il y a une charte, et que les discussions hors-sujet ne sont pas acceptées. Lorsque j'allais sur fr.comp.lang.c, on savait que le newsgroup n'était pas modéré, mais malgré tout, globalement les questions hors-charte¹ étaient soit ignorées, soit on y répondait en indiquant qu'on n'allait pas répondre (« ici on parle de C ANSI/ISO, pas de C POSIX », ou « C'est une question de C++ et pas de C. Tu ferais mieux d'aller demande sur fclc++ »). Même pour les questions en charte, certains pouvaient faire preuve d'une certaine condescendance dans leurs réponses. Malgré tout, ces gens condescendants aidaient beaucoup, et donc consacraient une grande partie de leur temps à répondre à des gens qui connaissaient moins le langage qu'eux. Comme ces gens étaient très actifs, ils ne se gênaient pas pour répondre de façon assez directe quand la réponse était déjà dans la FAQ (un équivalent de « RTFM » quoi). D'autres étaient plus aimables dans leurs réponses. Dans tous les cas, comme le newsgroup était extrêmement spécialisé, je trouvais l'ambiance parfaitement supportable. Lorsque j'allais sur fr.comp.os.linux.debats, je savais que j'allais atterrir dans un nid à troll. J'y ai participé, et c'était un joyeux mélange de discussions relatives à l'environnement des LL, et de discussions politiques et économiques très souvent façon brèves de comptoir (un peu comme les journaux de LinuxFR en fait).

Il faut éviter de confondre agressivité (active ou passive) et le fait d'être direct. C'est un peu la différence entre dire qu'un argument est nul (dans le sens : dénué de sens ou de substance), et dire que quelqu'un est nul. Il faut faire attention au contexte dans lequel c'est dit évidemment, car il est facile d'abuser de cette subtilité : il suffirait de dire pour chaque argument qu'il est nul, sans dire que l'interlocuteur l'est, mais tout le monde aurait compris ce qu'on pense.

Enfin je discute avec des gens directement par IRC ou blogs (ou, pour les mécréants, Google Plus) interposés, et le ton des discussions y est là encore très agréable.

Tu as bien de la chance. Sur IRC, j'ai le droit à tout : des cons, des mecs qui se veulent sarcastiques et drôles, mais sont juste des connards, mais aussi des gens qui veulent vraiment aider, et qui prennent le temps. Ou bien, pour les sites moins orientés technique, j'ai de tout : des mecs qui sont lourds, des mecs qui sont intéressants, etc.

Bref, encore une fois, plus la communauté est centrée sur un sujet précis, plus il y a de chances que les gens soient tous « OK », surtout s'il y a des règles strictes pour empêcher les dérives.

Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca.

Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca Caca.

Bonne lecture.

Hey, ça veut dire qu'il y a 30 à 40% de choses que ce site ne peut plus t'apprendre, c'est pour ça que le niveau général parait moins élevé !

Pas seulement. Je suis arrivé sur le site fin 2002. À l'époque je commençais mes études en école d'ingénieur, et je connaissais Linux et les BSD depuis ~3 ans. J'avais pour ainsi dire tout à apprendre. Mais je m'aperçois aussi que tout un tas de gens qui finissaient à l'époque leurs études (école d'ingé/Master ou doctorat en majorité, avec quelques uns qui étaient déjà pros et quelques autodidactes) sont restés sur le site (moi y compris). Et du coup, je pense que beaucoup, beaucoup de gens ont énormément gagné en expérience, et que forcément il y a moins à apprendre : après tout, tout un tas de sujets sont ressassés (« Linux est-il prêt pour le Desktop ? »; « Ubuntu : une alternative bidon à Debian ? »; etc. — les sujets que j'ai choisis sont trollifères, je l'admets).

Le problème de « l'apprentissage » dont parle Ontologia est aussi, comme il le dit implicitement, que certains aspects des LL ou des systèmes UNIX intéressent moins à mesure qu'on se spécialise (ou en tout cas pas assez pour que j'y consacre le temps nécessaire pour suivre l'activité) : je suis passé de « je vais devenir sysadmin ! » à « non en fait, j'aime trop coder, ça me manque ! » à « Bon en fait, la recherche liée aux aspects bas-niveau de l'info, c'est ce qu'il me faut ! » Même si je suis toujours intéressé par les news sur les nouvelles versions du noyaux Linux, j'avoue que je suis moins passionné par cet aspect. Lorsque je croyais que j'allais finir sysadmin, j'étais bien plus passionné par ce sujet.

Ah mais en fait je viens de comprendre. Tu viens de faire une review de la dernière version de Darwin OS. J'ai bon ?

Oui, mais une appli mal codée non voulue et qui me siphonne ma batterie, c'est quand même un malware, à défaut d'être un « vrai » virus.

En l'occurrence, comme Android est plus ou moins comme un Windows 95/98 sur beaucoup de points, je pense que pBpG n'est pas complètement dans le faux. Grosso modo : utilisateur = admin, avec juste un truc du genre « pour installer cette application vous devez l'autoriser à avoir les droits suivants: [liste de 10000 droits, dont géolocalisation, accès à tout un tas d'apps, etc.] ». Rien qu'hier, avec mon vieil Android 2.4, je cherchais un truc sur Google, et le premier lien va vers un site qui, avec du recul, était bien douteux. J'ai pas trop fait gaffe, et j'ai cliqué. Bon, en tant qu'infoteux un minimum parano, le simple fait qu'au lieu d'aller jouer la vidéo promise, le soft commence à télécharger un fichier exécutable m'aurait mis la puce à l'oreille. Du coup, le fait que l'anti-virus installé par défaut sur mon smartphone ait « détecté » que le fichier en question était un virus n'était pas spécialement une aide, parce que mon métier est informaticien.

Mais si un infoteux qui baisse sa garde ne fait « que » télécharger par inadvertance un binaire sans l'exécuter, que penses-tu qu'il arriverait avec un utilisateur lambda encore moins vigilant, qui veut voir sa vidéo de <insert stuff here: porn, lolcat, etc.> ?

Au moins aux US, lorsque tu achètes un smartphone Android avec un opérateur mobile, il est normal qu'un antivirus soit installé par défaut.

Bon, il faut bien avouer que MS a compris que copier OOo/LO et la syntaxe Latex pour les maths n'était pas une mauvaise idée. Du coup la dernière fois que j'ai essayé, ça marchait plutôt bien (Office 2010).

Euh, j'ai dû louper quelque chose, tu peux me filer un lien ? J'ai cherché « Barnes and Noble Microsoft » mais tout ce que j'ai pu trouver c'était que MS avait investi dans le Nook.

Je suis globalement d'accord avec toi, mais pour les crapwares, même si sans doute ça arriverait, le fait que la plupart des softs soient libres sous Linux « freinerait » un peu les choses je pense. Par contre j'imagine bien Steam être préinstallé avec une distribution commerciale, avec Opera et je ne sais pas quoi…

Bon après, je suis peut-être naïf. :)

C'est le genre de choses que j'éviterais d'aborder dans un premier temps. Et maintenant je me souviens pourquoi je n'avais pas traité la différence entier/décimal : la programmation avec des décimaux est compliquée.

Pas vraiment. Les problèmes d'arrondis ne deviennent une gêne que si tu as besoin d'afficher plus de 2 décimales avec printf (genre printf("Temperature: %.2f\n", temperature);). Dans ce cas, tu n'as pas besoin d'embêter les élèves avec les histoires de « on ne compare pas deux nombres flottants par l'égalité » et autres trucs importants pour l'analyse numérique, mais pas tellement pour une initiation à la programmation.

[…] il ne faut pas introduire trop de concepts à la fois pour éviter de noyer sous une masse d'information imbitable. C'est pour ça qu'à mon avis, se limiter à 1 seul langage pour apprendre la programmation, ce n'est pas une bonne idée.

Je ne pense pas que rewind indique qu'il faille apprendre un seul langage. Dans certaines facs, les 2 premières années sont passées à apprendre l'algo/prog avec un même langage, et la troisième année ils en voient un autre. C'est pas forcément idiot. Cependant, les élèves qui suivent des études scientifiques à la fac doivent bien commencer quelque part. C ou C++ (version light) ne sont pas forcément de mauvais choix. De toute manière, les élèves qui font de la physique devront bien apprendre à manipuler R ou matlab, ou même Fortran (et s'ils ont de la chance, Python+les bonnes bibliothèques). Les élèves qui sont en bio apprendront Python ou Perl s'il font de la génomique/génétique, etc. Ce ne sera pas forcément pendant les 3 premières années de licence, mais ça finira nécessairement par arriver.

Pour un élève en informatique, comme je l'ai dit ailleurs, il est important selon moi que sur trois ans, il ait vu au moins 2 paradigmes de programmation (impératif, objet, fonctionnel), ce qui signifie au moins deux langages, et probablement en pratique 2,5 (genre ils commencent avec C, et embrayent ensuite avec C++ ou Java pour voir comment fonctionne la POO, puis font peut-être du Scheme ou OCaml).

Oui mais ça ne veut rien dire. « De mon temps », on abordait l'arithmétique en spé maths en Terminale S (donc du coup je savais déjà ce qu'était un groupe en arrivant en IUT), mais désormais une partie de l'arithmétique est enseignée en Seconde si j'ai bien compris (ou peut-être même en 3è). Ce qui change d'une décennie à l'autre, c'est dans quel ordre on voit les sujets en maths.

Hum. Autant je suis d'accord pour dire que la plupart des gens ont Fortran 66 ou Fortran 77 en tête lorsqu'ils parlent du langage, autant mon expérience (limitée, je l'admets) a été que oui, les codes qu'on me donnait à optimiser étaient faits en F77 ou F90. Pas de F95, et certainement pas F03 (F08 ne compte pas, vu qu'à l'époque j'étais en 2è année de thèse :)).

Je suis certain que tout un tas de gens utilisent F95 ou même F03 dans les milieux du calcul scientifique, mais je n'en entendais pas parler (j'ai bossé avec des gens du CEA, de Dassault Aviation, et des boites allemandes). Par contre c'est sans doute lié à ce que je devais optimiser : les primitives de calcul en algèbre linéaire, des solveurs itératifs, etc.

En terme d'expérience pratique oui, bien sûr. Mais la programmation n'est qu'une partie du cursus. Nous faisons énormément de génie logiciel aussi, et en règle générale d'analyse et conception de systèmes d'info. La programmation n'est qu'une portion (pas négligeable, mais pas majoritaire non plus — la plupart du temps le génie logiciel a un plus fort coefficient que les UV de programmation/algo pures) du programme.

Ensuite, la plupart des gens qui arrivent en école d'ingénieur ont quand même fait un minimum d'algorithmique (à mon époque, les prépas MPSI faisaient soit du Caml light, soit du Pascal, et la prépa intégrée de mon école permettait aux étudiants de suivre une intro à l'algorithmique). Note : ayant fait un IUT, nous étions (à raison!) interdits d'UV de structures de données (car nous avions déjà vu 90%).

Maintenant je peux te dire comment j'ai vécu la chose : je venais d'un monde purement impératif (C, C++, Java, Visual Basic/ASP, etc.), et là on me dit que la récursion c'est cool. Alors que, lorsque tu viens du monde du C, au contraire, t'as pas envie de faire de la récursion si tu peux l'empêcher, car tu vas dupliquer les variables, etc. Donc techniquement, il a fallu que j'arrive à me retourner le cerveau pour changer complètement mes habitudes, là où les autres de DEUG/prépa étaient relativement « vierges », voire avaient déjà vu des langages comme Scheme ou OCaml (bon ceux-là n'avaient pas de problème avec Lisp en général ;-)).

Enfin, autant les langages comme OCaml, Scala, ou Haskell ont réellement une notation proche de ce que je ferais en maths, autant la syntaxe de Lisp c'est quasiment purement du lambda calcul, qui certes reste un domaine des maths, mais quand même, il est super restreint. J'ai fini par m'y faire à l'époque, et quelque part je trouvais ça rigolo de penser en récursif, mais très clairement, ça n'est pas très bien passé avec les gens qui avaient moins d'expérience pratique avec la programmation.

Pour moi, c'est le Lisp.
[…] Ca ressemble à des maths.
Pour des gens qui ont une formation scientifique, ça ne pose pas de problème. C'est une notation en plus.

Perdu ! Lorsque j'étais en école d'ingénieur, beaucoup de gens en génie info avaient pris « structures de données » et « introduction à l'intelligence artificielle » comme cours de base en premier semestre. Parmi ces gens, beaucoup venaient de la prépa intégrée de l'école, et avaient clairement fait bien plus de maths que moi. Une bonne partie avait aussi suivi une UV d'initiation à l'algorithmique (en Pascal je crois). Bref. Les gens comme moi qui venaient d'IUT avaient clairement un avantage sur les gens qui n'avaient fait « que » des maths lorsqu'il s'est s'agit d'apprendre à programmer en Lisp. Pourtant ils apprenaient l'algo à part (et les TP de l'UV d'algo étaient en C, certes, mais ils n'ont commencé que tard d'une part, et ensuite les élèves voyaient C et Lisp de front, donc ils n'étaient pas pollués par la syntaxe de C à ce moment).

Encore une fois : le langage importe peu, tant que l'équipe enseignante fait correctement son boulot. De toute manière pour les premiers cours d'algo/prog, les profs vont utiliser des sous-ensembles du langage choisi, quel qu'il soit.

Le C n'est pas un problème si le cursus de l'étudiant est de faire de l'informatique. Par contre, il est important d'y aller progressivement. De plus, l'algorithmique, ce n'est pas simplement faire des tris avec données déjà allouées pour toi en mémoire. Au contraire, c'est admettre qu'il y a un besoin de pouvoir créer (et potentiellement détruire) de nouvelles données dynamiquement. L'exemple le plus parlant est la liste chaînée non-bornée. Les bases de l'algo s'apprennent en recréant les structures de données fondamentales et les méthodes pour les traverser et les modifier. Apprendre l'algo (pour un élève en informatique) sans parler des problèmes d'allocation dynamique à un moment donné, c'est quand même gênant (mais ça existe, je connais des élèves qui ont dû apprendre à coder en C++ seulement une fois arrivés au niveau master/doctorat).

Sans doute parce que je n'avais pas abordé les anneaux, groupes et corps avant la fin de ma 1è année d'IUT, et que (par exemple) les IUT génie informatique acceptent aussi les candidatures venant de sections sciences économiques et sociales (à raison).

Selon moi, utiliser la notation hongroise dans le contexte de langages à typage dynamique et faible, c'est une façon de définir une autre forme d'interface : pour reprendre un exemple que j'avais donné en Perl, si j'ai un truc du genre :

my $i_var = 10;
$i_var += $valeur_flottante;

… Alors je m'attends à ce que la prochaine fois que je cherche à lire $i_var, j'aie bien fait attention à le lire en tant qu'entier :

un_petit_calcul(int($i_var));

Évidemment mon exemple est trivial, mais comme l'explique groumly ailleurs, l'idée c'est quand même aussi d'ajouter une certaine sémantique qui ne peut être capturée par le compilateur. Dans le cas de langages fortement typés, préfixer par i_, f_, etc. ne sert à rien (le compilateur a déjà les infos pour te gueuler dessus). Dans des cas plus complexes, du genre :

sub construire_type1 { return { Champ1 => valeur1(), Champ2 => valeur2(), ... }; }
sub construire_type2 { return { AutreChamp1 => valeur1(), AutreChamp2 => valeur2(), ... }; }

my $foo = construire_type1();
my $bar = construire_type2();

# du temps passe...

$foo = $bar; # MAIS C'EST PAS BIEN ! C'EST PAS LES MÊMES TYPES ! :(

sub construire_type1 { return { Champ1 => valeur1(), Champ2 => valeur2(), ... }; }
sub construire_type2 { return { AutreChamp1 => valeur1(), AutreChamp2 => valeur2(), ... }; }

my $t1_foo = construire_type1();
my $t2_bar = construire_type2();

# du temps passe...

$t1_foo = $t2_bar; # MAIS C'EST PAS BIEN ! C'EST PAS LES MÊMES TYPES ! Mais bon au moins c'est plus visible

Ça reste un exemple abstrait, et bien entendu un bon choix pour nommer les variables va très certainement aider à ne pas se planter, avec ou sans préfixes. Mais parfois il est facile de faire des bourdes pour des types qui sont très proches, parce qu'on a mal lu la doc, etc. Et dans un langage dynamique, ça a tendance à avoir des effets plutôt très indésirables (genre une partie des champs est commune à deux types, et au début, tout à l'air de fonctionner, et ensuite des bugs apparaissent « silencieusement » …)

[à propos des allocations dynamiques] Sauf que ce n'est presque plus le cas depuis C++11 et ce ne sera plus du tout le cas dès C++14.

C'est faux. Le monde n'arrêtera pas d'utiliser new/delete juste parce qu'une nouvelle norme sort. J'ai appris le C alors que ça faisait déjà 3 ans que C99 était sorti. Tu penses bien qu'on m'a appris le C89, et que j'ai dû me mettre à jour tout seul. Il faut gérer l'existant (i.e. le maintenir) bien plus qu'on ne crée de nouveaux programmes.

[à propos de code C mélangé à du code C++ par un élève] Ça c'est bien idiot et ça montre bien que ce qui est noté ce n'est pas la réflexion. On parle d'apprendre à gérer correctement la mémoire. Ce qu'il faut c'est résoudre la question de l'allocation et de la libération. Si l'étudiant utilise malloc/free n'est pas un problème tant que c'est cohérent dans son programme.

Je ne vois pas en quoi c'est idiot. Qu'un élève trouve de l'inspiration dans du code ailleurs (quel que soit le langage), soit. Maintenant, l'allocation dynamique explicite en C++ se fait par new et delete/delete [], et pas par malloc/free. Si tu mélanges les deux, ce n'est pas simplement un mauvais style de programmation : tu risques aussi potentiellement de mettre en branle une mécanique complexe avec possiblement deux gestionnaires mémoire. Que new/delete se servent la plupart du temps de malloc/free en sous-main n'est pas requis par la norme à ma connaissance, et ne devrait pas être supposé. Donc je persiste, un étudiant qui n'est pas foutu d'adapter un algo « pur C » en utilisant les new/delete qui vont bien sera pénalisé.

C'est pas complètement débile d'utiliser une convention pour aider à la lecture (ou à l'auto-complétion !) dans beaucoup de cas. J'ai vu pas mal de gens utiliser des préfixes du genre m_ pour une méthode d'instance, s_ pour une méthode de classe, _ pour un membre privé (ou protégé), etc.

Concernant les types dans un langage faiblement ET dynamiquement typé, je trouve au contraire que c'est loin d'être con, s'il y a potentiellement une ambiguïté sur la façon dont on compte se servir de la valeur :

my @valeurs = get_valeurs();
# Je sais, c'est pas très idiomatique, mais j'fais c'que j'veux !@#$
my $distribution = 0;
for my $i (@valeurs) {
    $distribution += $i;
}

# Pour le moment, $distribution est un int
$distribution /= @valeurs; # PAF! $distribution devient float ou double!
$distribution = int($distribution); # troncature, et $distribution redevient un int

Il y a de très bonnes raisons pour lesquelles une valeur devrait être flottante mais doit être représentée sous forme entière (parce que dans la vie réelle, il n'existe pas de version fractionnaire de la quantité modélisée par exemple). Le principe est évidemment d'appliquer les règles de préfixage avec parcimonie : une variable de compteur de boucle n'a pas besoin d'être préfixée, puisque généralement « allouée » au début de la boucle, puis mise à la poubelle à la fin : son contexte est clair et non-ambigu. Mais lorsqu'on parle de variables qu'on passe en paramètre à des fonctions, etc., préfixer les noms de variables peut être utile pour lever les ambiguïtés.

[…] passer par les math est une très bonne idée.

Pas d'accord, et en tout cas pas pour un cours de débutants. Selon moi, une des raisons pour lesquelles les langages fonctionnels ont tant de mal à décoller, c'est en grande partie dû au fait que l'approche pour enseigner la programmation avec ces langages n'est pas pragmatique. Il ne faut pas nier les origines « matheuses » derrière les langages fonctionnels, mais il est à mon avis plus indiqué pour les gens « normaux » (càd : pas forcément très matheux) qu'on leur apprenne à faire des choses pratiques avec les langages. Un exemple de tentative est Land of Lisp ou Practical Common LISP, qui ne sont pas parfait, mais qui essaient d'enseigner LISP d'une façon pragmatique et didactique plutôt que faire dans l'habituelle programmation de fonctions mathématiques genre factorielle ou nombres de Fibonacci (non pas que je sois contre leur utilisation, mais il me semble que c'est pas forcément le meilleur moyen d'enseigner la récursivité à des gens).

Après les gens qui ont un esprit « orienté maths » n'ont souvent que très peu de problèmes pour passer du fonctionnel à l'impératif ou l'objet, mais c'est une tournure d'esprit que tout le monde n'a pas.

Justement on est entrain de parler de personne qui ne sait pas ce qu'il fait.

Non, on est en train de parler de gens qui sont débutants. Débutant ≠ débile. Évidemment les étudiants vont faire des erreurs, mais la plupart du temps il s'agit d'erreurs effectuées dans le cadre du sous-ensemble du langage utilisé pour les TP et projets.

En IUT, mes profs d'algo/prog avaient surtout en horreur les gens qui « avaient déjà trop fait d'informatique ». :-) Parce qu'on avait des automatismes pas forcément géniaux. Par contre, aucun élève n'était pénalisé pour avoir utilisé des portions de langage qui n'avaient pas encore été vus en cours (mais se prenaient des remarques quand leur utilisation complexifiait la solution). C'est un peu comme en maths : si tu utilises une démonstration différente de celle du cours (car tu passes par des théorèmes/sous-démos différentes), mais qu'elle est correcte, un prof ne peut pas te pénaliser pour ça, mais peut commenter sur la complexité de la solution.

Qui va potentiellement faire du free parce que c'est ce qu'il a vu qui marchait dans les exemples de la bibliothèque C qu'il essaie d'utiliser, de quelqu'un qui va voir en cours des méthodes pour ne jamais écrire de new/delete en cours et qui va trouver sur internet des exemples qui font le contraire parce que post C++11, etc.

Juste un truc : c'est aussi pour ça qu'il y a des profs et chargés de TD : pour bien répéter à l'infini aux élèves qu'il faut utiliser new/delete lors des allocation dynamiques (une fois qu'on leur a appris ce que c'était). Lorsque j'apprenais le C, un de nos profs avait comme manie de nous répéter « mallocons, mallocons, freeons, freeon ! ».

Si un élève commence à se ramener avec un code qui contient des malloc et des free dans un exercice noté ou un projet, ben on pénalise l'élève, car il a certes pris l'initiative de lire et reprendre du code pour résoudre une partie d'un programme à réaliser, mais il n'a pas été suffisamment rigoureux pour se demander ce que faisait le code ou même pourquoi les ordres d'allocation utilisaient un vocabulaire différent.

Ah tiens oui. My bad (histoire d'ajouter une pointe de mauvaise foi : mais même ainsi, il raisonne en termes d'entiers relatifs « infinis », au point qu'on pourrait presque parler « d'implementation defined » au lieu de « undefined behavior » :P).

Pas tout à fait : le compilateur raisonne bien en termes d'entiers « infinis » et lorsqu'il raisonne lors de la phase d'analyse sémantique ou bien lors des phases d'optimisation dans le middle-end. Par exemple :

float f = fabs(some_float);

if (f > 0) {  // always true -- compiler should be able to simplify branch
    /* ... */
} else { 
    /* ... */
}

ou bien

int a = ...,
    b = ...;

if (a > 0 && b > 0 && a+b < 0) { /* not possible, a > 0, b > 0 → a+b > 0, ALWAYS ! */
}

Un compilateur aura le droit d'optimiser ces branchements car fabs est une fonction de la libC, donc « magique » et que dans le deuxième cas, le compilateur ne considère pas les limites « physiques » des entiers considérés, mais juste les relations entre eux.

Je trouve que bash est un très mauvais choix pour faire apprendre la programmation structurée aux étudiants. Il ne faut pas oublier qu'on essaie de leur inculquer quelques principes de base, comme la notion de portée des variables, etc. Et bash est très pénible pour ça.