Re: Pascal...

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.
}