Re: Re : Re: Re : Re: [EDUC] Apprendre l'informatique, oui mais dans quel contexte ?

[David Chemouil <david AT chemouil.fr>]

Hello Charlie


Le 06/11/2013 11:38, cnestel AT free.fr a écrit :
> Je n'ai pas dit le contraire. J'ai juste rebondi sur ton message
> pour ne pas entrer dans un débat stérile sur les langages du message
> précédent. Néanmoins, il recommandait javascript.

OK je croyais que tu croyais que je recommandais JS :-)


> Je suis bien sûr pour un enseignement de la science informatique dès
> le collège.
> Je penche pour des options facultatives. J'ai réalisé des interviews
> par ordi interposé avec certains de mes élèves qui codent. Tous
> m'ont répondu que ce serait bien d'apprendre à utiliser pour tous
> des logiciels en techno et des rudiments de programmation, mais
> qu'il ne fallait pas imposer des cours d'informatique plus poussés
> à tout le monde. Le pire serait de rendre des cours d'informatique aussi 
> chiants
> que n'importe quel autre cours.

Je suis d'accord sur ce point : la programmation (pas toute 
l'informatique) peut assez aisément être présentée de façon 
majoritairement ludique et il faut s'appuyer là-dessus.



> Quand j'étais étudiant en architecture, on avait des cours sur la théorie
> des graphes qu'on appelait "algorithmes" appliqués à des questions
> d'urbanisme, de circulation, de tâches critiques sur un chantier.
>
> Je reste persuadé que l'algorithmie est une science qui trouve à s'appliquer
> à l'informatique. Mais cela ne concerne pas que l'informatique.

Je ne dirais pas les choses comme ça exactement, mais je pense voir ce 
que tu veux dire. À mon avis, si on appelle algorithmique la discipline 
qui pose des questions du genre : "qu'est-ce qu'un algorithme ?", 
"comment comparer deux algorithmes ?", etc., alors c'est bien à 99% une 
branche de l'informatique dans le monde académique.

Si tu poses la question de mettre au point des algorithmes concrets, 
c'est plus variable. Les algorithmes "généralistes" sont de nos jours 
majoritairement abordés en informatique. Avec quand même une parte 
non-négligeable d'apports d'autres sciences (quand les problèmes sont à 
la base issus de ces sciences) : recherche opérationnelle (comme 
l'emploi de diagramme de type PERT pour la maîtrise de chantier), 
mathématiques, physique, économie (ex : le "problème des mariages stables").

Mais ensuite, bien entendu, les sciences modernes allant vers des 
approches plus discrètes, l'emploi d'outils se développant, la création 
d'algorithmes spécifiques à d'autres domaines se répand.


> Jusqu'à présent nous avons vécu principalement sur le modèle de
> la segmentation arborescente - du codex à l'imprimerie, jusqu'aux
> éditeurs/traitements de textes. Enseigner l'usage structuré d'un
> traitement de textes, d'un MediaWiki, d'un CMS, du basique html,
> et même de LaTeX, c'est rester dans le paradigme de l'arborescence.
> Il a progrès technique, mais pas de coupure épistémologique.
[snip]
> L'école doit se donner les moyens, tout en ne lâchant pas prise sur
> le penser, classer sémantique et arborescent, d'apprendre à travailler
> sur des modèles non hiérarchiques.

J'ai déjà entendu ce raisonnement mais il ne me convainc pas vraiment, 
sur la partie épistémologique.

Ceci dit, c'est évidemment très bien de mettre en avant les diverses 
structurations les plus courantes ; d'autre part, les approches 
statistiques et stochastiques en informatique ont vocation à se développer.


> ... on entre là dans une autre dimension. Quand l'EPI dit l'informatique
> c'est à la fois, une science et une technique, elle devrait dire une science
> et un art de.

Il me semble que la position du programmeur est très loin de celle de 
l'artiste. Le fait qu'il y ait clairement une empreinte de l'auteur dans 
un programme, que la "personnalité" transparaisse, n'implique pas que ce 
soit de l'art.

Knuth, avec son "the Art of Programming", est parfois invoqué ici mais 
c'est selon moi un contre-sens : son art vient avec une majuscule et une 
"the ... of ...", ce qui -pour moi- fait référence au sens plus ancien 
de l'Art comme maîtrise technique spécifique à un certain artisan, ex : 
les imprimeurs ou les fabricants d'orgues (deux passions de Knuth). 
C'est à rapprocher des compagnons bâtisseurs de cathédrales qui étaient 
reconnaissables à leur style.



> Il faut aussi tenir compte des filières. On dit que les littéraires
> préfèrent Lisp ou Cobol...

Cobol, c'est uniquement pour les littéraires qui lisent Sade et 
Sacher-Masoch :-)


> > Hélas, la position des chercheurs en programmation est difficile à
> > défendre, en informatique, même auprès des collègues d'autres champs de
> > l'informatique. L'effet réseau, les modes, l'accessibilité à tous de la
> > programmation -d'autant plus forts dans le libre d'ailleurs- sont très
> > bien en général, mais ils ont aussi comme effet une dévalorisation des
> > résultats scientifiques et une certaine stagnation (voire recul) de la
> > qualité des langages.
>
> Il faudrait que tu développes. Car c'est ton terrain. Et je sens que c'est
> quelque chose qui te tient profondément à coeur. Peut être d'autant plus
> difficile à communiquer qu'il faut être membre pour comprendre.

Je vais développer un peu... mais mon but n'est pas de déclencher une 
guerre des langages. Si débat il y a, il faut qu'il soit argumenté...

Donc je pense pour ma part qu'il faut privilégier les langages 
fonctionnels typés. En l'état, ça peut être le fragment fonctionnel 
d'OCaml ou de Scala, ou alors Haskell.

Quelques raisons pédagogiques pour ça :
- les types permettent d'enseigner à raisonner par abstraction et 
permettent par ailleurs de détecter des erreurs avant exécution (pour ma 
part, je préfère savoir qu'un pont ne va pas s'effondrer *avant* de le 
construire)
- pour ceux qui développent de gros programmes, les types sont 
indispensables pour la mise au point de programmes modulaires (ce qu'on 
appelle "types abstraits" dans la littérature scientifique)
- le fonctionnel consiste à voir les programmes comme des fonctions qui 
se composent et se décomposent comme en maths, en physique...
- l'exécution d'un programme fonctionnel est très simple à expliquer 
comme la réécriture du programme en un autre programme (comme la 
récriture des identités remarquables en algèbre par exemple), ça se 
déroule très simplement au tableau. Ce n'est pas le cas des langages 
impératifs qui font en plus appel à une structure (processeur, mémoire, 
allocation...) pas simple à comprendre et qui force à mélanger deux 
niveau d'abstraction (l'application d'un côté, le compilateur et le 
runtime de l'autre)
- enfin le fonctionnel permet de voir de façon très simple LA méthode de 
raisonnement en informatique, à savoir l'induction/récursion 
(généralisation de la récurrence que les élèves voient en maths avec les 
suites)
- prosaïquement, je pense qu'il est préférable de commencer par un 
langage avec ces qualités pour pouvoir mieux affronter les langages 
différents qui ajoutent certaines difficultés sur le plan cognitif 
(faiblesse du typage -tous les langages étant typés contrairement à une 
certaine croyance-, approche impérative, approche objet, gestion mémoire...)

La question du langage web, à savoir Javascript, revenu dans plusieurs 
mails, me paraît décalée. Rien n'empêche de faire de la programmation 
web avec des langages fonctionnels typés (en pratique, pour Ocaml, on 
dispose de Js_of_Ocaml <http://ocsigen.org/js_of_ocaml/> qui compile du 
Ocaml en Javascript, ce dernier étant utilisé comme un assembleur).

Pour finir, pour de jeunes élèves (peut-être même jusque en 4°/3°, je 
sais pas), les langages graphiques me semblent une bonne idée en ce 
qu'ils permettent, en pratique, de se débarrasser des erreurs de syntaxe 
et en ce qu'ils mettent en avant l'idée fondamentale de "syntaxe 
abstraite" (soit la structure du programme, ici directement visible 
graphiquement). C'est dommage que ces langages graphiques soient tous 
impératifs AFAIK.

david