lasher a écrit 2753 commentaires

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.

Comme l'expliquait rewind, de toute manière tu ne veux pas enseigner tout le langage aux élèves de 1è année, c'est tout simplement impossible. Donc personnellement, C, C++, Perl, Python, Ruby, Scheme, Scala, OCaml, F#, etc., je m'en cogne un peu. :-)

Choisir un langage « suffisamment » fortement typé aide les élèves à trouver leurs erreurs à la compilation, du coup C++ n'est pas forcément une mauvaise idée, mais très honnêtement, Scala non plus, ni F#, ni OCaml, ni C (qui est faiblement typé, mais si on dit aux élèves qu'il faut mettre -Wall -Wextra -pedantic sur la ligne de compilation sinon on n'aidera pas, les élèves finissent par piger), etc.

Tu parlais des espaces de nommages : ça va passer à la trappe chez les élèves de 1è année. Ce sera déjà bien s'ils comprennent la notion de programmation modulaire (découper le programme en fonctions, etc.).

Pas de gestion des pointeurs : pour les tableau il y a le type std::array, que les étudiants peuvent apprendre sans chercher à comprendre comme ça marche sous le capot (ie. les templates)

J'ai tendance à bien aimer la notion d'enseigner « C + STL » aux élèves, mais j'avoue que même dans un commentaires à côté, j'ai un peu surestimé ce qu'on apprenait aux étudiants de fac classique en 1è année. Du coup, même du « C + cout/cin » et std::string c'est généralement suffisant.

Et surtout pas de problème de passage par référence/par valeur.

Ce n'est un réel problème que si tu désires discuter de la différence. En tant que prof, tu édictes les règles. Si tu dis « tout paramètre est copié lorsqu'il est passé à une fonction, sauf les tableaux qui eux seront modifiés pour de bon », les élèves accepteront la règle. Ils demanderont peut-être pourquoi, mais la réponse que je donnerais c'est « pour simplifier les choses dans un premier temps, et dans quelques semaines, on reviendra sur le sujet ».

Pourvu qu’on se restreigne aux notions simples le C++ fait l’affaire.

Oui, mais n'importe quel langage fait l'affaire dans ce cas. La question pour moi est de savoir quel langage il faut choisir lorsque les trucs de base (structures de contrôles, algos simples, etc.) ont été acquis : est-ce qu'on approfondit avec le même langage, ou bien est-ce qu'on change au risque de perdre encore quelques semaines à apprendre un nouveau langage ?

Pas d'accord. On peut parfaitement apprendre un langage au fur et à mesure des cours d'algo (c'est d'ailleurs comme ça que j'ai appris en IUT). L'important est d'adapter les algos au sous-ensemble du langage considéré. Ensuite, au fur et à mesure on peut ajouter des aspects du langage quand on veut aborder des structures de données plus compliquées — mais pour les algos de base (tri, comprendre le principe d'échange de variables, etc.), on peut se contenter d'un tout petit sous ensemble et faire déjà pas mal. À Versailles, si ça n'a pas changé, en L1 ils ont construit un environnement de travail au-dessus du C en utilisant la SDL, et tous les algos/problèmes à réaliser/résoudre sont faits en utilisant les « nouvelles » primitives (genre tracer_droite, afficher_point, etc.), et au fur et à mesure ils découvrent aussi la bibliothèque standard. Je sais qu'en 1è/2è année de fac à l'université de Rice (Houston,TX USA), ils utilisent Python, mais au moins en 2è année, ils demandent au élèves un truc qui peut sembler bizarre au début : ils ne peuvent écrire qu'une seule fois dans une variable, et doivent numéroter les variables s'ils veulent « écraser » la valeur. La finalité est de faire une intro à un style de programmation plus fonctionnel une fois qu'ils ont les bases (et parce que ça aide pour pas mal d'algos parallèles, qui sont ensuite enseignés en 3è et 4è années).

Que ce soit la méthode à laquelle j'ai été sujet (sous-ensemble du C qu'on agrandit au fur et à mesure, quand la compréhension est suffisante) ou un langage avec de « nouvelles » primitives pour aider à faciliter certaines tâches¹, l'important c'est la notion de progression. En IUT, nous faisions tous nos exos d'algo en C sur papier, et c'était à nous d'aller ensuite sur les machines de la fac (ou chez nous) pour coder les programmes sur PC. Nous avions aussi des projets (3 en C en 6 mois) à effectuer en binôme.

Il ne faut pas oublier que les algos et structures de données de bases sont vraiment simples :

• Structures de contrôles (while, for, if/else do…while, switch)
• Types composés (struct en C) et tableaux (et combinaison des deux)
• Tris et recherche de tableaux (tri à bulle, recherche dichotomique)
• Notion de « sauts » : break, continue, goto (avec les avertissements qui vont bien)
• Tableaux d'indices (pour trier suivante différents critères sans toucher au tableau « lourd »)
• Une fois que les pointeurs ont été vus : listes chaînées, arbres, et graphes.

Rien que ça, ça prend beaucoup de temps à enseigner à des étudiants qui ne savent rien de la programmation. En IUT génie info en parallèle, les élèves font de la logique formelle, apprennent un peu d'archi des ordinateurs (logique de Boole, tableaux de Karnaugh, portes logiques), commencent à voir ce qu'est une base de données, et font pas mal de génie logiciel. En fac classique, en première année de cursus scientifique, à côté de l'intro à la programmation/algorithmique, il y a les maths, la physique, la chimie, la bio, etc.

Bref, en un semestre, voir déjà les points que j'ai énumérés, c'est pas mal.

Ca c'est bien une idée de prof dans sa tour d'ivoire. Le typage, c'est un concept difficile à apprendre pour "des étudiants qui ne se destinent pas forcément à l'informatique".

Tu n'es pas obligé de donner un cours sur la théorie des types et le lambda calcul. Si on parle (comme semble l'indiquer le journal) d'étudiants en informatique, de toute manière, en trois ans il serait bon qu'ils voient au final 2 ou 3 paradigmes (procédural classique, objet, et fonctionnel), l'ordre important finalement relativement peu pour peu que l'équipe enseignante prenne sur elle de fournir des primitives suffisantes ou une progression spécifique dans l'apprentissage du langage si le langage de base + bibliothèque standard ne suffisent pas dans le cas du premier langage.

On peut imposer des standards de code si on utiliser un langage dynamique, au moins au début, par exemple la notation hongroise¹. La notion de typage n'est pas compliquée à apprendre à quiconque a pigé l'une des bases fondamentales des exercices qu'on faisait en physique, de la 4è jusqu'en Seconde, et au-delà pour ceux qui ont suivi une section scientifique : il faut une homogénéité des unités, et donc, s'il est possible d'ajouter des objets (au sens « théorie des langages du terme », pas POO) qui sont de type fruits ensemble, on ne peut pas additionner des fruits et des boulons. Par contre si je suis déjà dans le contexte des fruits et que je veux « zoomer », je dois faire la distinction entre des oranges et des pommes.

On n'est pas obligé d'utiliser des explications théoriques, et on peut rester très terre à terre, en expliquant que certains langages refusent de compiler/faire tourner un programme si on n'a pas garanti que les variables qu'on fait interagir entre elles ne correspondent pas aux mêmes choses (au même type) qu'on veut représenter, alors que d'autres sont plus permissifs et autorisent d'additionner des choux et des carottes, mais que le résultat n'est pas forcément celui auquel on s'attend.

Lorsque j'étais en IUT, nous avons commencé l'algo/prog par l'apprentissage du C. Nous n'avons vu les pointeurs que très tard : nous avions commencé en Septembre, et nous n'avons commencé à voir les pointeurs qu'à partir de Décembre je pense. Du coup nous passions les structures par valeur, comme des gros bourrins, et nous avions tout plein d'algos qui se contentaient d'utiliser des tableaux et des tableaux d'indices, ainsi que des chaînes de caractères (qui n'étaient donc que des tableaux elles-mêmes). Pour déclarer des chaînes, on nous faisait passer par des typedefs :

typedef char CH20[21];

CH20 une_chaine_de_vingt_chars;

/* le reste */

Sans forcément nous donner le vocabulaire à l'époque, ou alors en passant², on nous avait dit deux choses : (1) on nous expliquerait plus tard ce qui se cache sous le string (i.e. pourquoi déclarer un tableau de 21 chars et pas 20), et (2) que les tableaux qu'on passait par des fonctions étaient modifiés « pour de bon » si les fonctions appelées les modifiaient.

Qu'entends-tu par "entrées-sorties" ?

Je me permets de répondre: en intro à l'algo/prog, il faut pouvoir lire l'entrée du clavier, écrire sur un écran, puis un peu plus tard faire de même avec des fichiers.

Tu délires là non ? C++ pour apprendre ? Il y a bien plus simple aujourd'hui. Tu veux dégouter tes étudiants de la programmation ?

C'est parce que tu penses à C++ tel qu'il est utilisé professionnellement. Tu n'es absolument pas obligé d'apprendre C++ avec les templates. En fait, tu peux parfaitement faire du C++ qui ne soit que « C + STL », en rappelant bien à tes élèves que si jamais ils ont des erreurs bizarres à la compilation, c'est sans doute qu'ils ont mal écrit la ligne qui déclare/définit un conteneur STL utilisé, genre

#include <iostream>
#include <vector>

// pas besoin d'expliquer les espaces de nommage; il suffit de dire que c'est pour raccourcir les noms des fonctions
using namespace std; 

// ...

struct foo 
{
    // contenu
};

int
main(void)
{
    vector<fooo> foovec;
    // on fait quelque chose avec foovec, reste du code, etc.
}

Non, le contexte du journal c'est le milieu professionnel, pas chez le particulier.