Discussion :

[DavidDeharbe]

Bonjour,

Je suis enseignant universitaire et ai adopté Objective Caml comme langage pour un cours intitulé "Concepts et Techniques de Programmation", destiné à des étudiant(e)s fraîchements arrivés à l'université pour y suivre une formation de 4 années en Informatique.

Je souhaite échanger des idées sur la séquence de présentation des différents concepts de programmation et leur mise en oeuvre en Objective Caml.

Je suis en train de donner le cours pour la 4ème fois, et j'en suis à la séquence suivante:
1. Types, operateurs et expressions numériques (le langage comme calculatrice)
2. Variables, portée de variable, variables globales et locales.
3. Fonctions, curryfication, fonctions d'ordre supérieur.
4. Expressions conditionnelles et le type booléen.
5. Fonctions récursives
6. Types registres
7. Filtrage ("pattern matching")
8. Types tuples
9. Types variants
10. Listes
11. Types et fonctions génériques
12. Références
13. Programmation impérative (séquence, boucles)
14. Vecteurs
15. Entrées-sorties textuelles
16. Construction de programmes
17. Programmation modulaire
18. Programmation orientée à classes
19. Programmation graphique

Les items 17., 18. et 19. sont optionnels et introduits si la classe arrive à bien assimiler les concepts antérieurs.

David.
--

[gorgonite]

pour infos, une présentation du langage OCaml et de ces fonctionnalités est en cours de rédaction sur dvp.com (http://gorgonite.developpez.com/tuto...presentation/), et InOCamlWeTrust avait opté pour un plan légèrement différent... mais qui peut sembler plus adaptée aux personnes ayant déjà quelques bases de programmation

-------------------------------------------


le plan que vous proposez me semble assez bon... mais qu'en est-il du découpage des parties par rapport aux séances de cours ?

par exemple, référence et programmation impérative sont-ells vues dans la même séance (ce qui me semblerait logique)

en effet, un mauvais découpage d'un bon cours, peut être préjudiciable à la pédagogie (mais je ne vous apprends rien, vous êtes prof )

[Garulfo]

Bonjour,
Je suis enseignant universitaire[...]
David.
--

Voici le plan de ce que j'enseigne pour Scheme
1- éléments de syntaxe [1,2,4]
2- Expressions symboliques [7,10]
3- Programmation fonctionnelle [3,5]
4- Programmation impérative [13]
5- Évaluations et ordres
6- Environnements et fermetures
7- Données structurées et algorithmes
8- Appels par continuation
9- Macros
10- Flots et flots infinis
11- Programmation par objets [18]

Chaque chapitre représente une semaine (2h de cours + 2h de travaux dirigés en lab environ). J'ai mis entre crochets les liens évidents pour le reste cela dépend ce que tu donnes dans le détail.

Personnellement j'adore le chapitre 8 qui est rarement enseigné mais permet de leurs montrer comment implémenter des mécanismes d'exceptions en e cumulant avec le 9. J'aime beaucoup le 11 pour leur montrer le fondement des objets, Scheme offrant une solution très élégante. Le 10 est un must aussi car ils ne verront ça nul part ailleurs.

Cependant pour moi c'est un cours de 3e session (deuxième année donc).

Dans ton cas, il faut mettre plus l'emphase sur les principes et les méthodes de développement, et moins sur les éléments très particulier au langage fonctionnel.

Quel est le temps accordé à chaque chapitre ?

[HS]On partage beaucoup en recherche aussi je vois [/HS]

[Jedai]

10- Flots et flots infinis

Le 10 est un must aussi car ils ne verront ça nul part ailleurs.

Si, en Haskell non ? C'est parfaitement naturel de travailler avec des listes infinies en Haskell, à moins que tu ne parles de tout à fait autre chose ? (je dois avouer que je ne suis pas vraiment un connaisseur en Scheme)
A moins que tu ne veuilles dire que les étudiants ne risquent pas de tomber sur beaucoup d'autres cours abordant le sujet ? (bien que les itérateurs permettent des choses très proches dans d'autres langages, moins élégamment, soit)

NB : Je sais que d'autres langages permettent la même chose (OCaml entre autres), mais je n'en avais jamais rencontré qui le rende aussi "évident" qu'Haskell (ceci découlant directement de l'évaluation paresseuse bien sûr).

--
Jedaï

[gorgonite]

NB : Je sais que d'autres langages permettent la même chose (OCaml entre autres), mais je n'en avais jamais rencontré qui le rende aussi "évident" qu'Haskell (ceci découlant directement de l'évaluation paresseuse bien sûr).

+1


d'ailleurs, ce n'est pas pour rien que Haskell est utilisé pour modéliser des structures manipulant des flux d'information "non stop" comme les réseaux, circuits électroniques, etc. (cf le projet Lava par exemple)

[InOCamlWeTrust]

D'accord... mais enfin, vous conviendrez tout de même que les flots Caml, c'est quasiment des listes paresseuses, non ? On peut pas dire que leur manipulation diffère énormément de celle des listes : ça se filtre, il y a le mot-clef parser, ça s'écrit presque pareil, etc... Le seul truc qui me dérange, c'est leur utilisation avec le module Stream, entre autres l'impossibilité de mélanger les flots issus de Stream et ceux construits à la main : je trouve qu'il y aurait un effort à faire de ce côté-là.

[gorgonite]

D'accord... mais enfin, vous conviendrez tout de même que les flots Caml, c'est quasiment des listes paresseuses, non ? On peut pas dire que leur manipulation diffère énormément de celle des listes : ça se filtre, il y a le mot-clef parser, ça s'écrit presque pareil, etc...

tout à fait
d'ailleurs, c'est très bien décrit dans le papier d'origine d'implémentation des structures paresseuses en Caml
(Michel Mauny 1992, si je ne me trompe pas )

edit confirmé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Integrating lazy evaluation in strict ML, Michel Mauny
 
@TechReport{inria-techniques-137,
  author = 	 "Michel Mauny",
  title = 	 "Integrating lazy evaluation in strict ML",
  institution =  "Institut National de Recherche en Informatique et an
		  Automatique",
  year = 	 1992,
  number =	 "Rapports Techniques No.137"
}

Le seul truc qui me dérange, c'est leur utilisation avec le module Stream, entre autres l'impossibilité de mélanger les flots issus de Stream et ceux construits à la main : je trouve qu'il y aurait un effort à faire de ce côté-là.

perso, je fais plutot du Haskell dans ces cas-là... donc je peux pas trop de dire

[Garulfo]

Si, en Haskell non ? [...]
Jedaï

Bien sûr en Haskell aussi quand je disais qu'ils ne le verraient nulle part ailleurs, je parlais hors de la programmation fonctionnelle. Le Scheme et le Haskell sont très proches de toute façon. Plus encore que le Scheme et le ML...

Et IOCWT a complètement raison puisque les flots infinis sont des listes évaluées de manière paresseuse. Quelque soit le langage, c'est de ça qu'on parle quand on parle de flots infinis.

Pour des gens qui croient s'y connaître en informatique (étudiants de 2e année) c'est souvent assez incroyable. De même que le continuation passing style.

[gorgonite]

De même que le continuation passing style.

pour le CPS, il vaut mieux voir SML et ses call/cc

[Garulfo]

pour le CPS, il vaut mieux voir SML et ses call/cc

Ou Scheme... ou Haskell...

Mais tu parles des call/cc.
On peut coder des CPS à la main.
C'est ça le plus intéressant.
Après, si on a compris, il est pertinent de voir le call/cc.

C'est comme dépecer un système objet en scheme (ou autres).
On se rend compte du point de vue dual très vite.

[InOCamlWeTrust]

Les items 17., 18. et 19. sont optionnels et introduits si la classe arrive a bien assimiler les concepts anterieurs.

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

La programmation graphique devrait être relayée au stade de jouet, à mon avis, et les forumistes ici et là cherchant quasi-désespérément une solution à leurs problèmes avec le module Graphics le montrent bien. Je pense qu'en parler ou faire un ou deux TP n'est pas une mauvaise idée, mais il faudrait insister lourdement sur le fait que ce ne sont que des exercices, et non des modèles de véritable programmation graphique, un monde à part entière, disposant de ses propres compilateurs, et qui se fait quasiment, d'ailleurs, entièrement en C (sauf rares cas).

La programmation orientée objet peut être vue dans la partie modulaire. Un module définissant un type principal et l'exportant sous forme abstraite, peut être vu comme une classe, dont les méthodes sont les fonctions, qui ici prennent, en général, un paramètre supplémentaire, du type le type principal. Les modules String, Stack, Queue, Map et Set de la librairie standard en sont de bons exemples.

Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose, étant donné que le système objet de Objective Caml est parfois complexe, surtout très fin dans l'approche et pas vraiment standard.

A ce stade, la question des foncteurs reste encore ouverte, étant donné que c'est une chose que l'on ne trouve nulle part ailleurs.

Il serait bon (et très sain) de présenter (ou dire deux mots) sur l'ensemble de la distribution :

- énumération des modules et possibilités de la librairie standard
- présentation des compilateurs ocamlc et ocamlopt
- ocamllex et ocamlyacc (juste dire ce dont il s'agit, hein !)
- ocamldep et les Makefile (très très très utiles... surtout que ça sert pour n'importe quel autre langage)
- threads
- module Unix (juste dire que ça existe et que c'est bien !)
- Camlp4 (présenter et en parler un tout petit peu, car pour les flots, c'est indispensable, même si, c'est vrai, on peut l'utiliser sans savoir comment !)

[Garulfo]

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

Pas exactement. La programmation modulaire (utilisation de modules indépendant sous forme boîte noire) est indépendante en théorie de la programmation structurée (utilisation des trois énoncés classiques pour la construction d'un programme). Cependant il est vrai qu'elles sont souvent liées en pratique.

Mais on peut très bien commencer par parler des principes de la programmation modulaire sont parler des modules de ocaml. À la fin du cours, on peut parler des modules d'ocaml, et revenir sur ces principes en expliquant comment ils sont bien représentés dans le langage.

La programmation graphique [...]

La programmation orientée objet peut être vue dans la partie modulaire. [...]
Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose[...].

Encore une fois, on peut parler des principes et montrer comment implémenter les mécanismes de programmations objets sans utiliser les objets d'ocaml.

Tout dépend des objectifs pédagogiques du cours. Si le but est de présenter les concepts qui seront repris dans les autres cours, alors c'est une bonne chose de le présenter comme je le propose. Si par contre c'est un cours qui se veut suffisant (pour des étudiants en physique ou en math) alors je suis d'accord avec IOCWT.

[DavidDeharbe]

Mauvaise idée, d'après moi.

La programmation modulaire est le B-A-BA de la programmation structurée, et l'aborder avec Objective Caml est une très bonne chose.

Mon objectif est plutôt de donner les outils pour faire de la programmation à petite échelle (programming in the small) qu'à grande échelle (programming in the large). Pour autant que je trouve la programmation modulaire intéressante, et nécessaire, l'expérience m'a montré qu'il (m') était difficile de faire passer ce concept. En effet ces très jeunes étudiants commencent à apprendre à programmer et ne saisissent pas vraiment la problématique de la construction de grands programmes. Mon objectif est de leur fournir les outils intellectuels pour mettre en oeuvre les structures de données et algorithmes qu'ils voient par la suite.

Leur formation inclut d'autres matières, telles que "Paradigmes de Concepts et Techniques de Programmation" où sont exposés des concepts plus avancés de programmation.

La programmation graphique devrait être relayée au stade de jouet, à mon avis, et les forumistes ici et là cherchant quasi-désespérément une solution à leurs problèmes avec le module Graphics le montrent bien. Je pense qu'en parler ou faire un ou deux TP n'est pas une mauvaise idée, mais il faudrait insister lourdement sur le fait que ce ne sont que des exercices, et non des modèles de véritable programmation graphique, un monde à part entière, disposant de ses propres compilateurs, et qui se fait quasiment, d'ailleurs, entièrement en C (sauf rares cas).

Tout à fait d'accord. Néanmoins, l'attention des étudiants est beaucoup plus grande lorsque je leur montre comment programmer les primitives du langage LOGO em OCaml que la séquence de Fibonacci (même si Dan Brown a donné un bon coup de main).

Parler, pour un cours d'introduction destiné à des débutants, de classe et objet Objective Caml n'est absolument pas une bonne chose, étant donné que le système objet de Objective Caml est parfois complexe, surtout très fin dans l'approche et pas vraiment standard.

A ce stade, la question des foncteurs reste encore ouverte, étant donné que c'est une chose que l'on ne trouve nulle part ailleurs.

Oui, d'accord (voir d'ailleurs mon 1º paragraphe). Mais il me semble que Java commence à s'en approcher.

[QUOTE]

Il serait bon (et très sain) de présenter (ou dire deux mots) sur l'ensemble de la distribution :

- énumération des modules et possibilités de la librairie standard

J'évoque au fur et à mesure certains modules.

- présentation des compilateurs ocamlc et ocamlopt

C'est présenté dès le début, en fait. Et j'essaie d'y revenir à la fin (module Arg).

- ocamllex et ocamlyacc (juste dire ce dont il s'agit, hein !)
- ocamldep et les Makefile (très très très utiles... surtout que ça sert pour n'importe quel autre langage)
- threads
- module Unix (juste dire que ça existe et que c'est bien !)
- Camlp4 (présenter et en parler un tout petit peu, car pour les flots, c'est indispensable, même si, c'est vrai, on peut l'utiliser sans savoir comment !)

Bonne suggestion, je pourrai en parler au dernier cours, histoire de faire le lien avec les autres cours qu'ils vont suivre dans leur formation.

Merci pour le feed-back.

David.
--