URL: https://linuxfr.org/users/ploum/journaux/et-si-ce-quon-apprenait-ne-marchait-pas Title: Et si ce qu'on apprenait ne marchait pas ? Authors: ploum Date: 2004年05月01日T01:41:21+02:00 Tags: Score: 0 Un éclair de lucidité m'envahit : et si les autorités académiques n'étaient pas si compétentes ? Et si, en fait les "professeurs" pouvait parfois être réellement à coté de la plaque ? Je suis pour le moment en train de réaliser un projet en Oz dans le cadre de ma fac. Oz est un langage peu connu qui a beaucoup de bonnes possibilités mais une syntaxe crado. Il y'a de bonnes idées derrière mais voilà... ( [http://mozart-oz.org(...)](http://mozart-oz.org) ) Le but du projet est d'implémenter un jeu de dame en réseau, avec un server et des clients qui peuvent jouer aux dames. Le Oz offre de nombreuse facilité au niveau réseau. Le cadre est placé... Il y'a quelques mois, j'avais du faire, avec le même binôme, un projet en C relativement simple. Mais nous avions une timeline assez contraignante : on ne pouvait rien implémenter durant les 7 premières semaines, seulement faire du pseudo-code et des petits tests. Les 3 dernières semaines devaient être l'occasion d'implémenter tout et de voir qu'en construisant correctement l'application, ça devait marcher presque tout de suite. Naïvement, nous avions alors suivi ces directives... Inutiles de dire que le programme n'a JAMAIS marché et que même le professeur n'a pas compris pourquoi ça plantait... Retour au projet en Oz. Par paresse et à cause d'autre occupations, mon binôme et moi-même commençont seulement le projet effectif ce lundi, deux semaines après tout le monde. Sur un projet qui compte 4 semaines, ça fait beaucoup. Le retard sera t'il rattrapable ? La majorité des groupes ont déjà des pions qui bougent à l'écran alors que mon binôme et moi-même n'avons presque rien programmé en Oz, et surtout presque rien compris à ce langage, notre premier et dernier "Hello World" remontant à deux mois... (du moins pour moi) Plutôt que de suivre la démarche académique du pseudo-code, je décide de suivre ma méthode personnelle, celle qui a porté ses fruits : la technique du "Hello World amélioré". Il faut savoir que tous mes programmes qui marchent et un peu conséquent sont des Hello World améliorés. J'écris un "Hello World" en suivant un tutoriel du langage en question. Ensuite je l'améliore, en ajoutant des fonctionnalités. ça m'a toujours réussi. Et bien, sur le même principe, nous avons bâti notre jeu de dames. Après 5 jours, plusieurs constats s'imposent : - nous avons, en 5 jours, rattrapé les autres groupes ! - notre programme est très propre, très modulaire et surtout, il marche bien (il est pas fini, mais ce qui est implémenté marche). - notre programme est déjà plus avancé que ce qui est demandé et a déjà plein de fonctionnalités ! La technique utilisée est pourtant simple : on rajoute une fonctionnalité, on teste, on débug et on recommence. Mais ça semble dépasser le monde académique... Oz possède ce qu'on appelle des "functors". D'après le professeur (un des principaux développeur de Oz) et les assistants, c'est l'équivalent d'écrire une bibliothèque statique. Sauf que, un functor est en fait un objet qui peut garder en mémoire des variables créées lors de son importation ! Il n'est donc pas statique du tout !!!!! Cette propriété, découverte par mon binôme et ignorée des assistants a permis de rendre plus propre des cochonneries(dixit mon binôme et je suis d'accord avec lui) que j'avais écrite pour passer outre la limitation statique. Bon, pas grave, je continue... Oz est un langage "sale" à mes yeux (ou du moins ce que j'en connais hein !): tout se mélange. Il est très difficile de séparer l'interface graphique du programme par exemple. En gros, disons que Oz est un langage ultra académique, facilitant les démonstrations de programme, permettant plein de paradigmes théoriques, etc.. Mais il n'est, de ce que je connais, pas du tout adapté au développement applicatif. Je voulais réaliser un truc et je voyais comment le faire en 30 lignes de C/Gtk. Il m'a fallu 150 lignes de Oz et des workaround crades pour le faire.. Pour tenter de travailler un peu correctement et de séparer le programme en plusieurs entités, nous utilisons de manière intensive les fameux "functors". Cela permet de se séparer proprement le boulot et de réutiliser du code à plusieurs endroits. Je pose une question aux assistants : Ils s'étonnent avec effroi que nous utilisions les functors ! En effet, eux attendaient deux fichiers : le client et le serveur, point barre ! tout dans un seul fichier ! ARGHHHH !!! Bon, ensuite, j'ai le malheur de dire que les règles du jeu sont stockées sur le serveur ! En effet, les assistants (ceux qui nous corrigent) voulaient que chaque client contiennent les règles du jeu et que personne jusqu'ici n'a fait le contraire ! Je réplique que n'importe qui peut alors tricher très facilement ! Et si il y'a une légère différence entre les règles de deux clients, que se passe-t'il ? Ah... l'assistant n'y avait pas pensé. Mais dans ce cas-ci, c'est pas grave.. Je continue en disant que c'est bien plus prore de mettre les règles dans le serveur. Réponse : oui, mais ça augmente la bande passante. Là, j'explique que je ne comprend pas, parce que la bande passante est exactement la même ! Mais j'abandonne et je lui dis de laisser tomber. Est-ce qu'il va faire une crise cardiaque si je lui explique que notre règle est stockée dans un fichier à part avec une syntaxe très simple afin de pouvoir écrire aussi facilement que possible de nouvelles règles ? Que nous avons intégré un chat avec le jeu ? Voilà, je me rend compte que finalement, seul obtenir le papier avec écrit "diplôme" compte, que j'apprend beaucoup de choses mais que je dois rester critique vis-à-vis de ce que j'apprend. Mais bon, dans un moi, je vais devoir déblatérer par coeur ce qu'il y'a marqué dans des syllabus, surtout ne pas être critique !!!

AltStyle によって変換されたページ (->オリジナル) /