Journal De l'enseignement de la programmation en classe préparatoire

Posté par Manger sur pattes le 24 mars 2012 à 00:19. Licence CC By‑SA.

Étiquettes :

mar.

2012

Le monde court un grave danger. Il y a quelques décennies, avec l'arrivée de l'outil informatique, la programmation a pu se développer. Grâce à elle, n'importe quel esprit capable d'exprimer clairement ses idées et de les structurer peut arriver à de grands résultats avec bien moins d'efforts que dans tous les autres domaines. En dessin : dessine un joli mouton ; si tu en veux un second il faudra redessiner le même en espérant avoir le même coup de crayon. Le cerveau peut s'habituer au bout d'un certain temps et on peut commencer à dessiner facilement et rapidement de jolis moutons, mais ça reste plutôt lent. En programmation : on a fait notre fonction, on n'a pas à la refaire chaque fois qu'on veut s'en servir. La programmation, c'est vraiment cool. Malheureusement, c'est aussi dangereux. Un tel domaine peut attirer beaucoup trop de monde, délaissant ainsi les autres secteurs. Afin d'éviter de ne former plus que des ingénieurs en informatique et de ne plus avoir personne quand il s'agit de construire un pont, une décision doit être prise.

C'est ainsi que naquit l'épreuve d'algorithmie d'une certaine école d'ingénieur. Les classes préparatoires doivent alors former leurs élèves - déjà assez chargés - à la programmation, ce qui devrait déjà les empêcher de trop s'attacher à ce domaine. Mais, cela n'est pas assez. Ils risqueraient de trouver cela intéressant malgré tout et finalement découvrir et approfondir ce domaine, ce qui serait contre-productif. Il faut donc choisir un langage de programmation approprié. Pas question d'utiliser un BASIC qui serait beaucoup trop simple à enseigner ou à comprendre et qui permettrait en plus de faire des choses sympathiques avec les fonctions graphiques. Enseigner le brainfuck ou l'assembleur ? Ce serait pousser le bouchon un peu trop loin ; les gens devineraient un peu trop facilement qu'on essaie de les dégoûter. Java ou C++ ? Trop à apprendre, on ne veut pas que les élèves passent trop de temps dessus non plus. C ? Il y a de l'idée, mais ça reste un assez lourd pour des débutants.

Une solution est finalement trouvée : utiliser un logiciel qui n'est absolument pas prévu pour la programmation comme outil de programmation : le logiciel de calcul formel Maple. Bien qu'un excellent outil de calcul formel, quand utilisé pour la programmation il réussit l'exploit d'allier la lenteur d'un langage interprété non optimisé (facteur 500 par rapport au C pour un crible d'Ératosthène dans mon souvenir) et une certaine complexité qui sort un peu de nulle part. Quelques exemples :

Ajouter un élément à une liste ? L := [op(L), nouvel_element];. Parce qu'une fonction comme Add(L, nouvel_element) ou éventuellement L.Add(nouvel_element) si on va jusqu'à faire un peu d'objet, voire L[size(L)+1] = nouvel_element, ce serait beaucoup trop simple.
Les listes sont limitées à 100 éléments. Au-delà, il faut utiliser des Array, qui ont une taille définie à la création et qui ne se laissent pas facilement redimensionner (dans les versions
L'interface est celle d'un outil de calcul formel. Un peu comme un shell, sauf qu'on peut éditer les commandes déjà entrées et les réexécuter. On entre tout son code sous la forme d'une séquence d'instruction sur plusieurs lignes, sans la moindre notion de coloration syntaxique ou d'indentation (encore que, dans les dernières versions, il y a des progrès de ce point de vue), et on appuie sur entrée en priant. Malheureusement, il est possible de faire des fonctions, il faut donc faire attention à ce qu'une telle possibilité ne facilite pas trop la vie aux étudiants. Nota bene : penser à utiliser les anciennes versions qui affichent tout le code dans un rouge criard qui pique les yeux
Pas d'outil d'exécution pas à pas pour débugger ou de choses du genre. Et puis quoi encore ? Un peu de printf-debugging, ça forge le caractère !
Pas de possibilité d'entrée utilisateur : il ne faut surtout pas que les étudiants réalisent qu'on peut interagir avec la machine et donc faire des programmes plus amusants qu'un tri en N^2.

Une fois cette première étape passée, les futurs ingénieurs devraient avoir une vision assez négative de tout ce qui touche à la programmation, tout en leur donnant quelques notions quand même au cas où. Mission accomplie.

--- Fin de l'ironie

Je vous l'accorde, il y a exagération sur certains points (pas besoin de gérer les entrées quand on fait de l'algorithmie pure). Par ailleurs, certains sujets sont intéressants : anti-aliasing sur une ligne (même si là c'est plus trouve-la-formule-sort-le-code que de l'algorithmie), simulation d'incendie de forêts avec un petit modèle), mais il reste que l'outil utilisé est incroyablement inapproprié pour ce genre de tâches. Le seul avantage est l'ensemble des fonctions de plottage, mais c'est pas comme s'il était impossible d'écrire une fonction capable de tracer un plot à partir d'un tableau et de filer le fichier à tout le monde. Enfin bref, n'importe quel langage ferait mieux l'affaire, que ce soit l'antique QBasic de Microsoft, Python… Les langages fortement typés sont biens quand on veut être sûr de ce qu'on fait (c'est un peu le but quand on code aussi), mais pour un premier contact avec la programmation, c'est peut-être un peu rude quand on veut juste voir un peu la logique générale variable-instructions.
Après, on peut comprendre cette décision, si on tient compte du fait que pour d'autres épreuves, Maple est utilisé en tant que logiciel de calcul formel : vu que de toute façons, Maple est utilisé, autant s'en servir aussi pour l'algorithmie, même si c'est pas fait pour.

Il doit aussi y avoir plein de confusions entre algorithmie et programmation dans le texte ci-dessus ; d'une manière générale, à moins d'avoir de fantastiques capacités d'abstraction, il vaut mieux savoir programmer avant de faire de l'algorithmie ; pour pouvoir profiter au mieux des algorithmes qu'on compose, il faut que le langage de programmation qu'on utilise soit agréable à employer, donc ça revient plus ou moins à la même problématique pour un débutant total.

Maple n'est pas un logiciel libre et, par ailleurs, la version étudiante coûte un paquet (150€) ; dans ce journal je tenais plus à me focaliser sur le côté inapproprié de l'outil que sur le fait qu'on forme les gens à un outil non libre, chose qui a déjà été maintes fois débattue. À côté de ça, les alternatives libres qui peuvent aider à former les gens à la programmation sont nombreuses : Python si on se restreint un peu, Gambas a des possibilités intéressantes mais je ne sais pas s'il est très pédagogique, Smallbasic (http://smallbasic.sourceforge.net/)….

# Julia

Posté par needs le 24 mars 2012 à 01:24. Évalué à 7.
A noter le langage de programmation Julia (github, Julia_(langage_de_programmation)) qui bien qu'un peu jeune semble être plutôt adapté aux calculs scientifique. Et plutôt simple de prise en main, voici pour les flemmards un exemple tiré de la page d'accueil :
```
function mandel(z)
    c = z
    maxiter = 80
    for n = 1:maxiter
        if abs(z) > 2
            return n-1
        end
        z = z^2 + c
    end
    return maxiter
end

function randmatstat(t)
    n = 5
    v = zeros(t)
    w = zeros(t)
    for i = 1:t
        a = randn(n,n)
        b = randn(n,n)
        c = randn(n,n)
        d = randn(n,n)
        P = [a b c d]
        Q = [a b; c d]
        v[i] = trace((P.'*P)^4)
        w[i] = trace((Q.'*Q)^4)
    end
    std(v)/mean(v), std(w)/mean(w)
end
```
- [^] # Re: Julia
  
  Posté par barmic le 24 mars 2012 à 06:42. Évalué à -1.
  
  Le prof d'algo qui explique qu'il fait mettre un return dans un for et plusieurs return par fonction, il manque beaucoup de crédibilité… :-)
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Julia
    
    Posté par drakmaniso le 24 mars 2012 à 09:07. Évalué à 10.
    
    Ça, ça fait partie des mythes de l'ingénierie logicielle.
    
    S'il est vrai qu'on peut facilement en abuser, il y a de nombreux cas où insérer un return supplémentaire simplifie beaucoup la lecture d'un algo, notamment en évitant des niveaux supplémentaires d'imbrication.
    
    L'exemple ci-dessus n'en fait pas partie, puisque que l'on peut supprimer le return sans ajouter de niveau supplémentaire. Toutefois il me semble que cela colle mieux à la définition mathématique de l'ensemble de Mandelbrot.
    
    Avoir des fonctions courtes et simple à lire est bien plus crucial que le nombre de return qu'elles contiennent (et bien sûr, pour cela aussi il y a des exceptions).
    - [^] # Re: Julia
      
      Posté par Graveen le 24 mars 2012 à 11:38. Évalué à 10.
      
      J'allais le dire, on frise la branlette intellectuelle, le poncif d'un autre âge, au moins aussi pertinent que 'accolades: avant ou aprés le nom de la fonction ?' ou 'indentation: tabulation ou espaces ?'… le genre de croisade qui finit toujours mal, un peu comme lorsqu'on parle d'Apple.
      
      Dès l'instant où ça a un effet bénéfique, en particulier la lisibilité donc compréhension donc maintenabilité OU - soyons fou - l'optimisation (si, si, y'a des gens qui choisissent VOLONTAIREMENT la performance sur la maintenabilité), il n'y a pas de raisons de se contraindre à ces règles discutables.
      
      Elles n'ont de sens que lorsqu'elles répondent à une problématique, bien sûr que les good practices ou les design patterns sont fortement structurants, mais ça doit être avant tout des règles de bon sens, rabachées aux étudiants le temps qu'ils gagnent une expérience qui les aurait naturellement amené à utiliser lesdites règles.
      
      Non ?
      - [^] # Re: Julia
        
        Posté par drakmaniso le 24 mars 2012 à 12:03. Évalué à 5.
        
        Il est clair qu'il y a une grande confusion entre "c'est comme ça qu'il faut faire", et "faire comme cela peut apporter tel avantage".
        
        Par exemple pour cette histoire de return, il est évident qu'il y a plein de situations où il est plus clair de n'avoir qu'un point de retour en fin de fonction. Il est important qu'un nouveau programmeur apprenne cela, mais aussi de ne pas en faire une règle à suivre.
        
        En fait, je crois que l'élément le plus sous-estimé de l'apprentissage de la programmation, c'est la lecture de code. AMHA Il n'y a rien de plus enrichissant et de plus formateur que de lire (et comprendre ^ ^) du code bien écrit.
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 12:11. Évalué à 4.
        
        je te rejoins sur l'importance de la lecture du code. En fait, dès qu'un projet commence à atteindre une taille respectable, un développeur passe plus de temps à lire du code qu'à en écrire. Malheureusement, dans la vrai vie, on passe plus souvent du temps à lire du code mal écrit que du code bien écrit … Cela dit, pour peu d'avoir un oeil critique, c'est formateur aussi.
        
        hop, tous là bas !
        ps: pour ceux qui ne veulent que du sérieux, je recommande la section Alex's Soapbox
    - [^] # Re: Julia
      
      Posté par barmic le 24 mars 2012 à 14:48. Évalué à 2.
      
      Avoir des fonctions courtes et simple à lire est bien plus crucial que le nombre de return qu'elles contiennent (et bien sûr, pour cela aussi il y a des exceptions).
      
      Avoir des return un peu partout ça t'empêche de faire du log par exemple, si tu veut faire évoluer ton code et ajouter un traitement supplémentaire avant le retour de la fonction tu te retrouve.
      
      Les seuls cas où ça peut être intéressant c'est les préconditions testées en début de fonction (si tel paramètre vaut ceci return -1).
      
      Ensuite, les break je préfère éviter de les utiliser dans des boucles pour regrouper les conditions de sorties au même endroit dans un boucle ce qui la rend plus lisible (on comprend mieux l'invariant quand on a sous les yeux toutes les conditions de sorties).
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Julia
        
        Posté par gUI (Mastodon) le 24 mars 2012 à 16:20. Évalué à 3.
        
        Pour résoudre le log, il y a toujours la possiblité du "goto". Dans ta boucle, tu fais un "goto end" et t'as un label "end" qui assure la sortie.
        Oui, le goto reste noble, il n'y a qu'à voir le nombre de goto qu'il y a dans le kernel Linux (qui, rappelons-le, contient du code relu avant d'être accepté) pour comprendre qu'on peut aussi fort bien utiliser le goto.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Julia
        
        Posté par barmic le 24 mars 2012 à 17:34. Évalué à 2.
        
        Je n'ai pas dis le contraire, j'ai parlé du return et uniquement du return pas du break ou du goto.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par gUI (Mastodon) le 25 mars 2012 à 12:25. Évalué à 2.
        
        Je n'ai pas dit que t'avais dit le contraire ! J'ajoute simplement au débat "ça c'est interdit", et à une époque, bcp de monde disait également que le goto était crasseux.
        
        Mais bon, dans tout les cas, rien ne vaut un commentaire explicite ;)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Julia
        
        Posté par calandoa le 26 mars 2012 à 22:54. Évalué à 4.
        
        Les gotos c'est le mal! Les vrais programmeurs sérieux de devraient jamais les utiliser, exactement pour la même raison qu'un vrai ouvrier sérieux ne devrait jamais utiliser de marteau : l'année dernière, on a recensé 4739 ouvriers qui se sont blessés au doigt avec un marteau, pour 12 avec un manche de tournevis ; logiquement, il faut donc planter des clous avec des manches de tournevis si on ne veut pas se blesser (et mettre des booléens partout dans ses boucles si on veut faire disparaitre les bugs).
        
        Merci à tous les profs d'informatique pour nous permettre d'avoir tous les ans les même débats passionnants avec nos collègues butés.
        
        [^] # Re: Julia
        
        Posté par barmic le 27 mars 2012 à 00:18. Évalué à 5.
        
        Merci à tous les profs d'informatique pour nous permettre d'avoir tous les ans les même débats passionnants avec nos collègues butés.
        
        Être buté pas besoin des prof pour l'être. Tu n'a jamais entendu parler de, au hasard, Linus Torvald ou de Theo De Raadt pour voir des gens buttés ? Au contraire j'ai l'impression qu'une bonne partie des plus réputés sont les plus obtus. Il y a des exceptions comme John Carmack, mais j'ai vraiment l'impression que c'est l'exception plutôt que la règle.
        
        Tu pourra me dire que c'est la faute de leur prof, mais à ce moment là tu peut tout leur mettre sur le dos.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Julia
        
        Posté par Guillaume Knispel le 24 mars 2012 à 17:24. Évalué à 7.
        
        Si tu peux virer des returns sans aucun effet de bord néfaste, alors va-z-y. Si ça t'oblige à introduire par exemple le moindre booléen supplémentaire, alors les virer et souvent désastreux et augmente la complexité au lieu de la diminuer.
        
        [^] # Re: Julia
        
        Posté par barmic le 24 mars 2012 à 17:52. Évalué à 4. Dernière modification le 24 mars 2012 à 17:55.
        
        Je ne vois pas de quel augmentation de complexité tu parle. Tu introduit de manière quasiment systématique une variable qui contient le résultat qui est initialisé à une valeur non pertinente et quand tu l'initialise tu fait un break ou un goto derrière. Éventuellement s'il n'existe pas de valeur non pertinente tu crée un booléen, mais je ne vois pas en quoi ça ajoute une complexité dramatique.
        
        Mais bon c'est comme la langue, tu as le droit de faire une faute si tu sais pourquoi tu l'a fait. Quand tu introduit des return à plusieurs endroit, il faut garder à l'esprit que la libération de la mémoire, l'ajout de log ou l'ajout d'un traitement supplémentaire peuvent devenir pénible, mais c'est ton choix.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par windu.2b le 24 mars 2012 à 20:41. Évalué à 2.
        
        Mais bon c'est comme la langue, tu as le droit de faire une faute si tu sais pourquoi tu l'as faite. Quand tu introduits des return
        
        :-p
        
        [^] # Re: Julia
        
        Posté par VictorAche le 24 mars 2012 à 22:45. Évalué à -1.
        
        Je pensais plutôt à "si tu sais pourquoi tu la fais", parce qu'en général les gens écrivent les choses comme ça se prononce.
        
        "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 24 mars 2012 à 23:26. Évalué à 7.
        
        Je parle des gens qui bien souvent érigent ce genre de "règle" ou de pratique en dogme sans savoir pourquoi, et/ou en font l'apologie sans préciser le contexte. Un peu comme les adeptes de "goto considered harmful" qui n'ont même pas lu le papier, oublient le contexte dans lequel il a été écrit, et s'en servent pourtant pour justifier une haine irrationnelle des gotos.
        
        Pas de goto et un seul return ne devraient pas être une règle dans 99,99999999% des environnements de programmation. Ne pas mettre de goto et mettre un seul return va rendre CERTAINS codes plus simples et plus complexes. Dès lors l'ériger en règle ou bonne pratique ou que sais-je est crétin si on ne garantie pas par avance que le contexte est tel que cette "bonne pratique" va produire des effets positifs et jamais de négatifs (ou uniquement un nombre très faible de négatifs).
        
        Il n'y a même pas besoin de chercher très loin pour trouver des exemples avec lesquels un seul return produit un code plus complexe que plusieurs:
        
        def search(lst): for elem in lst: if match(elem): return elem return None
        
        (note : omettre le second pour profiter du return None implicite de python ne le ferait pas pour autant disparaître sémantiquement)
        
        Quant au goto il est extrêmement pratique pour la libération de ressources sur erreur en C, ou pour certains algorithmes un peu pointus.
        
        Et il n'y a pas à parler de besoin de trace ou que sais-je avant d'en avoir vraiment besoin.
        
        En outre, quand c'est dans un standard de codage, cela dénonce parfois une approche culturelle du développement par l'encadrement rigide de gens peu compétents et le code résultant à beau satisfaire toutes les règles magiques en question, c'est de la merde en boite pour d'autres raisons. Le cargo cult programming n'a jamais produit de bons résultats…
        
        Pour avoir une illustration d'un contexte où pas de goto et un seul return aurait des effets délétère et serait complètement crétin, lire un noyau de système d'exploitation généraliste. Ou pour un effet encore plus rigolo envoyer des patch pour supprimer des goto de Linux en les remplaçant par des choses plus complexes et admirer comment on se fait accueillir :p
        
        [^] # Re: Julia
        
        Posté par barmic le 25 mars 2012 à 00:53. Évalué à -1.
        
        Il n'y a même pas besoin de chercher très loin pour trouver des exemples avec lesquels un seul return produit un code plus complexe que plusieurs:
        
        def search(lst): for elem in lst: if match(elem): return elem return None
        
        Un code de 5 lignes n'a jamais voulu rien dire. On peut faire dire à peut près n'importe quoi à un code de 3 à 5 lignes. De plus je l'ai déjà dis les règles/conseils/bonnes pratiques/coutumes sont faites pour être violées en connaissance de cause.
        
        Quant au goto il est extrêmement pratique pour la libération de ressources sur erreur en C, ou pour certains algorithmes un peu pointus.
        
        Oui en C. Ça n'en fait pas une règle générale. Il faut vraiment s'en servir avec parcimonie, jamais (du moins je n'ai jamais vu de cas où ça ne deviendrait pas de la merde) avec un label hors de la fonction, avec précision. Grosso modo il y a quelque patern où le goto est utile, 2 où il est indispensable (libération des ressources traitement des erreurs) et quelques exceptions. Les langages objets On sortis c'est deux motifs pour qu'ils aient une sémantique plus précise. Faire fit de ce que le langage te propose pour cela c'est avoir choisi un langage inadapté.
        
        Et il n'y a pas à parler de besoin de trace ou que sais-je avant d'en avoir vraiment besoin.
        
        Oui sauf que le coût et le risque d'erreur lié à la mise en place de ces patern après coup rend, montre que le logiciel perd beaucoup en maintenabilité. Des logs c'est quasiment systématique d'avoir à en produire, si ton utilisateur rencontre un problème il est bien de pouvoir voir les conditions de l'erreur sans avoir à tenter de reproduire le bug difficilement chez toi (en fait ça simplifie de beaucoup la reproductibilité). Tu peut t'en sortir avec de l'AOP, mais là il faut :
        
        ajouter un nouveau langage/paradigme à ton projet
        
        faire très attention à ne pas rendre ton code totalement imbitable
        
        En outre, quand c'est dans un standard de codage, cela dénonce parfois une approche culturelle du développement par l'encadrement rigide de gens peu compétents et le code résultant à beau satisfaire toutes les règles magiques en question, c'est de la merde en boite pour d'autres raisons. Le cargo cult programming n'a jamais produit de bons résultats…
        
        C'est dommage tu avais bien commencé en donnant des exemples et tout et tu finis sur des jugements à l'emporte pièce sur des valeurs. C'est à partir de là que j'ai arrêter de lire ton commentaire, il ne peut rien sortir de bon face à ce genre d'arguments.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par Sylvain Sauvage le 25 mars 2012 à 17:09. Évalué à 7.
        
        Un code de 5 lignes n'a jamais voulu rien dire.
        
        C’est marrant parce que la fonction mandel que tu fustigeais plus haut est construite sur le même modèle que la fonction search. Si elle fait un peu plus de lignes, c’est parce qu’il y a des end et deux variables…
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 20 avril 2012 à 05:30. Évalué à 2.
        
        un label hors de la fonction ne serait pas du C
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 20 avril 2012 à 05:31. Évalué à 2.
        
        (et tu as oublié de lire le mot "parfois")
        
        [^] # Re: Julia
        
        Posté par 2PetitsVerres le 25 mars 2012 à 05:05. Évalué à 5.
        
        De toute façon dans tous les cas un goto peut être avantageusement remplacé par un longjmp, qui est quand même bien plus drôle.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
  - [^] # Re: Julia
    
    Posté par PachaFonk le 24 mars 2012 à 10:22. Évalué à 3.
    
    On m'a aussi expliqué à l'école que les goto, c'est le mal !
    
    Après l'école, il y a la vrai vie, où on s'aperçoit que le plus important pour du logiciel, c'est qu'il soit maintenable et lisible !
    - [^] # Re: Julia
      
      Posté par pamputt le 24 mars 2012 à 11:20. Évalué à 4. Dernière modification le 24 mars 2012 à 12:02.
      
      Après l'école, il y a la vrai vie, où on s'aperçoit que le plus important pour du logiciel, c'est qu'il soit maintenable et lisible !
      
      Et donc on se rend compte que ce qu'on nous avait appris à l'école n'était pas si faux : il ne faut pas utiliser de goto.
      - [^] # Re: Julia
        
        Posté par nazcafan le 24 mars 2012 à 11:36. Évalué à 4.
        
        Si tu fais du C, utiliser un goto peut parfois aider a la lisibilité. Le mot clé n'a pas été mis dans le langage pour des prunes. Il faut juste l'utiliser à bon escient (lire : avec parcimonie dans le cas de goto)
      - [^] # Re: Julia
        
        Posté par inico (site web personnel) le 24 mars 2012 à 11:39. Évalué à 4.
        
        Sauf si tu code de la gestion d'erreur où la notion de label peut aider à ne pas oublier d'étape.
        
        On retente un débat sur l'utilité du goto ?
        
        [^] # Re: Julia
        
        Posté par Batchyx le 24 mars 2012 à 13:55. Évalué à 1.
        
        Quand tu fait de la gestion d'erreur, tu utilise des exceptions. Ce n'est que lorsque ton langage ne le supporte pas que tu peut légitimement placer un goto.
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 14:21. Évalué à 4.
        
        tu sembles avoir une position dogmatique sur le sujet. Tu peux légitimement placer un goto n'importe quand si tu estimes que c'est légitime, quelque soit les moyens fournis par le langage. Les exceptions sont une façon de gérer les erreurs parmi d'autres, mais pas une nécessité.
        
        Un exemple que je trouve parlant, dans le guide de Google pour le C++, c'est laconique mais c'est tranché: "Nous n'utilisons pas les exceptions C++"
        
        [^] # Re: Julia
        
        Posté par Batchyx le 24 mars 2012 à 16:46. Évalué à 8.
        
        C'est peut-être une position dogmatique, mais quand on à des fonctionnalités dans un langage, c'est pour qu'on s'en serve.
        
        En C++, justement, la méthode standard pour gérer le cleanup, exceptions ou pas, erreur ou pas, c'est de le faire dans un destructeur d'une classe instanciée dans la pile. Tu peux ensuite utiliser les exceptions ou les return sans risquer le moindre leak ou autre chose, puisque tes destructeurs seront forcement appelés avant de sortir de ta fonction. Et des classes qui font du cleanup dans leur déstructeurs, la bibliothèque standard en est remplie (et au pire, il y a boost).
        
        Le guide de google pour le C++, en plus d'être décrié par beaucoup de programmeurs C++, ne banni pas les exceptions parce que les goto sont mieux, mais parce si tu code en C++ comme tu code en C, comme c'est trop souvent le cas, les exceptions peuvent faire péter tout ton code en zappant les cleanups faits à l'ancienne. C'est encore plus vrai si tu mélange du code C++ et du C, et c'est sans doute pour cette raison que c'est banni chez google. Mais ça ne changera pas le fait que les exceptions fassent partie du langage et que tu ne peux pas faire grand chose si tu veut être sûr de ne pas lever d'exceptions.
        
        Placer un goto légitime dans du code C++ est bien plus compliqué que dans du code C.
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 24 mars 2012 à 17:25. Évalué à 2.
        
        Faire n'importe quoi en C++ est bien plus compliqué qu'en C.
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 18:22. Évalué à 8.
        
        j'aimerais tellement que ça soit vrai …
        Malheureusement, pour devoir régulièrement intervenir sur du code produit à quelques dizaines de milliers de kilomètres d'ici, je peux dire que le langage C++ en tant que tel permet tout à fait de faire autant n'importe quoi qu'en C.
        
        [^] # Re: Julia
        
        Posté par patrick_g (site web personnel) le 24 mars 2012 à 19:22. Évalué à 7.
        
        Je crois que Guillaume voulait dire "faire quoi que ce soit en C++ est bien plus compliqué qu'en C".
        
        [^] # Re: Julia
        
        Posté par Batchyx le 24 mars 2012 à 22:05. Évalué à 3.
        
        Peut-être, mais pendant ce temps là, moi j'écris des programmes en C++ qui sont lisibles et qui marchent. Et avec le temps que je gagne, je peux corriger des cleanups dans le noyau Linux.
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 25 mars 2012 à 00:22. Évalué à 2.
        
        Et moi j'ai arrêté d'en débugger qui étaient illisibles et ne fonctionnaient pas (ex : OpenH323), depuis j'ai moins mal à la tête et avec le temps que je gagne en ne le faisant plus je peux concevoir des ordinateurs.
        
        Le C++ est un langage pour les experts. Ça ne poserait pas de problèmes si seuls les experts s'en servaient. (OpenH323 et d'autres prouvent clairement le contraire.)
        
        [^] # Re: Julia
        
        Posté par Batchyx le 25 mars 2012 à 15:44. Évalué à 3.
        
        Tu devrai essayer le code source d'ISC BIND, pour voir. C'est apparemment le même genre de code que OpenH323, sauf que c'est du C.
        
        [^] # Re: Julia
        
        Posté par cedric le 24 mars 2012 à 23:33. Évalué à 2.
        
        Et vu le nombre de fonctionnalite du langage C++, ils peuvent meme faire pire qu'en C ! Perso, je recommande de ne pas utiliser le C++, pour tout projet ou intervienne des prestataires en trop grand nombre et dont on ne peut pas garantir la presence continu durant toute la duree de vie du projet. Dans le meilleur des cas, un projet de C++ industriel ressemble a du C. Dans le pire des cas, tu vas devoir te payer un psy pour survivre au construction hazardeuse et les approximations de pattern design qu'ils ont utilise…
        Le C++, il te faut des gens vraiment tres doue pour avoir quelque chose qui survive au temps… J'ai encore jamais rencontre de projet proprietaire correct en C++ (je dis meme pas bien ou genial, juste correct…). Ca rend triste…
        
        [^] # Re: Julia
        
        Posté par Faya le 25 mars 2012 à 07:19. Évalué à 2.
        
        Et moi je me suis toujours demandé comment on pouvait être aussi sûr qu'un code n'est "pas correct". Je n'y connais pas grand chose hein … je code en PHP, c'est vous dire ! Mais si ça se trouve c'est ta manière de voir le code qui n'est pas correcte ? Ils savent peut-être pourquoi ceci a été codé comme cela ?
        
        [^] # Re: Julia
        
        Posté par daimrod le 25 mars 2012 à 10:27. Évalué à 8.
        
        Facile, si ça ressemble à du PHP ce n'est pas correct.
        
        [^] # Re: Julia
        
        Posté par GuieA_7 (site web personnel) le 25 mars 2012 à 14:32. Évalué à 5.
        
        Et moi je me suis toujours demandé comment on pouvait être aussi sûr qu'un code n'est "pas correct".
        
        Autant il est difficile de dire qu'un code est correct, autant il est bien souvent facile de montrer qu'un code ne l'est pas. Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant, c'est que le vieux code n'était pas bien fameux.
        
        [^] # Re: Julia
        
        Posté par barmic le 25 mars 2012 à 15:58. Évalué à 1.
        
        Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant,
        
        C'est un « ou » ou un « et » ? Parce que :
        
        si c'est un « et », C'est rare d'avoir un choix si manichéen
        
        si c'est un « ou », ça dépend fortement des choix du projet. Tu as fréquemment un choix à faire entre lisible et performant par exemple.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 25 mars 2012 à 16:21. Évalué à 4.
        
        c'est l'approche KISS (Keep It Simple Stupid), et ça peut aller ensemble. Un code plus simple est plus lisible, plus robuste et souvent plus performant. Pour moi, l'enjeu principal du développement est d'arriver à du code simple pour traiter des problèmes complexes. Vu de loin, on pourrait croire qu'il y a plus d'effort intellectuel pour écrire du code complexe alors que c'est plutôt le contraire.
        
        [^] # Re: Julia
        
        Posté par barmic le 25 mars 2012 à 17:23. Évalué à 3.
        
        C'est un objectif, mais il n'est pas toujours réalisable IRL. Que ce soit un problème de compétence, de problématique autre.
        
        Tu le dis toi même « ça peut aller ensemble ». Ce n'est pas une vérité générale.
        
        Mais tu as raison c'est un objectif qu'il ne faut pas perdre de vue. Personnellement, il faut que j'écrive une première version correct, puis je reprend mon code le lendemain (ou un peu plus tard pour reprendre le code) et là j'arrive à une solution nettement plus KISS.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 25 mars 2012 à 17:49. Évalué à 2.
        
        tout pareil. La première version, c'est un peu l'obligation de résultat. Il faut avoir une base qui démontre qu'on peut répondre au problème et qui pose les grandes lignes de ce qu'on fait. Une fois qu'on a cette version, j'ai presque envie de dire que c'est là que le travail commence vraiment (factorisation, simplification, robustesse, résistance à la charge, …)
        
        [^] # Re: Julia
        
        Posté par GuieA_7 (site web personnel) le 26 mars 2012 à 13:35. Évalué à 3.
        
        C'est un « ou » ou un « et » ?
        
        Je parlais bien d'un « et ». On va dire qu'effectivement on ne peut pas toujours améliorer à la fois tous les critères que j'énumère, mais 2 ou 3 sans dégrader les autres est très souvent possible. Je travaille beaucoup avec des (talentueux) juniors, mais bien souvent ils se contentent de faire du code qui marche (ce qui est déjà bien) ; j'essaie de relire systématiquement leur code, et je les surprends souvent en améliorant tous (ou du moins la plupart) de ces critères. Et leur code est bien meilleur que ce que j'ai pu voir écrit par le mec lambda en SSII, ce qui doit représenter une grosse partie du code écrit dans le monde. Je n'ai évidemment pas la prétention d'en faire de même dans le kernel, mais l'informaticien de gestion de base n'est pas Linus Torvalds malheureusement…
        
        [^] # Re: Julia
        
        Posté par cedric le 28 mars 2012 à 17:56. Évalué à 3.
        
        Quand je parle de code bien pourri, c'est qu'on peut facilement avoir du code plus simple, plus lisible, plus robuste et plus performant que ce que j'ai l'horreur de decouvrir en general. Je parle pas d'une solution super optimal, mais juste d'un code blinde de bug et de probleme de stabilite, impossible a relire sans y passer des jours, fait de rustine… Le graal du logiciel propriétaire !
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 18:15. Évalué à 2.
        
        en relisant ton premier commentaire, je l'avais sur interprété. Je pensais que tu disqualifiais tous les usages éventuels de goto, alors qu'en fait tu restreignais à la problématique de gestion d'erreur.
        
        C'est ta dernière phrase impliquant qu'il pouvait y avoir des usages légitimes au goto en C++ qui m'a mis la puce à l'oreille. Je retire donc (symboliquement) mon commentaire précédent.
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 24 mars 2012 à 23:31. Évalué à 3.
        
        que tu ne peux pas faire grand chose si tu veut être sûr de ne pas lever d'exceptions.
        
        Chez Google ils font pas grand chose du C++ ? Hm peut être, mais j'ai un doute.
        
        Placer un goto légitime dans du code C++ est bien plus compliqué que dans du code C.
        
        D'un autre côté tu viens de donner un exemple légitime au dessus (code C/C++).
        
        En fin de compte vous êtes d'accord (et moi aussi) ; il ne s'agit pas de savoir si goto >? exception, mais de dire que les deux ont leur légitimité, et que la programmation dogmatique c'est le mal.
        
        [^] # Re: Julia
        
        Posté par Batchyx le 25 mars 2012 à 12:36. Évalué à 8.
        
        Chez Google ils font pas grand chose du C++ ? Hm peut être, mais j'ai un doute.
        
        En C++, un simple "new" peut lever une exception lorsqu'il n'y à plus de mémoire. Est ce que google utilise new ? Apparemment oui. Est ce qu'il attrape l'exception std::bad_alloc ? D'après le guide de google, non tu doit pas le faire, mais plutôt bidouiller ton new pour qu'il lance pas d'exception. Moi j'appelle ça lutter contre le langage.
        
        D'un autre côté tu viens de donner un exemple légitime au dessus (code C/C++).
        
        Je vois pas le rapport. Si tu fait du C tu peux avoir envie d'utiliser des goto. Si tu fait du C++, tu fait du cleanup automatique (plus connu sous le nom de RAII). Si tu doit faire du C++ qui s'interface avec du code C, tu sais que si tu ne wrappe pas les ressources C dans des classes avec des destructeurs, ça sera super emmerdant dès que tu voudra les mettre dans un conteneur standard du style std::vector/list/set, parce qu'ils sont prévus pour des objets avec des destructeurs. Et si tu ne le fait pas, tu ferai mieux de faire ta fonction en C et de la mettre dans la partie écrite en C.
        
        En fin de compte vous êtes d'accord (et moi aussi) ; il ne s'agit pas de savoir si goto >? exception, mais de dire que les deux ont leur légitimité, et que la programmation dogmatique c'est le mal.
        
        Non. À Rome il faut faire comme les romains. Si ton langage gère les erreurs avec des exceptions de partout et/ou du RAII, gérer des erreurs avec goto c'est le mal.
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 20 avril 2012 à 05:24. Évalué à 2.
        
        Non. À Rome il faut faire comme les romains. Si ton langage gère les erreurs avec des exceptions de partout et/ou du RAII, gérer des erreurs avec goto c'est le mal.
        
        C'est une position dogmatique. Si tu peux faire ça tant mieux. Si quelque chose t'en empêche (et il y a 1000000 raisons pour que quelque chose puisse légitimement t'en empêcher) démerde toi pour faire autrement. Si dans l'affaire tu arrives au niveau de Google, tant mieux.
        
        [^] # Re: Julia
        
        Posté par Batchyx le 20 avril 2012 à 21:21. Évalué à 3.
        
        C'est pas dogmatique du tout : Si tu gère des erreur avec des goto en C++, le langage va te rendre ta vie misérable. new balance des exceptions, tout les conteneurs du langage balancent des exceptions, toutes les opérations sur les streams, sur les pointeurs intelligents, et j'en oublient balancent des exceptions. Sans indication explicite, n'importe quel code à le droit de balancer des exceptions. Avec indication explicite, tu te privera de toutes les fonctionnalités citée précédemment, ainsi que de toutes les autres fonctions/méthodes/bibliothèques qui ne s'amusent pas à en mettre partout.
        En C++, tu ne peux pas faire de goto en avant si tu défini de nouvelles variables entre temps. si en C ça ne pose aucun problème, en C++, toutes les classes n'ont pas forcement de constructeurs par défaut, et ça n'a souvent aucun sens d'en ajouter. Pour contourner le problème, il faudrai soit tout allouer dynamiquement avec new (tu sais, celui qui lance des exceptions et qui leake avec des pointeurs nus), soit introduire à l'arrache des constructeurs par défaut, enfin bref, rajouter des états et des bugs.
        
        Si il y a 1000000 raisons pour laquelle tu peux pas utiliser d'exceptions ou de RAII, il y a 100000000000000000 raisons pour laquelle tu ne peux pas t'en passer. Tu peux toujours passer outre, mais après tu arrivera au niveau de Google et Microsoft qui en sont à inventer leur propre langages plutôt que d'utiliser C++ tel qu'il à été conçu.
        
        [^] # Re: Julia
        
        Posté par Guillaume Knispel le 24 avril 2012 à 01:39. Évalué à 2.
        
        Si tu peux ne faire que du C++ tout ce que tu dis tiens la route et le C++ est depuis longtemps largement construit et pratiqué autour de ces principes (entre autre, pour les autres pratiques cf Google again, et comme tu le fais remarquer cf MS aussi, sur une plateforme qui n'est ni négligeable ni techniquement moisie). C++ est probablement un des meilleurs langages pour travailler totalement comme cela (a vrai dire je serais incapable d'en citer un autre).
        
        Un des problèmes c'est quand tu cherches à utiliser de l'existant, que cela soit du C, du vieux C++ pas fait comme ça, ou du C++ récent pas fait comme ça, voire même encore autre chose que du C ou du C++). Au mieux tu va wrapper le truc. Si c'est assez petit ça sera à la fois faisable et propre. Si c'est trop gros et/ou un peu tordu ça sera faisable en codant des bordels au cas par cas à chaque fois que tu as besoin d'une gestion d'erreur précise, bordels qui risqueront d'être moins facile à suivre qu'un simple goto de cleanup bien placé (une indirection en plus dans le cas nominal, au lieu d'un path bien définit pour la gestion d'erreur).
        
        La négation de l'existant en large quantité et incompatible avec une démarche, j'appelle aussi ça du dogmatisme. Mais entendons nous bien : si toi, personnellement tu n'as jamais à toucher à ce genre d'existant et que tu apprécies et profites de la manière de faire en RAII, tant mieux !
        
        [^] # Re: Julia
        
        Posté par Batchyx le 25 avril 2012 à 22:10. Évalué à 2.
        
        Un des problèmes c'est quand tu cherches à utiliser de l'existant, que cela soit du C, du vieux C++ pas fait comme ça, ou du C++ récent pas fait comme ça, voire même encore autre chose que du C ou du C++)
        
        En même temps, quoi qu'on en dise, je n'ai jamais vu de compatibilité entre langages indépendants qui ne soit pas une grosse blague. Ce n'est pas parce que C et C++ peuvent linker entre eux qu'ils sont compatibles pour autant. Si j'ai de l'existant en Ruby et en Java, je vais pas m'amuser à interfacer mon C++ avec un interpréteur Ruby et une JVM. Je vais plutôt les faire tourner chacun dans leur coin et ils communiqueront avec les autres avec des méthodes standard (sockets, IPC …) que je devrai implémenter en utilisant les paradigmes de chaque langage. C'est pareil avec les bibliothèques C qui sont remplies de callbacks dans tout les sens, c'est pas la peine d'essayer de forcer pour qu'elles rentre dans du C++, tu fait juste du C pour que ça communique avec de manière propre. Pour le C++ qui se fiche des exceptions, si c'est assumé et "bien fait", que les options de compilations sont bien réglées en upstream et que ça gère bien les erreurs quand même, tu le met dans un processus à part. Si ça n'est pas assumé, c'est juste du code buggé, à considérer en tant que tel. Tu peux choisir de l'utiliser, ou pas.
        
        Pour le reste, genre POSIX (enfin, pas tout), oui c'est assez léger pour qu'il y ai des ribambelles de bibliothèque C++ bien foutues pour wrapper ça, avec un support pour plusieurs systèmes d'exploitations.
        
        [^] # Re: Julia
        
        Posté par barmic le 24 mars 2012 à 17:52. Évalué à 2.
        
        C'est de rétorquer une affirmation dogmatique à une autre jugée dogmatique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 18:18. Évalué à 2.
        
        est-ce que tu peux élaborer ton commentaire ?
        Je crois percevoir qu'il a une teneur critique, mais je ne te connais pas assez pour l'interpréter correctement.
        
        [^] # Re: Julia
        
        Posté par barmic le 25 mars 2012 à 00:57. Évalué à 2.
        
        Wow ! Je suis vraiment fatigué aujourd'hui, il manque des mots à mon commentaire précédent.
        
        Reformuler ça donne :
        
        C'est surprenant de dénoncer le dogmatisme d'une affirmation, par une autre toute aussi dogmatique.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 25 mars 2012 à 11:27. Évalué à 2.
        
        ok. Il y a plusieurs phrases dans mon commentaire en question, du coup, je ne sais pas trop laquelle tu visais. J'imagine que ça concernait la position de google ?
        
        Si c'est bien le cas, je me souviens d'avoir lu quelque chose de plus détaillé chez eux il y a quelques mois (est-ce que c'était une version antérieure ou à un autre endroit de leur guide, je ne sais plus) ou ils listaient les cas dans lesquels il était acceptable de gérer des exceptions.
        
        Hop, je viens de trouver, il faut cliquoter sur le triangle à coté de "nous n'utilisons pas les exceptions du C++". Il y a tout un tas de pour/contre, et la conclusion contient:
        
        Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch.
      - [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 11:43. Évalué à 5.
        
        Et donc on se rend compte que ce qu'on nous avait appris à l'école n'était pas si faux : il ne faut pas utiliser de goto.
        
        ah la la, les développeurs du noyau, c'est vraiment des gros mauvais, ils truffent leur code de goto.
        Et dans mon école, la seule méthodologie de développement enseignée à l'époque : le cycle en V. Du coup bien sûr, j'évite soigneusement toutes les trucs à Gilles et les machins itératifs.
        </sarcasme>
        
        Après quelques années d'expérience, j'en suis arrivé à la conclusion que les principes et règles que j'appliquais devaient toujours être évalués en fonction du contexte. Parfois, violer une règle se justifie (tant que cette violation ne nuit pas la lisibilité/maintenabilité). Le goto mal utilisé est un moyen très simple de produire du code spaghetti de la pire espèce, mais ce n'est pas une fatalité.
        
        [^] # Re: Julia
        
        Posté par Graveen le 24 mars 2012 à 11:50. Évalué à 1.
        
        cf mon commentaire plus haut: tu es trop timide :D j'enlèverais même la partie "(tant que cette violation ne nuit pas la lisibilité/maintenabilité)" qui est hautement subjective.
        
        Quand je code un virus de fou pour Linux, je VEUX que mon code soit difficile d'accès :) :)
        
        [^] # Re: Julia
        
        Posté par gaaaaaAab le 24 mars 2012 à 12:00. Évalué à 2.
        
        je reformule: "tant que cette règle ne nuit pas trop à la lisibilité/maintenabilité)
        
        et là, effectivement, l'évaluation du "trop" est subjective, mais il y a des métriques pour évaluer un peu la lisibilité/maintenabilité. Je te renvoie à Code Complete (Tout sur le code en français) de Steve McConnell si ça ne fait pas partie de tes lectures. Pour moi, un must read absolu pour tout développeur.
        
        je préfère ne pas répondre à ton autre commentaire, il y a un petit appeau à troll sur la position des accolades contre lequel mes défenses sont assez fragiles :D
        
        [^] # Re: Julia
        
        Posté par BAud (site web personnel) le 24 mars 2012 à 12:06. Évalué à 3.
        
        le cycle en V. Du coup bien sûr, j'évite soigneusement toutes les trucs à Gilles
        
        si tu veux une anti-sèche, il y a http://faq.tuxfamily.org/MethodoProject/Fr qui en recense quelques-une dans plusieurs domaines :)
    - [^] # Re: Julia
      
      Posté par Michaël (site web personnel) le 20 avril 2012 à 06:46. Évalué à 2.
      
      Après l'école, il y a la vrai vie, où on s'aperçoit que le plus important pour du logiciel, c'est qu'il soit maintenable et lisible !
      
      Dans la vrai vie, le plus important c'est qu'il tourne! Ce que tu dis arrive en seconde position.
# ma vie à moi

Posté par Oook le 24 mars 2012 à 02:22. Évalué à 4.

franchement, maple… comment dégouter les jeunes de la programmation…

l'algo, pour moi au concours c'était du (turbo)pascal… on a fait un puissance 4…

Franchement, tout le monde s'est pris au jeu et même les filles (60% de la promo) on eu l'air d’apprécier.
je ne comprend pas ce tropisme de l'enseignement sup' vers l'imbitable, alors qu'il y a tant de chose passionnante et relativement simple à faire qui font appel aux mêmes notions
- [^] # Re: ma vie à moi
  
  Posté par Bobyl le 24 mars 2012 à 06:25. Évalué à 4.
  
  Ma vie de prof de physique en prépa:
  
  En plus, faut voir les exercices que nous pondent nos collègues de maths pour les TD info (genre fabrication du polynôme à partir des conditions sur ses racines…).
  
  Pour la physique, Maple est utile pour son côté "laissons le physicien faire de la vraie physique et Maple faire les calculs bourrins". Je l'utilise pour préparer les devoirs (histoire de pas perdre de temps dans les calculs) et également pour mes animations de cours (pour illustrer la décomposition en série de Fourier, les différentes trajectoires du tir balistique avec/sans frottements, avec/sans gravitation uniforme), et c'est franchement assez puissant. Je reconnais que j'aurais peut-être pu faire la même chose en java (que Maple utilise) ou un autre langage orienté objet, mais c'est ce que j'avais sous la main…
  
  Disons que Maple est utilisé, à tord, comme un langage de programmation alors que c'est "juste" un excellent langage de calcul formel.
  - [^] # Re: ma vie à moi
    
    Posté par Manger sur pattes le 24 mars 2012 à 11:21. Évalué à 2.
    
    Oui ; pour des problèmes de mathématiques ou de physique, utiliser Maple est beaucoup plus rentable que de passer par un autre langage de programmation en réinventant la route au moins une bonne dizaine de fois pour avoir les fonctions dont on a besoin. Après, certains exercices peuvent mêler un peu d'algorithmie et des notions mathématiques (polynômes, fonctions) auxquelles Maple donne facilement accès ; dans ce cas, utiliser Maple pour de la programmation est plus pratique.
    
    Par contre, pour de petits algorithmes ne faisant pas intervenir d'objets mathématiques nécessitant un logiciel de calcul formel, commencer par Maple c'est pas forcément génial, mais c'est vrai que les étudiants n'ont pas le temps d'apprendre deux langages de programmations, aussi simple soient-ils. Il faut voir si apprendre un langage très simplifié puis apprendre à programmer avec Maple prend moins de temps que lancer les gens directement dans Maple quitte à ce que le choc soit un peu plus fort. Avec 3h de TD d'info par semaine (ou toutes les deux semaines, je ne me souviens plus), c'est vrai que la seconde option semble plus efficace.
  - [^] # Re: ma vie à moi
    
    Posté par Graveen le 24 mars 2012 à 11:46. Évalué à 2.
    
    Merci pour ce témoignage.
    
    Il y a quinze ans, j'aurais dit que cela était relatif à la formation des enseignants.
    
    Quelque part, les choses ont dûes évoluer, mais enseigner un produit pour lequel il faut s'investir sur la base de l'intérêt personnel et du volontariat, c'est pour le moins 'aléatoire' (en terme d'efficacité globale).
    - [^] # Re: ma vie à moi
      
      Posté par beleys (site web personnel) le 24 mars 2012 à 16:59. Évalué à 1.
      
      Oui et non, il n'y a toujours pas de CAPES/Agreg d'info et donc, tous les cours d'informatique au lycée sont de fait, réaliser par des personnes sans formation en informatique.
      
      Il parait que c'est annoncé mais à quoi bon, l'informatique, tout le monde en fait … pourquoi avec des formations pour l'enseigner ^{^}
# Nawak

Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 mars 2012 à 07:28. Évalué à 9.

C'est inexact. Maple est uniquement utilisé dans les cours d'info des classes qui se sont éloignées de ce domaine, les PC par exemple. Dans les classes les plus proches de ce domaine, par exemple MP option info par exemple, c'est de la programmation fonctionnelle en Caml, qu'on fait. Et c'est vraiment idéal pour apprendre les notions de programmation à mon avis.
- [^] # Re: Nawak
  
  Posté par Manger sur pattes le 24 mars 2012 à 11:30. Évalué à 1.
  
  En effet ; j'ai fait une PC (bien qu'ayant eu un professeur qui savait donner goût à la physique, je ne suis pas sûr que suivre cette filière ait été le meilleur choix compte tenu de mes goûts), et je n'ai donc vu en prépa que Maple. Je ne sais pas ce qu'il en est des MP option SI ; à ce que j'ai lu ils ont aussi le droit à Maple, auquel cas cela voudrait dire que la majorité des prépas scientifiques ne fait que du Maple. Mais c'est vrai qu'il y a de petits chanceux comme vous ;-)
  
  En revanche, à l'épreuve d'algorithmie, on a le choix du langage de programmation, donc on peut se ruer sur le langage qui paraît le plus approprié à la tâche demandée, même si seul Maple est vu en classe.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 24 mars 2012 à 11:53. Évalué à 2.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Nawak
    
    Posté par daimrod le 24 mars 2012 à 13:32. Évalué à 4.
    Les programmes d'enseignements sont bien souvent tentés de trop se focaliser sur un seul langage.
    
    Ça dépend totalement de la formation, et encore, j'ai fait un DUT et je suis actuellement à la fac et bien je trouve qu'on voit un paquet de langages.
    - IUT → Ada, C, Java, ASM x86, PHP, Javascript
    - Fac → C, C++, Java, python, Prolog, OCaml, ISETL, ASM MIPS
    Bien sur, avec un langage comme Common Lisp on a quasiment tout ça d'un seul coup et d'avantage mais bon, ça serait trop simple.
    
    Ah, et on n'oublie pas tous les trucs géniaux comme l'UML, Merise, Méthode en V, …
- [^] # Re: Nawak
  
  Posté par Gabbro le 24 mars 2012 à 12:26. Évalué à 2.
  
  Malheureusement, même en MP, c'est du m'importe quoi : la version de Caml utilisé est Caml light, qui n'est plus développée depuis 2002 (avec tout ce que cela implique : non présent dans les dépots Debian et ne s'installant pas correctement, pas de version pour Windows 7…) et qui n'est même pas compatible OCaml !
  Le truc qui n'est utilisé qu'en prépa en somme…
- [^] # Re: Nawak
  
  Posté par Snark le 24 mars 2012 à 13:22. Évalué à 3.
  
  Caml, j'ai détesté quand j'étais en prépa. Après, j'ai compris l'utilité d'une part pour moi-même, d'autre part pour de purs débutants en programmation (et il y en a…).
  
  Je suis prof de maths en PC ; je traîne mes élèves en maple pour l'info, je déteste ça pour diverses raisons :
  - c'est lourd ;
  - le parseur est trop gentil, du coup on peut taper n'importe quoi pendant un moment, et d'un seul coup on a une erreur, qui remonte à on ne sait quand ;
  - les messages d'erreur ne sont pas d'une clarté phénoménale ;
  - en plus ce n'est pas libre.
  
  Par contre, je ne suis pas d'accord pour dire qu'il n'y a pas d'outil pour déverminer : on peut lancer "trace" sur une fonction pour en étudier le fonctionnement. Je m'en sers rarement, mais c'est là. En général, je sais où sont les erreurs rien qu'en regardant l'indentation (et s'il n'y a pas d'indentation, je fais indenter et parfois l'élève voit tout seul que son code ne tient pas la route).
  
  Ah, si on avait un langage un peu strict et si en plus on pouvait l'utiliser aussi en maths… j'en ai marre des divisions par les vecteurs!
- [^] # Re: Nawak
  
  Posté par Guillaume Knispel le 24 mars 2012 à 17:36. Évalué à 3.
  
  Oui alors ta définition des classes "éloignées" de l'info elle est osée quand même.
  
  Déjà MP option info c'est quand même assez spécifique.
  
  Ensuite dans mes souvenirs de PT on faisait toutes les matières, certaines en zappant des trucs par rapport à PC/MP, d'autres en ajoutant des trucs.
  
  Donc zapper quasiment toute la programmation (parce que programmer en Mapple, j'ai beau chercher, j'arrive pas trop à concevoir qu'on peut faire quelque chose qui irait au delà de l'équivalent de ce qui devrait être d'un niveau collège en programmation) en PC ou PT ou MP si pas d'option info, en 2012 (sous réserve que le seul endroit ou on fait vraiment de la programmation aujourd'hui soit MP option info), pour des futurs ingénieurs, c'est quand même complètement n'importe quoi. Ça l'était déjà en 2002 (et même avant), dix ans après ça serait quand même bien que les responsables des programmes se sortent les doigts pour arrêter de nuire aussi gravement à la compétitivité .fr
# Quand on n'a qu'un marteau comme outil...

Posté par Croconux le 24 mars 2012 à 09:40. Évalué à 3.

Je partage ton ressenti sur Maple. A mon avis, il faut regarder qui enseigne l'informatique en prépa. Je n'y ai jamais vu de prof d'informatique. Les cours d'info étaient dispensés par des profs de math et parfois de physique. Forcément, ils utilisent les outils auxquels ils sont habitués. Si on avait demandé à un prof d'économie, il aurait probablement utilisé Excel…

Ce qui manque, c'est une véritable approche de la discipline avec un programme conçu par des gens de ce domaine. On ne demandera pas à un prof d'informatique de concevoir le programme des cours de math. Alors pourquoi fait-on le contraire ? Comme si l'informatique était une sous-discipline et que tout utilisateur de PC devenait du coup à même de donner des cours. Le fait de savoir se servir d'une calculatrice de fait pas de moi un prof de math que je sache.
# Il n'y a pas d'uniformité

Posté par Lomig E le 24 mars 2012 à 10:59. Évalué à 2.

Je suis un petit peu vieux peut-être, mais lors de ma propre prépa en 1998-2000 (MPSI en l'occurrence), la situation n'était pas aussi dramatique.

Maple pour une exploration formelle des mathématiques…

… Caml pour l'algorithmique. Programmation fonctionnelle fortement et statiquement typée, une jolie interface mêlant éditeur et prompt interactif à la QBasic. C'était très sympathique, en soit. Et une bonne introduction éventuelle à Objective Caml.

L'année suivante, Java a la fac, première année ou ils n'utilisaient pas C++
# De l'usage des synonymes

Posté par Perthmâd (site web personnel) le 24 mars 2012 à 11:28. Évalué à 3.

C'est un fait assez étonnant : je n'ai jamais entendu le mot « algorithmie » en dehors de linuxfr. Le mot est pourtant attesté par le TLFi, ce qui n'est pas rien. J'ai pour ma part toujours entendu « algorithmique » en lieu et place, et ce, dans une communauté assez vaste, de la prépa à tous les labos d'info que j'ai pu fréquenter.

Alors quid ? Est-ce une variante régionale ? Une variante sociologique, d'usage chez les ingénieurs ? Obi-wan Kenobi ?

P.S. : je trouve ce mot assez moche, et milite pour l'utilisation d'algorithmique à la place. Est-ce que vous dites la rythmie d'un morceau, vous ?
- [^] # Re: De l'usage des synonymes
  
  Posté par gaaaaaAab le 24 mars 2012 à 11:53. Évalué à 3.
  
  non, je dis "le rythme" ;-)
  
  Accessoirement, c'est aussi que le mot "rythmie" n'existe pas (en tout cas, pas dans le TLF).
  Cela dit, arythmie existe, et, d'après le tlf, est le "manque de régularité dans le rythme". Du coup, la rythmie pourrait être "la régularité dans le rythme", ce qui serait plutôt un pré requis qu'une qualité pour un morceau.
  - [^] # Re: De l'usage des synonymes
    
    Posté par Sylvain Sauvage le 25 mars 2012 à 17:41. Évalué à 6.
    
    La dérivation de mot peut sembler se faire à partir de leur forme (orthographe ou prononciation) mais elle se fait surtout dans leur groupement étymologique. Donc si, effectivement, il y a peut-être eu une influence du grec (a)rithmos ((ἀ)ριθμός, ce qui est mesuré (nombre)) ou de arithmétique (aussi du grec ἀριθμητική, compter, de τέχνη, art) sur la forme actuelle du mot algorithme (les premières orthographes étant plutôt proches de « augorisme »), cela n’en fait pas un mot construit sur ces mots-là. Effectivement, puisque vous lisez le TLF, regardez aussi la partie étymologie, vous verrez que algorithme viens de Al Ḫuwārizm, « celui de Huwārizm », surnom de Abdallāh Muhammad ibn Mūsā dont le livre a introduit les chiffres arabes et leur arithmétique en Europe.
    
    De fait, on peut dériver ce que l’on veut de algorithme, que ce soit l’adjectif et le nom algoritmique ou le nom algorithmie (personnellement : beurk).
    
    En fait, on pourrait aussi dire qu’on fait ce que l’on veut du moment que les autres nous comprennent, tout cela n’étant que conventions sociales émergentes.
    
    Et sur ce, enclume à tous.
# Utiliser sagemath

Posté par Ludo le 24 mars 2012 à 11:42. Évalué à 6.

http://www.sagemath.org/ Ça allie la force d'un vrai langage (Python) qui possède une floppée de librairies autour des maths (numpy, scipy…) et un GUI à la Mapple/Mathematica.

Je ne l'ai vu qu'en démo à la PyCON-FR l'année dernière, mais ça a l'air vraiment bien.
- [^] # Re: Utiliser sagemath
  
  Posté par Snark le 24 mars 2012 à 13:09. Évalué à 2.
  
  Rappelons au passage que sage vient de faire son entrée aux agrégations de mathématiques; voir cette dépêche récente.
  
  Car il existe des concours qui précisent quels logiciels sont accessibles aux candidats, avec quelle version exactement, dans quel environnement, etc. Et il y a les autres…
# Suggestion

Posté par thor_tue le 24 mars 2012 à 11:50. Évalué à 5.

J'ai longtemps cherché puis enfin trouvé un excellent outil : sagemath

En bref : c'est un outil extrêmement complet pour faire du calcul formel, numérique, des tracés de tous types, etc ; le tout avec Python comme langage. Et surtout il est libre (et gratuit).

Je ne suis pas expert en pédagogie, mais Python me paraît pas mal pour s'initier à l'algorithmique. Par rapport au C++ (que j'apprécie aussi), c'est vraiment le jour et la nuit, on a vraiment l'impression d'être débarrassé des détails et complications de la syntaxe de ce dernier.

Il me semble avoir vu qu'on le propose à ceux qui préparent l'agrégation de maths.

Nota : Je n'ai jamais testé OCAML.
- [^] # Re: Suggestion
  
  Posté par thor_tue le 24 mars 2012 à 11:53. Évalué à 1.
  
  J'ai lu le message précédent trop tard. ;)
- [^] # Re: Suggestion
  
  Posté par Jux (site web personnel) le 24 mars 2012 à 14:17. Évalué à 3.
  
  Sage est excellent ! Il y a aussi SymPy qui permet de faire du calcul formel en python.
  
  Je me suis récemment mis à python pour faire des calculs scientifiques (j'étais sur Matlab avant) et en découvrant numpy/scipy pour le calcul numérique et sage/sympy pour le calcul formel, c'est un vrai bonheur. Tout ça basé sur Python qui est un langage complet et élégant (contrairement à Matlab :)).
# Pourquoi faire, un langage ?

Posté par 2PetitsVerres le 25 mars 2012 à 05:11. Évalué à 6.

C'est quoi le rapport entre un cours (ou une épreuve) d'algorithmique (ou -rithmie) et un langage de programmation ? L'algorithmique ça s'apprend bien avec un papier et un crayon non ?

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
- [^] # Re: Pourquoi faire, un langage ?
  
  Posté par Dr BG (site web personnel) le 25 mars 2012 à 06:58. Évalué à 9.
  
  Mettre en pratique les algos avec un langage de programmation permet de faire des TP.
- [^] # Re: Pourquoi faire, un langage ?
  
  Posté par Didrik Pining le 26 mars 2012 à 13:49. Évalué à 1.
  
  Effectivement, oui, on faisait ça quand le temps machine était précieux, qu'il y avait une file d'attente pour lancer ses travaux batch, et où tu avais intérêt que ça marche du premier coup: Sinon on te rendait tes cartes et tu devais debugger à la main. En ce temps là effectivement, laisser les étudiants s'entrainer sur une vraie machine était impossible.
  
  Depuis, il me semble que ça a un peu changé.
- [^] # Re: Pourquoi faire, un langage ?
  
  Posté par steph1978 le 26 mars 2012 à 14:13. Évalué à 5.
  
  Tu apprends l'effet gyrostatique en cours physique, ça empêche pas de faire du vélo pour confirmer que ça fonctionne.
  - [^] # Re: Pourquoi faire, un langage ?
    
    Posté par 2PetitsVerres le 27 mars 2012 à 13:06. Évalué à 1.
    
    Tu fais du vélo pendant le cours de physique ?
    
    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
    - [^] # Re: Pourquoi faire, un langage ?
      
      Posté par steph1978 le 27 mars 2012 à 13:47. Évalué à 3.
      
      Qui a dit que cela devait se faire en même temps ?
    - [^] # Re: Pourquoi faire, un langage ?
      
      Posté par barmic le 28 mars 2012 à 18:23. Évalué à 2.
      
      Peut être pas du vélo, mais de la distillation par exemple oui.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Pourquoi faire, un langage ?
      
      Posté par windu.2b le 28 mars 2012 à 19:31. Évalué à 3.
      
      Je me souviens de la scène au début du film "187 : code meurtre" avec Samuel L. Jackson, qui est un professeur. Pour expliquer le principe de la force centrifuge à ses élèves, il utilise justement son vélo en cours.
# De l'enseignement de l'algorithmique en classes préparatoires autres que MP

Posté par 태 (site web personnel) le 25 mars 2012 à 11:38. Évalué à 2.

Le monde court un grave danger. […] une décision doit être prise.

Au secours, c'est un complot pour que les plus brillants esprits de cette génération construisent des ponts dans lesquels on pourra lancer des avions ! On se croirait vendredi !

C'est ainsi que naquit l'épreuve d'algorithmie d'une certaine école d'ingénieur.

De quelle "école d'ingénieur" (sic) s'agit-il ? J'ai eu des épreuves d'informatique dans tous les concours de grandes écoles que j'ai passés. Oui, dans les filières sérieuses, on ne fait pas juste de l'algorithmique, on fait de l'informatique (il y a par exemple un peu de théorie des langages).

Ajouter un élément à une liste [c'est tout pas beau].

Qu'attends-tu pour écrire ta propre procédure qui ajoute un élément à une liste, elle fait une ligne.

Les listes sont limitées. Il faut utiliser des tableaux qui ne sont pas redimensionnables.

Mmmh. Que les tableaux ne puissent être redimensionnés est assez classique. C'est vrai que des listes limitées à une taille 100, ça doit être lourd. Ils auraient du les limiter à 128 ou 1024.

L'interface est celle d'un outil de calcul formel.

Certes

Un peu comme un shell […] pas de coloration syntaxique

Un peu comme un interpréteur (ce qu'est le shell), on ne programme pas directement dans l'interpréteur mais dans un éditeur et on teste dans l'interpréteur.

Pas de possibilité d'entrée utilisateur

Pourtant, on peut créer des inputDialog, elles servent à quoi si ce n'est à obtenir des entrées utilisateur ?

Pas d'outil d'exécution pas à pas.

Il parait que si.

printf debugging

Quoi, il y a des sorties utilisateur, mais qu'est-ce que c'est que ce langage impur !

Maple serait un choix contestable pour former à l'informatique ou à la programmation généraliste (y compris à cause de son coût). Mais il ne s'agit ici pas de ça. Maple est utilisé comme outil de calcul formel et cerise sur le gâteau permet de faire de l'algorithmique. Parce que pour l'algorithmique, il n'y a pas besoin d'entrées sorties, il n'y a pas besoin de compilateur ou de performances particulières ! Il y a juste besoin de savoir structurer un processus (avec des structures de contrôle). Ça pourrait être porté par n'importe quel langage (basic si tu veux, ou pascal, ou javascript, ou…) mais dans le cadre d'une prépa scientifique, autant que ce soit avec un outil dans lequel on peut faire de la physique (enfin, la physique de prépa, ça pourrait s'appeler équations différentielles). Donc maple, matlab, mathematica… sont cohérents comme choix.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.