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(...) )
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 !!!
Journal Et si ce qu'on apprenait ne marchait pas ?
1
mai
2004
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Olivier Dzwoniarkiewicz . Évalué à 6.
Cela fait maintenant 5 ans que je suis aux études supérieures. Je commence à avoir une certaine habitude des études, travaux de groupes etc... Je suis également une formation qui touche à l'informatique (étonnant me diras-tu :p) : analyste/programmeur pour être précis.
Et je dois t'avouer que cela fait très longtemps que j'ai remarqué que les assistants voir même les profs dans certains cas ne sont pas à même de nous aider à comprendre, à avancer dans certaines matières. J'ai des fois l'impression qu'ils sont tellement à côté de la plaque que, d'après moi, ils ne mériteraient pas leur diplôme.
Je trouve ce genre de situation très regretable et malheureusement nous ne pouvons rien y faire (du moins je ne le pense pas). Évidement il ne faut pas généraliser... il existe de très bon professeurs (bien qu'à mon avis ils soient rares). Certains sont très bons dans la théorie, d'autres sont meilleurs dans la pratique. Personelement j'ai connu un seul prof qui m'aie vraiment impressionné tant au niveau connaissances pures qu'au niveau pratique. Cela me parait très peu sur 5 ans d'études :)
Je me suis donc résolu à me plier à leur _bêtes_ exigences tout cela pour avoir mon diplôme (que je devrais normalement avoir l'année prochaine). Mais je dois bien t'avouer que ça me reste en travers de la gorge... J'ai l'impression certaines fois d'aller à l'école pour rien (je t'avouerais d'ailleurs que j'ai un taux d'absentéisme assez élevé :) ).
Le temps que je ne passe pas à l'école, je l'utilise pour approfondir les domaines qui ne l'ont pas été assez (ou mal) , d'après moi, à l'école. J'ai ainsi acquis une certaine notoriété dans la région qui me permet de travailler dans le domaine de l'info en tant que programmeur pour certaines entreprises ainsi que d'administrateur réseaux/UNIX pour d'autres. Quand les profs se plaignent que je ne vient pas aux cours, je leur montre ce que je fais à l'extérieur de l'enceinte scolaire et ils arrêtent de m'emmerder.
Je mène donc une sorte de "double" vie, je rends ce qu'il faut rendre et comme ils le veulent, mais je fais le minimum pour le papier. Tout en leur faisant bien comprendre que ce ne sera pas grâce à eux que j'aurais plus tard du boulot. Certains ont compris la leçon et commencent à changer leur manière de donner cours car cela fait mauvais genre quand 10 élèves viennent auprès de moi pour que je leur explique une matière :)
Je compatis donc avec toi, tout en te suggérant de réagir face à ce fléau de l'éducation nationale (je signale que je suis belge et que c'est pareil ici qu'en France :p). Bien sur il faut faire cela raisonnablement autrement tu vas te casser les dents face à des profs abrutis. Bonne merde pour la suite.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
2) Je ne traite pas les profs ni assistants d'abrutis, loin de là. Certains sont exceptionnellement doués, d'autres moins et ils sont en majorité très sympa (surtout les assistants). Oui, certains sont des abrutis, heureusement pas tous..
Mais force est de constater que leur connaissance ne s'applique en fait que rarement à ce que nous sommes censés apprendre...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Olivier Dzwoniarkiewicz . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ckyl . Évalué à 2.
Les méthodes de prog de la moitié de profs que j'ai eu etaient assez flippantes et il est clair qu'ils ne maitrisent pas leur domaine. Et je ne parle même pas d'une sécuritée/modularité/inventivité minimale dans le code.
Bref il faut avoir de la chance, prendre ce qu'il y a d'interessant chez les gens compétent et rendre ce qu'il faut pour avoir ton bout de papier sans pour autant perdre ton temps avec les butés/abrutis/incompétents.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Erwan . Évalué à 3.
Autre chose, l'info c'est tres large et on demande souvent aux profs des trucs qui ne sont pas de leur specialite. Genre si on demande a un mec de genie logiciel de faire de la BD, il est possible qu'il s'y connaisse moins que les etudiants.
Pour finir, si tu te documentes bien sur un langage inconnu (au hasard, le Oz) tu le connaitra forcement mieux qu'un prof. Il ne peut pas etre omniscient.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Anonyme . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Fabimaru (site web personnel) . Évalué à 0.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Sixel . Évalué à 1.
"Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Anonyme . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Pooly (site web personnel) . Évalué à 2.
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par jemore . Évalué à 1.
Bravo, tu viens de redecouvrir la methode de programmation XP.
http://wikibooks.org/wiki/Fr_Programmation_XP(...)
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Merci pour le lien.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Parce qu'entre Windows XP, programmation XP, Athlon XP,... ça commence à bien faire cette mode ridicule.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Erwan . Évalué à 9.
Situation 1:
Chef - Vous vous organisez comment, les gars ?
Devel - Ben on s'organise pas, on code ce qu'on a envie de coder et quand ca plante on essaye de trouver pourquoi. D'ailleurs on cherche pas a savoir a l'avance a quoi ca va ressembler, on code et si faut changer l'architecture en cours de route, ben on le fait.
Chef - Heu, comment vous dire...
Situation 2:
Chef - Vous vous organisez comment, les gars ?
Devel - On utilise la methode "Extreme Programming", ca vient des States!
Chef - Super les gars, continuez comme ca.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Ramso . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Anonyme . Évalué à 3.
Il propose des techniques telles que le travail en binome, la creation de protos et l'evolution de ces protos, des contacts avec le client tres frequents et présents tout au long du developpement.
Ainsi, si un erreur de conception ou d'appreciation des besoins du client existe, elle est detectée rapidement et ces impactes sont relativement faibles.
Cette methode s'oppose au cycle en V ou le client n'entervient qu'au debut du process. Le developpement ce fait en boite noire et on ressort a la fin un produit, ne repondant pas forcement aux besoins du client.
Dans la pratique les boites utilisent certains conceptes de l'XP sans vraiment le savoir ; elles n'appliquent que tres rarement le cylce en V a la lettre.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Black Fox . Évalué à 1.
Le planing des choses à exécuter, les itérations courtes avec des objectifs précis à remplir c'est vrai que ça ne ressemble pas à de l'organisation.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par TImaniac (site web personnel) . Évalué à 1.
- on rédige les tests unitaires.
- on s'arrange pour qu'ils plantent.
- on recommence jusqu'à ce qu'ils passent.
Tout celà en binôme, on fait des retours aux architectes qui dirigent les programmeurs vers la nouvelle étape, et on affine au fur et à mesure le planning (itérations).
La méthode XP c'est très structuré mais pas adapté aux projets qui comporte plus du'ne grosse dizaine de programmeurs, en tout cas c'est loin de la technique du newbie : j'écris je debug je recommence et c'est tout...
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Cerel (site web personnel) . Évalué à 1.
Elle est aussi connue sous le nom de "Trial And Error".
Comme son nom l'indique, on essaye et l'on corrige au fur et a mesure.
Bien que cette methode soit assez intuitive et assez facile a metre en oeuvre, elle possede aussi ces faiblesses....
Cette methode fonctionne relativement bien lorsqu'il s'agit de petits projets ou des projets d'amvergure moyenne.
Cependant cette methode montre vite ces limites lorsque le projet est un soit peu important.
Pour developper ce genre de projet il existe d'autre methode, dont la methode de "developpement en V" en fait partie.
Une recherche sur google te permetera surement de trouver plein de documentation dessus.
Sache que meme si cette methode peut sembler contraignante au debut, elle permet de gagner beacoup de temps par la suite.
Par plus tard que hier matin, notre prof d'informatique nous a racconte une anecdote.
Il parlait d'une eleve en informatique qui faisait son travail de diplome (qui dure 4 mois en tout). Il s'etonnait et s'inquietait du fait que l'edite eleve n'avait rien code au bout de 1 mois et demi voir 2 mois. Elle avait passe le plus clair de son temps a creer des schemas ainsi qu'a creer une description precise des taches a accomplir.
Ce n'est qu'apres une derniere visite avec son client, afin de metre les derniers details au clair, qu'elle commenca a coder.
Et la elle coda "tout droit".
Une fois que les schemas, et les taches sont faites, le coding devient incryablement "simple". Car il ne sagit plus que de "traduire". Etant donne que tout le travail de pensee a ete fait avant, tu peux te concentrer uniquement sur le coding.
Evidement il serait inutile d'utiliser ce genre d'approches pour des petits programmes. Mais lorsque tu dois realiser des programmes d'amvergure, le "trial and error" n'est plus vraiment utile.
Pour conclure sache que moi aussi je rencontre des assistants ainsi que des profs "inquietants", neanmoins il ne faut pas jeter tout l'enseignement, il y a de bonnes choses aussi.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par thaodalf . Évalué à 1.
d'apres mon experience faire tous le code a la fin comme l'etudiante dans ton exemple c'est le meilleur moyen d'avoir un log qui n'exploite aucune specificité du langage de la becane ou des libs.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Anonyme . Évalué à 1.
La programmation modulaire permet d'obtenir tres rapidement un proto a montrer au client. Elle permet de reutiliser le maximum de code, de faire evoluer les specif sans trop remettre en cause ce qui a deja ete fait.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Fabimaru (site web personnel) . Évalué à 2.
Donc, modules et protos comme l'ont déjà fait remarqué certains.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Black Fox . Évalué à 1.
Mais ça ne marche que dans les rêves ou dans les joli dossiers présentés en classe :D
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
http://www.linux-france.org/article/these/cathedrale-bazar/cathedra(...)
Le même genre de théorie à été formalisé de pleins de façons différentes, mais ça revient toujours plus ou moins à la même chose :
Cathédrale <-> Bazar
Développement en V <-> Développement en spirale
Développement cascade <-> Développement incrémental
...
Il n'y en a pas un qui est meilleur que l'autre dans l'absolu. Souvent, le développement incrémental (on rajoute les fonctions une par une) est la solution de facilité. Mais au bout de quelques années à essayer de maintenir un projet qui avance pas à pas, surtout si on fait gaffe à chaque pas à garder la compatibilité avec l'existant, c'est parfois la cata. On se rends compte trop tard que le truc est mal pensé à la base et qu'il faut tout réécrire.
D'ailleurs, quand tu regardes l'évolution de pas mal de logiciels, souvent, les améliorations importantes correspondent à une réécriture complete d'une partie du programme. Regardes Mozilla, par exemple. Est-ce qu'ils auraient réussi à faire XUL en ajoutant des trucs "petit à petit" à Netscape 4 ? Non, heureusement qu'ils ont tout mis par terre pour faire Moz 1.0 !
Le fait que le logiciel soit libre ou pas a aussi son importance. Souvent, le logiciel propriétaire va adopter un cycle en cascade. On réfléchi bien, on fait plein de R&D, et un jour, on se met au boulot, on teste, et on sort une version 1.0.
Pour du logiciel libre, "realease early, release often" (Linus). Si tu veux des contributeurs, il faut une démo fonctionnelle le plus rapidement possible.
Après, il ne faut pas croire que ce que tu fais à l'école, c'est la même chose que ce que tu feras dans l'industrie. On essaye de te faire faire des trucs pédagogiques, de te montrer des trucs que tu n'aurais pas fait spontanément. Si on te laissait faire comme tu le sentais dès le début, ou est l'intérêt de l'école.
Et puis il faut voir aussi que les profs en école sont en général "vieux chercheurs", qui savent bien faire du LaTeX, mais pour ce qui est de coder, c'est plus que variable !
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
1) Un shéma des différents composants à implémenter et la manière dont ils s'interfacent.
2) Dévelovepement indépendant de chaque composant selon la méthode du "Hello World"
3 éventuel) On note les défauts de la structure et ce qui ne va pas. On réécrit le programme en tenant compte des erreurs apprises.
Mais je crois que tout cela dépend aussi de la personnalité du programmeur.
Personnellement, sans un exemple concret dans un langage, je ne sais pas écrire le moindre prorgramme : j'oublie tout de suite la syntaxe, les détails comme les entêtes, etc... Alors j'écris le Hello World et là, j'ai le langage dans les doigts et tout le reste du programme vient tout seul ensuite...
Certains, au contraire ont une réelle mémoire de la syntaxe et sont plus à l'aise avec la grammaire syntaxique du langage.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ckyl . Évalué à 1.
Bref quand tu n'es pas un guru dans un domaine l'approche de monter petit a petit me semble naturelle étant donnée que tu t'appercois assez vite des erreurs que tu peux faire et les corriger se résume a réecrire un petit bout de code ce qui ne va pas prendre longtemps.
Si tu tentes de tout monter d'un coup, soit ca passe soit ca casse et tout part direct a la poubelle.
Ma méthode est en général de réfléchir a l'archi de la chose quelque temps. Quand j'ai une vue un peu claire du truc je commence a coder quelque chose a l'arrache qui fonctionne plus ou moins pour m'appercevoir très vite ou j'ai pu me planter ou ce que j'ai raté. Et seulement ensuite je recode la chose proprement. Le prototype rapide permet d'ecrire des "hello world" de chaque partie et de voir si tout va bien ensemble.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par __caffeine__ . Évalué à 1.
1.5) on écrit les tests unitaires d'après ce qu'on sait du projet (diagramme UML/ Merise, gribouillage sur une nappe de pizzeria...)
Une fois que tes classes/modules passent les tests unitaires, tu arrêtes de les coder et tu passes à la suite. ça te donne un prototype plus rapidement, et tu optimise ensuite en étant sûr de rien casser d'existant.
Lisez le chapitre "Unit Testing" de http://www.diveintopython.org(...) , c'est très bien expliqué.
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par samds . Évalué à 3.
J'ai exactement le même problème dans mon école dont je tairais le nom. En plus d'avoir des connaissances plus qu'approximatives en informatique (certains cours sont fait par des profs de physique !?!), 99,9% de ces profs (j'en connais que deux qui ne présentent pas ce problème) ne savent se servir que d'une souris (comprendre y a windows ou y a rien) et en plus ils s'obstine a faire apprendre des trucs faux aux éleves. On notera deux cas particulièrement flagrants :
"- Alors, dans le protocole IP, les addresses sont de la forme : 32.68.740.236"
Non, il n'y a pas de faute de frappe ... Le pire c'est que si quelqu'un est pas la pour le faire remarquer, 99% des etudiants (tous ceux qui n'ont pas de vagues notion de réseau ou qui ont meme jamais fait un LAN) prenne ca pour une vérité absolue ...
Deuxième exemple, dans le cours d'info de niveau supérieur, à propos des regles de format pour printf :
printf("%8.2f", mon_float) va afficher 8 chiffres, dont un point et une décimale, alors que c'est 8 chiffres, puis un point, puis 2 décimales ...
Et après pendant le TP, le prof s'étonne que ca n'affiche pas ce qui est attendu ... Le pire dans tout ca c'est que si ca tombe en question au final écrit, ben tu sais pas quoi répondre ! D'instinct et par conviction profonde je mettrais la bonne réponse (6.2f) mais j'ai des risques que ca soit compté faux ! Et si je réponds selon sa théorie (8.2f) j'ai aussi des risques que ca soit faux si elle s'est souvenue dans sa mémoire alzeihmerisée qu'elle avait fait une boulette monumentale ...
Malheureusement les exemples de ce genre sont de moins en moins rares, et c'est aussi une des raisons pour lesquelles je veux pas terminer mon enseignement en France ...
Enfin bon, bon courage pour ton projet et prends ton mal en patience ...
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ephemere . Évalué à 1.
C'est vrai qu'elle est pas mal celle-là de la part d'un prof. J'ai même connu des profs qui ne répondaient pas aux questions, des profs qui ne venaient même plus en cours ...
Je pense que c'est comme partout, y'a de tout comme prof, du meilleur comme du pire.
- y'a les compétents et bon pédagogue,
- y'a les compétents et mauvais pédagogue,
- y'a les incompétents et mauvais pédagogues,
- est-ce qu'on peut avoir des incompétents et bon pédagogues ?
Alors que faire ? Sinon qu'à constater les dégâts. Parce que dès qu'on critique la forme, on se fait vivement rembarrer que c'est pas nous les profs et qu'on a juste le droit de critiquer le fond (c'est sûr que là, les profs se rentranchent derrière le programme de l'Éducation Nationale).
Évidemment, je vous dit pas la réaction si on ose critiquer les compétences ...
Ce qui semble inquiétant, c'est que le proportion de BONS profs ne semble pas vraiment s'arranger. Ceci dit, ce n'est que mon point de vue, on pourra toujours rétorquer que je n'ai pas de statistiques là-dessus, ce qui est bien vrai. Mais cela fait quelques temps dans les forum que l'on voit le malaise grandir.
Sinon, je pense aussi qu'il y a une différence entre découvrir un langage et faire un programme pour un client. Je ne veux pas lancer de troll, mais avoir une méthode en V pour commencer, c'est comme la méthode globale pour apprendre à lire (mais non, je n'en veux pas aux enseignants). Mais je ne pense pas que Cerel ait voulu vraiment dire qu'il faille commencer par là. Comme il le dit lui-même, c'est une *méthode* (donc largement indépendante du langage).
Certains profs n'aiment pas la remise en question (surtout par des plus jeunes, même pas par des pairs). Alors, t'es obligé de prendre sur toi et tu t'épanouiras plus tard ou sur d'autres programmes, je l'espère pour toi.
Bonne chance.
e.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par lerouxrv . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Black Fox . Évalué à 1.
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Yusei (Mastodon) . Évalué à 2.
Bien sûr qu'ils peuvent, comme n'importe quel être humain. Mais je vois deux cas:
- Les enseignants à qui on demande d'enseigner un domaine qui n'est pas le leur. Souvent le cas des chargés de TD, qui sont encore à moitié étudiants, et qui se retrouvent à enseigner des choses qu'ils connaissent parfois très mal. Ceux qui sont bons sont capables de se remettre en question, et il faut les voir plus comme un accompagnant que comme un oracle qui sait répondre à toutes les questions. Au pire, si ni toi ni lui ne sait répondre, il en réferera au maitre de conf pour la séance suivante.
- Les enseignants qui sont de bons chercheurs mais de très mauvais pédagogues. Ceux là, on ne devrait même pas leur permettre d'enseigner, mais il est souvent obligatoire de faire un certain nombre d'heures... S'ils sont ouverts d'esprit on peut aller discuter avec eux, sinon il faut faire avec en espérant qu'un jour les "enseignants-chercheurs" ne soient plus obligés d'enseigner s'ils n'en sont pas capables. Une chargée de TD nous disait récemment qu'il fallait voir le prof (calamiteux) comme un guide de référence, et aller piocher sur le net pour avoir un vrai cours :-)
Et bien sûr, il y a aussi de vrais cons, comme partout...
Concernant les méthodes de développement, moi je trouve pas mal qu'on tente (peut-être maladroitement) de vous faire programmer méthodiquement. Comme la plupart des gens, je fonctionne plus facilement par essai successifs, comme tu le décris, mais il faut avouer que sur un gros projet c'est absolument ingérable, et il est vraiment souhaitable de savoir modéliser correctement avant de se lancer dans le codage.
«Je voulais réaliser un truc et je voyais comment le faire en 30 lignes de C/Gtk»
Erf, en 30 lignes de C/GTK on ne peut pas faire grand chose d'autre qu'une fenêtre avec un bouton ;-)
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ephemere . Évalué à 1.
Ce système de pourvoie de poste est très regrettable et très dommageable. Là encore, quand on veut réformer (quelque soit le ministre) le système ...
Et bien sûr, il y a aussi de vrais cons, comme partout...
Ah hem ... le problème, c'est que la connerie est indépendante de l'intelligence (logique, booléenne, rationnelle) et qu'elle touche à tous les aspects du comportement social de l'humain. DONC quand on a un con en face de soi (et que c'est un prof) y'a pas non plus grand chose à faire.
Erf, en 30 lignes de C/GTK on ne peut pas faire grand chose d'autre qu'une fenêtre avec un bouton ;-)
D'accord, mais l'important est d'acquérir les bons réflexes pour pouvoir se concentrer sur les méthodes, l'architecture, la conception. Les méthodes c'est bien mais c'est comme le code, faut y aller petit à petit. Et on s'attaque à des programmes de plus en plus gros.
e.
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Ashar Voultoiz . Évalué à 2.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ephemere . Évalué à 1.
Fait pas comme la vague (ça aussi c'est pas quantifiable) de jeunes qui se sont engagés dans le professorat juste pour le fonctionnariat comme on rentre à EDF ou à la SNCF. Mais bon, dans le privé, tes moyens d'actions seront limités pour la grêve : tu ne pourras pas couper le courant, arrêter les trains ou obliger les gens à prendre des jours de congés pour garder leurs enfants ...
C'est vrai qu'un diplôme c'est encore bien important pour rentrer dans une boîte. Mais après, ça l'est un peu moins. Le fait que tu t'intéresses à ce que tu fais et que tu cherches à améliorer les choses, c'est déjà un bon point.
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par ephemere . Évalué à 1.
http://www.mozart-oz.org/documentation/tutorial/node3.html#typehier(...)
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Snark_Boojum . Évalué à 0.
1) une histoire très courte, qui fait que l'on manque complètement de recul par rapport à la discipline ; à côté de disciplines qui ont bénéficié de siècles et de siècles de discussions sur les problématiques et les méthodes d'attaque, forcément ça fait une différence!
2) une forte implantation industrielle, qui fait que la fontière entre monde académique et monde économique est très poreuse. Comme par ailleurs ça rapporte moins d'un côté que de l'autre, les seuls à rester du "mauvais" côté sont les gens motivés et ... les mauvais!
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par Snark_Boojum . Évalué à 1.
[^] # Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par thaodalf . Évalué à 1.
"payé un très petit peu au dessus du smic, avec un statut précaire sans réel contrat"
un prof qui est maitre de conférence touche pas mal de sous quand même il me semble, le status precaire faut que tu m'explique là car ils sont fonctionnaire avec tous les avantages que cela implique et surtout tous les abus dont ils sont capablent/coupablent.
pis être prof c'est aussi un métier à vocation !
# Re: Et si ce qu'on apprenait ne marchait pas ?
Posté par fmaz fmaz . Évalué à 1.
À la fac, la grosse majorité des enseignants sont enseignants-chercheurs. Si certaines commissions de spécialistes avaient un peu les pieds sur terre, elles n'oublieraient pas qu'elles recrutent des personnes qui vont devoir enseigner et ce dans plusieurs matières. Normalement, un chercheur est quelqu'un qui apprend toute sa vie et qui est adaptable.
L'informatique n'est certainement pas assez vaste pour qu'un maître de conférences ne puisse pas maîtriser l'ensemble des domaines dans lesquels il va pouvoir enseigner jusqu'en licence/maitrise. La charge horaire d'un maître de conférences est de 192 heures d'équivalents TD. Ce qui corresponds (en se basant sur 32 semaiens de cours) à 6 heures de TD, à 4 heures de cours et à 9 heures de TP par semaines. Je veux bien que la recherche prenne du temps et que préparer un cours from scratch soit très lourd mais ne me faites pas croire qu'en 35 heures par semaines, on ne peut pas faire un cours potable.
Frédéric
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.