Grmbl Gorgonite, gasche l'avait lancé sur une solution simple et inefficace, tu aurais pu le laisser au moins finir ça ! (Parce que malgré le fait que ce soit simple, il était loin d'y arriver...)
Bref :)
Version imprimable
Grmbl Gorgonite, gasche l'avait lancé sur une solution simple et inefficace, tu aurais pu le laisser au moins finir ça ! (Parce que malgré le fait que ce soit simple, il était loin d'y arriver...)
Bref :)
Citation:
Envoyé par TropMDR
mouais, mais ça semblait tiré par les cheveux... et presque protentiellement trop foncteur pour un forum OCaml
Disons qu'il me semble que l'idée de base était "tu sais calculer fibo(n) pour tout n, commençons par utiliser ça pour calculer la liste de tous les fibo. Après on verra pourquoi c'est une idée de merde, et ce qu'on peut faire de mieux" !
Le risque alors, c'est qu'on ait le scénario suivant:Citation:
Envoyé par TropMDR
- Hé ça marche maintenant ! Merci ! [Résolu]
- Hé mais revient, ce que je voulais te montrer, c'est l'exemple qu'il ne faut SURTOUT PAS faire !
Par ailleurs, quand on répond sur le forum, il ne faut pas seulement penser à la personne que l'on essaye d'aider mais (beaucoup plus important) également à tous les paresseux qui vont just taper leur question sur Google, ne vont pas s'embêter à tout lire, et copier-coller sans se poser de question une mauvaise implémentation (et par "paresseux", je veux dire "les ingénieurs consultants de demain qui font des choses sans les comprendre").
Dans ce sens, je pense qu'il vaut mieux aller à l'essentiel en mettant les gens directement sur la bonne voie en leur disant "voilà l'idée, implémente-moi ça".
Et par "bonne" voie, j'entends que si en plus ça pouvait être récursif terminal, ça serait pas mal... ;)
Indépendamment de la question de "tout dire ou aider à chercher" qui a été déjà débattue, mes idées en "ayant d'abord un truc simple mais mauvais qui marche" étaient les suivantes :
- on ne leur demande pas forcément quelque chose d'efficace
- l'important quand on débute c'est d'apprendre à coder correctement; si on arrive à pousser le débutant à obtenir d'abord une première solution correcte, puis ensuite une deuxième solution correcte et efficace, on lui a plus appris et il code mieux à la fin
- de toute façon, les problèmes pratique qui se posent sont des questions d'apprentissage du langage et pas d'une solution ou une autre : quand quelqu'un écrit [fibo (n-1)]::foo, on sait qu'il y a un problème qu'on corrige localement, sans forcément penser à la solution dans son ensemble. Je pense qu'il est aussi bien de corriger les erreurs/incompréhensions qu'on voit que les oublier en forçant à changer d'approche.
Ceci dit je comprend aussi la position des gens qui préfèrent parler de "la bonne" solution directement. Enfin bref je pense que tout le monde aide d'une façon ou d'une autre, et après c'est aux gens qui posent les questions de faire le choix du genre d'aide qu'ils veulent recevoir.
+1 avec tout ce qui a été dit précédement, sachant qu'un consultant en info fainéant qui cherche via google ne code pas du tout en OCaml :aie:, mais bon, la solution telle que présentée au premier abord par gasche me semblait dériver potentiellement sur une vision très élégante à la Haskell, mais moins idiomatique à la OCaml (ça reste un ressenti, j'ai peut-être une vision déformée ;))
C'est vrai, on ne peut pas forcer les gens à apprendre. Mais on peut quand même essayer :)Citation:
Envoyé par pcaboche
Euh, on est d'accord que tu es en train de me convaincre que je devrais toujours mettre une mauvaise réponse en tête de thread pour punir ces mecs là nan ? Si c'est ça leur approche de la résolution de problème et de l'informatique, tant pis pour eux ! Il ne faut pas compter sur moi pour leur mâcher le travail, gratuitement qui plus est.Citation:
Envoyé par pcaboche
Je tiens en plus à souligner que même dans le monde professionnel, il y a un gros avantage à écrire une fonction trivialement correcte, même si elle est lente: cela permet de tester la version efficace en comparant les sorties.
Citation:
Envoyé par TropMDR
:mouarf: comme si l'on perdait du temps à faire des tests en milieu professionnel... nan mais les tests sont inutiles puisqu'on paie des prestataires au lance-pierres pour reprendre le code de nos anciens stagiaires :aie:
sérieux du vécu en entretiens d'embauche pour un poste en R&D: "Mais pourquoi avoir perdu de temps à faire une thèse en analyse statique alors qu'on a une armée de prestataires pour pondre les tests avant la qualification du projet ? "
pire un directeur R&D qui m'affirme haut et fort que Polyspace est un outil d'analyse dynamique (équivalent à des test quoi ^^) et que l'analyse statique est une chose triviale faite par des outils comme QAC ou Lint :roll:
On va dire que ça dépend des boites ;) Dans mes entretiens d'embauche, on m'a demandé comment écrire des tests et de justifier la correction de mon code :)Citation:
Envoyé par gorgonite
C'est exactement le fond de ma pensée...Citation:
Envoyé par gorgonite
Comme de toute façon il y a des gens qui ne savent faire que de la copie/colle, autant éviter qu'ils copient trop de conneries pour ensuite dire "j'ai trouvé ça sur DVP". :aie:
Je pense qu'il voulait dire qu'il faut une fonction Fibonacci avec juste le bon nombre de paramètres (1) qui appelle une fonction récursive avec d'autres paramètres "de travail" pour construire la liste.Citation:
Envoyé par gorgonite
La manière Haskell (enfin "une" manière Haskell), c'est : "Je définis un fonction qui me retourne la suite de Fibonacci... en tant que liste infinie ! Puis je prends juste les n premiers éléments de cette liste et grâce au comportement "paresseux" d'Haskell, ça ne me retourne pas plus d'éléments qu'il n'en faut. (bref ça marche, et en plus c'est vachement élégant)"
Je pense que la vision haskell dont il parlait c'était map fibo [0..n] :)Citation:
Envoyé par pcaboche
non je pensais plus au morphisme à passer directement au foncteur pour obtenir naturellement la liste remplie :aie:Citation:
Envoyé par pcaboche
Au contraire, il faut éviter qu'ils copient trop de conneries pour ensuite dire "j'ai trouvé ça sur DVP". :aie:Citation:
Envoyé par TropMDR
C'est souvent ce qui vient en premier à l'esprit : "ce type est incompétent, je vais le pousser à la faute". Mais après reflexion, on se dit : "pas besoin, un jour où l'autre il va forcément se tirer tout seul une balle dans le pied. Ce jour là, j'ai juste besoin d'amener une caméra pour immortaliser le moment". (là, c'est l' "exterminateur d'incompétents" qui parle :aie:)
Au contraire : le truc à la mode chez les consultants, c'est la "qualité". Et d'après ces mêmes consultants pour faire plus de qualité, il faut faire juste faire plus de tests (:whistle:).Citation:
Envoyé par gorgonite
Parrallèlement, on continue d'être évalué (et payé) sur la base de données mesurables. Donc on fait un maximum de tests (quantité mesurable, le patron est content) sans JAMAIS se poser la question de leur pertinence. :mrgreen:
Bon, on va formuler ça autrement alors : je n'en ai rien à carrer des mecs incompétents qui vienne récupérer du code tout fait sans vouloir passer une minute à lire les explications autour. Je ne vais pas tenter de les piéger, mais je ne vais pas non plus essayer de les aider ! Mon but (sauf quand je trolle, ce qui peut parfois aussi arriver :-D) est d'avoir des posts de bonne qualité technique, et d'aider à comprendre comment on arrive à une bonne solution, souvent en partant d'une mauvaise (c'est entre autre pour ça que j'ai rappelé quelles sont les étapes de base pour l'écriture d'une bonne fonction récursive). Toujours ces bonnes vieilles histoires de poissons et d'apprendre à pêcher !Citation:
Envoyé par pcaboche
Je pense que le processus pédagogique :
- laisser la personne avoir une idée, même "mauvaise", l'aider à l'implémenter
- expliquer (ou mieux, aider la personne à comprendre) pourquoi l'idée n'est pas la bonne
- montrer (ou mieux, aider la personne à trouver) une meilleur voie
aider la personne à l'implémenter
me semble bien plus intéressant que "le code est blah", et pour eux, et pour nous ! (je ne trouve pas super valorisant de montrer que je suis capable d'écrire un code trivial :-\ En revanche, expliquer à un débutant est un vrai challenge !)
Je comprends parfaitement ton point de vue sur le processus d'apprentissage.
Cependant ce que j'ai souvent remarqué, c'est que le cerveau humain a une tendance à se souvenir plus facilement des premiers exemples rencontrés (pas toujours les meilleurs), avec parfois le risque d'élever ces exemples au rang de "règles" (avec par la suite la difficulté de "désapprendre").
Beaucoup de gens sont assez à l'aise avec l'apprentissage "par l'exemple". Dans ce cas, il vaut mieux commencer en présentant des exemples pas trop mauvais pour ensuite essayer de généraliser, discuter de la qualité de la solution proposée et déterminer si on peut mieux faire (surtout qu'en l'occurrence, même dans le cas de "bons" exemples, il y a beaucoup à dire).
Enfin bon, c'est un point de vue (et c'est pour cela que je préférais l'approche de gorgonite).
EDIT:
Dans certains cas en revanche, il peut être plus intéressant de commencer par les mauvaises solutions. Par exemple, pour discuter de certaines solutions exposées sur internet :
- "Face à tel problème, de nombreux sites conseillent la solution suivante..."
- "Cependant voici ce que cela implique..."
- "Certaines personnes recommandent plutôt cette solution..."
- "C'est mieux, mais on est alors confronté à tel problème..."
- "Pour ma part, je recommenderais telle solution..."
- "En gardant à l'esprit que cela n'est applicable que dans tels cas... et souffre des limitations suivante..."
Dans ce cas, le but c'est de dire au lecteur "ok, t'as cherché telle solution dans Google, t'es certainement tombé sur tels résultats, je vais te faire gagner du temps en te montrant certains problèmes que tu peux difficilement soupçonner de prime abord, et (si je peux) je vais essayer de te donner une solution alternative".
Mais bon, dans ce cas, le but reste d'aller à l'essentiel (en montrant dès le départ ce qui ne va pas).
Tiens, quand on parle du loup... Vendredi j'ai rencontré quelqu'un qui essayait de me dire que les tests automatisés c'est bien, que ça l'avait beaucoup aidé dans l'un de ses projets, et que maintenant ils ne pouvait plus s'en passer.Citation:
Envoyé par pcaboche
Je lui ai répondu que les tests automatisés, c'est vrai que c'est bien; mais dès l'instant qu'on doit avoir une intervention extérieure (ex: intervention humaine pour une interface), ça devient tout de suite beaucoup plus difficile à "automatiser" justement.
Réponse de l'intéressé : "ah ben nous ça va, notre projet ne fait que du calcul, il n'y a pas d'intervention humaine".
Voilà le cas typique du consultant qui a vu une solution qui marche et qui essaye de transposer cette solution à n'importe quel type de problème comme si c'était la panacée. Un peu comme si on essayait de soigner un cancer avec de l'aspirine, quoi...
Les "évangélistes de la secte du test automatique (même là où c'est pas applicable)" sont de plus en plus nombreux. On peut les voir un peu partout en entreprise, même lors des entretiens d'embauche. Ca ne présume en rien de la qualité des logiciels produits, bien au contraire.
Bref, quand quelqu'un me parle d'automatiser les test, je me demande souvent :
- s'il comprend ce que cela implique
- s'il sait de quoi il parle
- s'il sait réfléchir au cas-par-cas, en allant au fond des choses, ou s'il applique bêtement des principes vu ailleurs
- s'il n'essaye pas juste de paraître intéressant en utilisant des termes à la mode ("buzzwords")
Je sais, c'est pas bien de généraliser, mais chez moi ce sont les consultants qui font l'objet de tests automatisés. :mrgreen: (et c'est pas souvent que les résultats ressortent tous verts :aie:)
Mais le pire, c'est quand votre patron vous demande : "quelles solutions envisages-tu pour améliorer la qualité du logiciel ?", là on se dit "aïe... Je crois bien qu'il a rencontré un de ces évangélistes qui l'a convaincu. Je crois qu'il attends une réponse pré-formatée, mais totalement inapplicable à mon projet. Je crois que je suis dans la m****". :aie:
Tant qu'on travaille sur un projet uniquement logiciel, dans l'absolu il n'y a pas de limite au test automatisé. Après les analyses statiques, c'est la méthode de détection des erreurs la plus efficace. Il est donc logique de chercher à faire un maximum de tests automatiques.
Tu cites les interfaces graphiques, mais à priori il devrait être possible de tester automatiquement un logiciel comportant une interface graphique. Soit en passant par une couche inférieure (par exemple en envoyant directement les entrées à la couche de contrôle), soit en utilisant de la reconnaissance d'image (ça permet de tester aussi le rendu, mais c'est moins sémantique donc plus fragile) comme par exemple dans le projet Sikuli. Pour le web par exemple il y a aussi Selenium (j'ai jamais essayé).
Le test n'est plus forcément automatisable de façon transparente quand il met en œuvre des composants matériels (contrôle d'une machine-outil ou autres) ou quand on ne sait pas évaluer automatiquement les résultats du test. Dans les deux cas on peut travailler sur l'automatisation : apporter une interface logicielle approximant le comportement de la pièce matérielle pour tester les autres composants, et se forcer à préciser les critères de réussite.
Je ne comprends donc pas trop ta tirade contre les tests automatiques.
c'est moi ou ça dévie ?
Ce n'est pas contre les tests automatiques (je n'ai rien contre, bien au contraire !), mais contre les consultants qui croient apporter une solution (toujours la même, d'ailleurs) mais ne comprennent rien au problème.Citation:
Envoyé par gasche
Les tests c'est bien, mais ce n'est pas suffisant. D'abord il faut une bonne conception, du code propre, éviter les copier-coller (ça multiplie les branchements et donc les cas à tester), détecter un maximum d'erreurs à la compilation plutôt qu'à l'exécution (donc dans les tests), ce genre de choses...
Et non, je ne cite pas les interfaces "graphiques" (dis moi où j'ai cité ce mot ?) mais tout type d'interface. Ca peut très bien être, par exemple, une machine sur laquelle il faut appuyer sur un bouton.
Et de manière plus générale (pas uniquement l'exemple des interfaces, graphiques ou non) je veux parler de "tout système sur lequel on ne peut pas avoir un contrôle direct" (exemple: un logiciel tiers qui est supposé interagir avec le système à tester).
Qu'on cherche à automatiser un maximum de choses, d'accord. Mais dans pas mal de cas, le maximum est très vite atteint à cause de certaines contraintes qui échappent au contrôle automatique (parce que dans le cas trivial où on a un le contrôle sur TOUT, oui, c'est facile d'automatiser les tests :roll:).
Je crois qu'au départ, on était parti sur une histoire de suite de Fibonacci en OCaml... :fou: Donc oui, ça dévie... :aie:Citation:
Envoyé par gorgonite
Alors évidement, on n'a pas toutes l'histoire, mais dans ce que tu racontes, ce n'est pas un intégriste. Il dit que pour son projet, les tests automatiques sont super adaptés, que ça lui a changé la vie, et qu'il ne pourrait plus s'en passer sur ce projet. Je ne vois pas où est l'intégrisme là... Et puis même sur un projet avec une "interface", si il est vaguement intéressant, tu as quand même quelques algos en interne qui peuvent bénéficier de tests automatiques (rien qu'un algo de tri, ou je ne sais quoi).Citation:
Envoyé par pcaboche
C'est toi qui fait un peu le sectaire en disant que sous prétexte que des gens tentent de pousser trop loin l'utilisation de tests automatique, ça montre que les tests automatique c'est mal... Calmons nous quand même !Citation:
Les "évangélistes de la secte du test automatique (même là où c'est pas applicable)" sont de plus en plus nombreux. On peut les voir un peu partout en entreprise, même lors des entretiens d'embauche. Ca ne présume en rien de la qualité des logiciels produits, bien au contraire.
Moi tout ce que je disais, pour revenir très vaguement au sujet original, c'est qu'avoir une solution triviale (et trivialement correct), même si elle est trop lente pour être exploitable en prod, peut être très utile pour les tests, et que donc même pédagogiquement, ce n'est pas une mauvaise chose du tout de laisser un débutant suivre le chemin "solution triviale -> problème ? -> meilleur solution".
Et puis bon, ça permet aussi de se faire embaucher dans des bonnes boites d'info en fait :) A tous mes entretiens techniques, j'ai systématiquement commencé par donner une solution triviale, puis par expliquer immédiatement pourquoi elle ne conviendrait pas, avant de passer à une "bonne version", puis de conclure qu'on pouvait utilise la première version pour tester la nouvelle (qui était typiquement vââchement moins évidement correcte...). Bon bah ça m'a plutôt bien réussi.
Ensuite pour revenir à
Il faut quand même se souvenir qu'une grosse partie des questions croisé sur ce sous forum sont en fait des exercices proposés en cours. Donc le prof a déjà présenté des exemples, etc. Et là il demande au élève d'appliquer ça à un autre énoncé. Alors puisque je comprends que certains élèves aient besoin de plus d'explications, aient plus de difficulté, que j'admets que certain profs sont moins bons que d'autres, etc, je veux bien répondre aux questions. En revanche, je pense que c'est deservir l'élève mais aussi saboter le travail du prof que de donner la réponse, et ça, je refuse de le faire :)Citation:
Beaucoup de gens sont assez à l'aise avec l'apprentissage "par l'exemple". Dans ce cas, il vaut mieux commencer en présentant des exemples pas trop mauvais pour ensuite essayer de généraliser, discuter de la qualité de la solution proposée et déterminer si on peut mieux faire (surtout qu'en l'occurrence, même dans le cas de "bons" exemples, il y a beaucoup à dire).