MicroAlg: langage et environnements pour l’algorithmique

Posté par ProfGra (site web personnel) le 23 octobre 2014 à 11:35. Édité par Benoît Sibaud, BAud, Xavier Teyssier, NeoX et tuiu pol. Modéré par Benoît Sibaud. Licence CC By‑SA.

Étiquettes :

oct.

2014

Professeur de mathématiques et d’informatique, n’étant pas pleinement satisfait par les outils pédagogiques du moment, j’ai décidé de créer MicroAlg. Une des forces de MicroAlg est qu’il est utilisable dans un navigateur (voir la page d’accueil du site officiel ou la galerie).

MicroAlg est un langage de programmation en « français » dédié à l’algorithmique et à son enseignement. Jeune (commencé fin mars 2014) et simple (des parenthèses pour seule syntaxe), il permet l’apprentissage des concepts les plus importants de l’algorithmique et de la programmation impérative.

La licence retenue est la GPL2. Des bibliothèques sont sous MIT, LGPLv3, BSD et Apache2. Le site est sous CC By Sa 3.0.

Exemple :

(Afficher "Quel âge as-tu ?")
(Si (< (Nombre (Demander)) 18)
 Alors (Afficher "Tu es mineur.")
 Sinon (Afficher "Tu prétends être majeur.")
)

Avis aux testeurs et aux contributeurs !

Aller plus loin

site officiel (1025 clics)
tutoriel interactif (268 clics)
documentation (130 clics)
galerie (153 clics)
FAQ (113 clics)
github (117 clics)

# Syntaxe lispienne, est-ce bien raisonnable ?

Posté par Thomas Douillard le 23 octobre 2014 à 12:29. Évalué à 10.

C'est certes une syntaxe simple, mais est-ce réellement important pour des débutants ?

Par exemple pour les expressions mathématiques, on a tellement l'habitude des expression infixes que ça risque de déstabiliser le débutant et de compliquer l'apprentissage, sans parler de la lisibilité du code. Et si c'est compliqué à lire, c'est encore plus compliqué de repérer les erreurs, notamment de syntaxe. Ce qui contrebalance largement les avantages d'avoir une syntaxe simple. Surtout sans les avantages d'un éditeur de texte avancé qui compte les parenthèse à ta place.
- [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
  
  Posté par macslan le 23 octobre 2014 à 13:31. Évalué à -10.
  
  le Brain****** est beaucoup plus simple c'est vrai :-D
- [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 18:18. Évalué à 8.
  Bonjour, merci pour ton commentaire.
  
  Je trouve qu’une syntaxe simple c’est important.
  J’ai choisi de privilégier la consistance (cmd arg1 arg2…) car ça me permet :
  - de simplifier les règles du langage,
  - de rendre l’arbre d’exécution transparent (ou presque, là j’arnaque un peu), jusqu’aux expressions mathématiques.
  Je sais bien que l’habitude infix n’aide pas, mais savoir traduire une expression simple comme 3n+1 vers (+ (* 3 n) 1) me paraît être un dans les prérequis pour l’algo ou la programmation. Et puis ce n’est rien d’autre que « la somme du produit de 3 et de n avec 1 ».
  
  Pour parler de l’éditeur, dans la version en ligne (et bientôt dans Notepad++ si j’arrive à écrire un plugin pour), les parenthèses sont colorées selon leur profondeur. Les étudiants apprécient beaucoup.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
    
    Posté par anaseto le 23 octobre 2014 à 19:09. Évalué à 8.
    
    Personnellement, je te rejoins sur la syntaxe : si l'objectif c'est juste d'apprendre des principes d'algorithmiques à des parfaits débutants, ils n'auront pas à écrire tout un tas de formules arithmétiques, mais plutôt à comprendre qu'est-ce qu'une boucle, une variable, etc. Donc que les formules ne soient pas écrites de façon pratique n'est pas important. J'irai même jusqu'à dire qu'au lieu d'utiliser des symboles comme < et +, on pourrait tout autant avoir inférieur et plus, histoire que ce soit bien clair que ces fonctions ne diffèrent pas par quelque magie des autres.
    
    Ceci dit, je pense que la syntaxe n'est pas non plus si importante que ça, du moment qu'elle est suffisamment intuitive, de sorte que si l'élève recopie un bout de code et l'adapte un peu, il n'ait pas de mauvaises surprises. Je pense que la façon d'expliquer les algos, etc. va être beaucoup plus importante pour les élèves que le choix d'une syntaxe ou d'une autre.
    - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
      
      Posté par Leslie Basmid le 23 octobre 2014 à 19:43. Évalué à 1.
      
      Si le public visé n'a pas à écrire des tas de formules compliquées mais juste à comprendre le concept de boucle, de variable, etc. pourquoi ne pas leur faire faire du C ? Oui le C peut-être très fastidieux, il peut être nécessaire de gérer sa mémoire, ses pointeurs, etc. Mais tout cela disparait si on ne fait que des choses simples et que l'on veut juste "comprendre qu'est-ce qu'une boucle, une variable, etc." Les exemples sur le site de calcul de reste de division euclidienne et de pgcd s'expriment très simplement en C.
      
      Mais plus grave dans ton commentaire: une addition est différente d'une fonction standard, pas par "quelque magie que ce soit" mais par hypothèse: avant d'arriver à la définition de groupe abélien, tu as du faire quelques années de mathématiques sans réaliser que + était une loi commutative de E x E -> E (avec (E,+) un groupe abélien), et de la sorte pas vraiment différent de n'importe quelle autre fonction de E x E -> E … Sauf qu'elle commute. Ah ? Mais alors, les deux lois (+ et *) de E x E -> E qui permettent de définir un corps commutatif différent-elles entre elles par quelque magie que ce soit ? Oui: par définition.
      
      Il faut être méfiant et ne pas sur-simplifier les choses en prenant le risque d'induire les élèves en erreur et leur compliquer l'apprentissage ensuite.
      - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par anaseto le 23 octobre 2014 à 19:58. Évalué à 6.
        
        Si le public visé n'a pas à écrire des tas de formules compliquées mais juste à comprendre le concept de boucle, de variable, etc. pourquoi ne pas leur faire faire du C ?
        
        Je pense que le fait de devoir compiler est une barrière, mais pour le reste, je ne pense pas que ce serait vraiment un problème, à part le fait que j'attendrais d'un langage pour débutant que faire des manipulations sur les chaînes de caractères soit plus simple (comme concaténer facilement, etc.), et préférablement typé dynamiquement.
        
        Il faut être méfiant et ne pas sur-simplifier les choses en prenant le risque d'induire les élèves en erreur et leur compliquer l'apprentissage ensuite.
        
        Dans le cas que tu mentionnes, je ne vois absolument pas en quoi le fait d'utiliser une notation infixe assure à l'élève que l'opérateur définit un groupe abélien : le signe < est tout aussi infixe, et pourtant donne une fonction tout sauf commutative. Et puis, enseigner le détail de propriétés algébriques des fonctions qu'il utilise à un élève, c'est pas vraiment, je pense, ce qu'il attend pour un cours de base sur l'algorithmique. Si c'est pour étudier ce genre de choses, autant passer direct à faire du coq, et démontrer soi-même que + est commutatif :)
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par Leslie Basmid le 23 octobre 2014 à 20:27. Évalué à 0.
        
        Dans le cas que tu mentionnes, je ne vois absolument pas en quoi le fait d'utiliser une notation infixe assure à l'élève que l'opérateur définit un groupe abélien : le signe < est tout aussi infixe, et pourtant donne une fonction tout sauf commutative.
        
        Nous sommes tout à fait d'accord, ce n'est pas le fait d'utiliser une notation pré-fixée qui va compliquer les choses (sur cet aspect), je n'ai pas été claire. Ce que je dis c'est que toutes les fonctions ne sont pas équivalentes, en témoignent les deux lois qui définissent une structure algébrique telle un corps commutatif. Je rebondissais donc sur le "histoire que ce soit bien clair que ces fonctions ne diffèrent pas par quelque magie des autres": il y a des fonctions qui sont différentes des autres par hypothèse. + et * ne sont pas des fonctions "comme les autres" sur un corps commutatif. Elles sont même très particulières… De même pour les relations d'ordre qui sont définies avec tout un tas de propriétés singulières, mais je vais cesser ici mon délire algébrique. Leur point commun serait de former des noeuds "équivalents" au sein de l'arbre d'interprétation, mais je crains que rentrer dans ces détails soit un peu complexe à ce niveau d'étude: comme est construit l'arbre a+b+c+d ? Par rapport à celui de a+b*c+d ? Celui de a*b+a*c+a*d ? Combien d'arbres différents sont possibles ? etc. On est sorti des "simples" concepts de boucle, variable et co. et on commence à rentrer dans des aspects de compilation qui te semblent être une barrière.
        
        Et puis, enseigner le détail de propriétés algébriques des fonctions qu'il utilise à un élève, c'est pas vraiment, je pense, ce qu'il attend pour un cours de base sur l'algorithmique. Si c'est pour étudier ce genre de choses, autant passer direct à faire du coq, et démontrer soi-même que + est commutatif :)
        
        Tout à fait, enseigner les détails des propriétés algébriques trop tôt, ça a déjà été essayé et ça a été un échec retentissant (je pense au triste épisode des "maths modernes"). Je rentre dans ces détails car nous sommes entre nous, et il me servent à montrer que toutes les fonctions ne sont pas équivalentes.
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par anaseto le 23 octobre 2014 à 21:12. Évalué à 4.
        
        Je suis d'accord que mettre en évidence certaines différences et points communs entre fonctions est intéressant. Ceci dit, pour revenir à ta remarque, l'avantage d'écrire (plus 2 3) c'est potentiellement justement que l'élève peut être amené à se poser des questions de commutativité, etc. qu'il ne se posera jamais si c'est écrit de la façon à laquelle il est habitué en cours de maths. Il y a sans doute un intérêt pédagogique aussi à écrire les choses de façon différente à son cours de maths, et donner des exemples qui justifient cela, comme mettre un effet de bord sur un des arguments, et s'apercevoir qu'en fait + n'est pas forcément commutatif dans tous les langages de programmation (ou plutôt, qu'il ne l'est que dans de rares langages).
        
        Et par "quelque magie", j'entendais qu'écrire certaines fonctions avec des syntaxes spéciales peut carrément conduire l'élève à penser qu'il ne s'agit même pas d'une fonction, et ne pas faire le lien avec une fonction "normale".
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par ProfGra (site web personnel) le 23 octobre 2014 à 22:35. Évalué à 6.
        
        comme est construit l'arbre a+b+c+d ?
        
        + avec 4 enfants
        
        Par rapport à celui de a+b*c+d ?
        
        + avec 3 enfants, dont * avec 2 enfants
        
        Celui de a*b+a*c+a*d ?
        
        + avec 3 enfants, tous de la forme * avec 2 enfants
        
        Je trouve ça parfait justement ! On explicite les priorités !
        
        Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
      - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par Antoine le 23 octobre 2014 à 20:24. Évalué à 7.
        
        s'expriment très simplement en C
        
        compiler à chaque changement ("make" ? "gcc" ?)
        
        ajouter des incantations mystérieuses ("#include" ?)
        
        afficher des valeurs ("printf" ? "%d" ?)
        
        …
        
        Ça fait pas mal de distractions pour un cours de niveau débutant total.
        
        Par contre il y a pas mal de variantes de Python s'exécutant dans un navigateur, je crois. Par exemple :
        
        https://www.pythonanywhere.com/try-ipython/
        
        http://repl.it/languages/Python
        
        http://www.skulpt.org/
        
        http://pythontutor.com/
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par Leslie Basmid le 23 octobre 2014 à 20:46. Évalué à 7.
        
        Dur de répondre à ce commentaire sans vraiment s'enfoncer dans le troll sur les langages, nous serons vendredi dans quelques heures, mais tout de même :)
        
        compiler à chaque changement ("make" ? "gcc" ?)
        
        ajouter des incantations mystérieuses ("#include" ?)
        
        afficher des valeurs ("printf" ? "%d" ?)
        
        …
        
        Pour compiler, pourquoi ne pas simplement cliquer sur la petite roue dentée d'un IDE ? Parce qu'on ne va tout de même pas les plonger tout de suite dans le code dans un shell ? Quelle différence fondamentale entre deux "clics" (compilier, puis exécuter) et un clic pour exécuter ? La plupart des IDE incluent maintenant un bouton "compiler & exécuter"… Et on a dit des programmes simples comme hypothèse… Un seul .c devrait suffire, non ? Donc les autotools… out.
        
        Les incantations mystérieuses, c'est vrai que c'est peut-être un obstacle (bien que j'en doute, on doit pouvoir les faire admettre comme hypothèse). En ce sens, MicroAlg fait un bon travail, c'est certain. Maintenant lorsque je regarde les autres langages, ces includes sont souvent là (et très nécessaires dès que l'on veut faire quelque chose de sérieux): des "import" de python ou Haskell, aux "use" de Perl en passant par les include de Caml… Dur de s'en passer… Je pense même que des élèves qui auront fièrement fait leurs premières fonctions, vont vite trouver pénible de toujours devoir recopier tout leur code quand ils veulent en faire d'autres… Non ?
        
        Quant au fait d'afficher des valeurs… Ca aussi c'est dur dès que le langage est typé. La fonction print de python est très fonctionnelle et agréable à utiliser, mais elle n'est pas toujours très simple non plus en témoignent les "Simple Programs" du site officiel: tu retrouve tes symboles ésotériques. Même avec des langages objets différents (attention, je ne veux pas marcher dans le troll !) tels C++ les choses deviennent vite pénibles à coup de cout << … Non clairement l'affichage semble avoir toujours été un problème complexe, je n'ai pas de solution magique: je me débrouille avec ce que j'ai dans le langage que je dois utiliser.
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par anaseto le 23 octobre 2014 à 21:23. Évalué à 4.
        
        Maintenant lorsque je regarde les autres langages, ces includes sont souvent là (et très nécessaires dès que l'on veut faire quelque chose de sérieux): des "import" de python ou Haskell, aux "use" de Perl en passant par les include de Caml… Dur de s'en passer… Je pense même que des élèves qui auront fièrement fait leurs premières fonctions, vont vite trouver pénible de toujours devoir recopier tout leur code quand ils veulent en faire d'autres… Non ?
        
        Sans doute, je pense que la différence c'est qu'en C tu as besoin d'incantations même pour des choses basiques, alors que d'autres langages permettent de faire de l'algo de base, affichage, etc. avant d'avoir besoin d'utiliser des modules. Franchement, je suis d'accord que ça ne va pas être une barrière insurmontable, mais je vois pas non plus d'argument en faveur d'utiliser C pour apprendre l'algorithmique, vu que le jour où le petit nombre de ces élèves qui deviendra informaticien aura besoin d'apprendre C, ça ne lui changera pas beaucoup de connaître un peu sa syntaxe depuis le lycée, je pense.
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par freem le 24 octobre 2014 à 13:40. Évalué à 9.
        
        Et accessoirement, il n'y à pas besoin de connaître le C pour être "informaticien" ou même développeur. Ce n'est rien d'autre qu'un langage comme un autre, ce n'est ni le seul langage ancien, ni le seul langage bas niveau, ni le seul langage compilé, ni le seul langage portable, ni le seul langage que l'on peut utiliser "gratuitement".
        
        Et c'est encore moins le seul langage qui cumule ces qualificatifs.
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par DerekSagan le 26 octobre 2014 à 10:02. Évalué à 1.
        
        C'est vrai mais ça reste le langage incontournable pour un développeur complet, c'est-à-dire qui code à la fois de l'appli en ligne de commande, de l'appli graphique, du système, du noyau, du middleware, et de l'embarqué.
        
        Même s'il a plein de défaut et que sur chacun de ces domaines il peut être remplacé assez facilement, pas sur tous. Et même si c'est probablement pas avec ça qu'il faut commencer.
      - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par ProfGra (site web personnel) le 23 octobre 2014 à 22:17. Évalué à 8.
        
        Bonjour, et merci pour ton commentaire.
        
        […] pourquoi ne pas leur faire faire du C ? Oui le C peut-être très fastidieux,
        
        Pratique ! Tu réponds à tes propres questions ! Bon, j’arrête.
        
        il peut être nécessaire de gérer sa mémoire, ses pointeurs, etc. Mais tout cela disparait si on ne fait que des choses simples
        
        Je suis tout à fait d’accord. J’ai pensé aussi que c’était clâsse de donner cet outil à un élève/étudiant pour la suite de son aventure. Moi-même j’aurais aimé commencer le C plus tôt. Mais :
        
        la syntaxe n’est pas triviale,
        
        l’environnement de dev n’est pas trivial,
        
        difficile de faire travailler l’apprenant en ligne, encore plus difficile si on veut travailler direct dans le client,
        
        c’est en anglais (surtout les msg d’erreur),
        
        …
        
        Par exemple, le C au collège, je n’y crois pas.
        
        Sinon, je n’ai rien compris à l’histoire de l’addition. Je ne vois pas en quoi je la simplifie, et du coup non plus pourquoi ça gênerait. Je veux bien des explications.
        
        Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
        
        [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par lolop (site web personnel) le 24 octobre 2014 à 08:42. Évalué à 9.
        
        Un truc simple qui pose des problèmes en C: les chaînes de caractères, qui nécessitent d'avoir rapidement une idée sur les tableaux… et les pointeurs (je ne parle même pas de l'encodage - vaut mieux rester en un truc 1 caractère/octet genre latin1).
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
        
        Posté par Diagonale de Cantor (site web personnel) le 23 octobre 2014 à 23:13. Évalué à 3. Dernière modification le 23 octobre 2014 à 23:16.
        
        Mais plus grave dans ton commentaire: une addition est différente d'une fonction standard, pas par "quelque magie que ce soit" mais par hypothèse: avant d'arriver à la définition de groupe abélien, tu as du faire quelques années de mathématiques sans réaliser que + était une loi commutative de E x E -> E (avec (E,+) un groupe abélien), et de la sorte pas vraiment différent de n'importe quelle autre fonction de E x E -> E … Sauf qu'elle commute. Ah ? Mais alors, les deux lois (+ et *) de E x E -> E qui permettent de définir un corps commutatif différent-elles entre elles par quelque magie que ce soit ? Oui: par définition.
        
        Une opération ce n’est rien d’autre qu’un type particulier de fonction.
        
        Par exemple PGCD PPCM MAX MIN peuvent être vu comme des opérations. Par exemple tu peux jeter un coup d’œil au Mathématiques tropicales ou on travaille avec un semi-corps où l‘addition est définie par MIN et la multiplication par +.
        
        De plus - et / sont algébriquement pourries. Par exemple, ce n’est même pas associatif !
        
        (1/2) / 2 est différent que 1 / (2/2)
        
        Tu va me dire ça ne compte pas, c’est des opération inverses de + et *. Alors parlons de la puissance.
        
        $(2^2)^{1/2} = \sqrt{4} = 2 \neq 2^(2^{1/2})= 2^\sqrt{2}$
        
        Donc franchement son idée de définir des opération comme des fonctions est loin d’être stupide et au pire encourageront les élèves à réfléchir sur ce qu’est un fonction et ce qu’est une opération. En fait pourquoi avoir deux types (fonction et opération) quand un seul type suffit (on a vu que les bonne propriété des opération n’avait rien à voir : MIN est plus sympathique algébriquement que ^ par exemple).
- [^] # Re: Syntaxe lispienne, est-ce bien raisonnable ?
  
  Posté par Zylabon le 23 octobre 2014 à 21:00. Évalué à 2.
  
  C'est certes une syntaxe simple, mais est-ce réellement important pour des débutants ?
  
  Sachant que la sémantique du langage du langage le plus fréquemment recommandé pour les débutant est indépendante de la représentation textuelle du programme, on se dit que lisp, c'est pas plus mal.
  
  Please do not feed the trolls
# Dans un navigateur…

Posté par lolop (site web personnel) le 23 octobre 2014 à 13:35. Évalué à 6. Dernière modification le 23 octobre 2014 à 13:37.

Voir http://www.pythontutor.com/, qui permet d'exécuter des petits scripts Python (2 ou 3) en pas à pas, avec la visualisation d'espace mémoire à côté.

http://www.pythontutor.com/visualize.html#mode=edit

Ça donner des idées pour une l'interface (bon, pas parfait, il n'a pas aimé le range() avec deux arguments — marche avec 1 argument et avec 3, pas avec 2)

Et en bas de la page d'accueil il y a des liens vers online Java/Ruby/Javascript tutor & Co.

Après, le choix du français retire une barrière pour certains étudiant, ce qui peut être bien ; mais le choix d'un langage ad-hoc bloque l'utilisation dans un cadre plus large, dommage pour ceux qui voudraient aller plus loin, et cela coupe l'enseignement de toutes les ressources déjà dispos autour d'outils existants.

Bons enseignements.

Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
- [^] # Re: Dans un navigateur…
  
  Posté par ord le 23 octobre 2014 à 13:56. Évalué à 7.
  
  Après, le choix du français retire une barrière pour certains étudiant
  
  les etudiants qui sont pas capable d'apprendre en 10min le minimum d'anglais que python demande ils sont probablement pas capable de programmer de toute facon …..
  - [^] # Re: Dans un navigateur…
    
    Posté par lolop (site web personnel) le 23 octobre 2014 à 14:16. Évalué à 6.
    
    Oui, mais leurs enseignants sont sensés leur apprendre… si ça retire une barrière. Faut voir quel niveau ils ont et ce qu'ils devraient savoir en fin d'année.
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
    - [^] # Re: Dans un navigateur…
      
      Posté par djano le 24 octobre 2014 à 04:30. Évalué à 2.
      
      Ca c'est en supposant que les enseignants parlent anglais :)
      - [^] # Re: enseignants anglophones
        
        Posté par ProfGra (site web personnel) le 24 octobre 2014 à 07:35. Évalué à 4. Dernière modification le 24 octobre 2014 à 07:36.
        
        Ça c'est en supposant que les enseignants parlent anglais :)
        
        Ce commentaire est subtilement placé entre (gentille) blague rabaissant les profs et réalité du terrain !
        J’accueille volontiers la blague, pas de problème. Je voulais juste dire que pour les profs de maths d’une certaine génération, qui ont du se mettre à l’algo avec les programme de seconde de 2009, mais qui n’étaient ni familier avec l’algo, les langages, les ordis… l’anglais a pu rajouter une couche.
        On est à une époque charnière où on a aussi beaucoup de grands débutants en algo qui sont adultes, et pas forcément anglophones non plus.
        
        Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Dans un navigateur…
    
    Posté par ProfGra (site web personnel) le 23 octobre 2014 à 18:33. Évalué à 5.
    
    On ne veut pas forcément en faire des programmeurs, on veut parfois juste passer l’idée d’algo.
    Aussi, j’ai envie de pouvoir m’adresser peut-être à des tous jeunes (collège, voire primaire), donc au niveau de l’anglais, ça peut être très limité.
    
    Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Dans un navigateur…
    
    Posté par lasher le 23 octobre 2014 à 19:44. Évalué à 4.
    
    Je pense que tout dépend de ce qu'on entend par « étudiant ». Si on parle de niveau fac, je suis assez d'accord. Si on parle en-dessous, je trouve pas forcément débile de se concentrer sur l'enseignement de l'algorithmique d'abord, en oubliant « la vie réelle », puis ensuite il sera toujours temps d'apprendre les quelques mots de vocabulaire en Anglais qui sont nécessaires.
- [^] # Re: Dans un navigateur…
  
  Posté par deuzene (site web personnel) le 23 octobre 2014 à 17:35. Évalué à 3.
  
  Une question de béotien à ce sujet.
  Ne serait-il pas possible d'imaginer une langage, du type de Microalg, mais je pense aussi à Linotte, où chacun pourrait écrire dans sa langue. Ainsi dans le code donné en exemple deviendrait ceci :
  
  (Print "Quel âge as-tu ?") (If (< (Nombre (Ask)) 18) Then (Print "Tu es mineur.") Else (Print "Tu prétends être majeur.") )
  
  Charge à l'interpréteur de faire les correspondances. Bien sûr on perd de la lisibilité (et encore, il serait facile de traduire un code source d'une langue à l'autre).
  
  Il me semble que la syntaxe est plus importante que les mots utilisés, pourquoi ajouter une barrière linguistique alors que le but est d'enseigner l'algorithmique ?
  
  Votre avis m'intéresse.
  
  « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
  - [^] # Re: Dans un navigateur…
    
    Posté par freem le 23 octobre 2014 à 17:54. Évalué à 5.
    
    Windev quoi…
  - [^] # Re: Dans un navigateur…
    
    Posté par Nicolas Melay le 23 octobre 2014 à 19:15. Évalué à -1.
    
    Error: Nombre: Unknown statement.
  - [^] # Re: Dans un navigateur…
    
    Posté par ProfGra (site web personnel) le 23 octobre 2014 à 23:00. Évalué à 1.
    
    Ne serait-il pas possible d'imaginer une langage […] où chacun pourrait écrire dans sa langue.
    
    J’y ai bien pensé, mais je l’ai rayé du cahier des charges. Je n’ai pas autant d’ambition (pourtant, j’en ai). Mais ça me donne envie de mener une enquête. Je vais aller voir mes collègues de langue;)
    
    Ça serait possible avec MicroAlg, à ceci près que certaines constructions peuvent s’exprimer avec un nombre différent de mots dans différentes langues. Faut voir la galère que ça peut être de traduire déjà les singuliers/pluriels…
    Je pense au Faire… Tant_que…. En anglais on aurait Do… While…, mais pas sûr que ce soit aussi simple dans toutes les langues.
    
    En fait quand je dis que j’y ai pensé, je n’avais pas pensé à la traduction dans différentes langues d’un même algo. Mais dans ce cas, que faire des noms de variables ?
    
    Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
    - [^] # Re: Dans un navigateur…
      
      Posté par freem le 24 octobre 2014 à 13:44. Évalué à 1.
      
      Mais dans ce cas, que faire des noms de variables ?
      
      google trad' est ton ami… non je déconnne :)
    - [^] # Re: Dans un navigateur…
      
      Posté par Pierre Jarillon (site web personnel) le 25 octobre 2014 à 22:00. Évalué à 6.
      
      J'aime bien le nom des variables en français car ça les différencie des instructions en anglais. À condition que le programme soit destiné essentiellement à des francophones…
- [^] # Re: Dans un navigateur…
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 18:30. Évalué à 2.
  Bonjour, merci pour ton commentaire.
  
  Oui, je connais OPT, je m’en sers ici.
  Le projet est encore jeune (moins de 6 mois !) donc je n’ai pas encore eu le temps de tout implémenter. Il est prévu :
  - d’inclure un truc du genre OPT (Blockly le permet avec un système de surlignage, et je compte le faire dans l’éditeur en ligne au moins avec du highlight,
  - de générer une trace des contenus des variables (PicoLisp le permet).
  Pareil pour « l’utilisation dans un cadre plus large », c’est un peu la même réponse : le projet est jeune. Je compte l’intégrer avec Geogebra entre autres, ce qui permettra déjà pas mal de folies. Ensuite, il sera possible d’intégrer des libs JS ou Java du genre game engines.
  
  Tu pourrais détailler « les ressources déjà dispos autour d'outils existants » ?
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Dans un navigateur…
    
    Posté par lolop (site web personnel) le 23 octobre 2014 à 18:46. Évalué à 2.
    
    Tu pourrais détailler « les ressources déjà dispos autour d'outils existants » ?
    
    Au niveau enseignement, je pensais à tout ce qui est cours (langage ou algo), exercices, TDs, TPs, documentations, etc.
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Dans un navigateur…
    
    Posté par lolop (site web personnel) le 23 octobre 2014 à 18:54. Évalué à 2.
    
    Ah, et si un jour tu peux écrire un backend MicroAlg pour Jupyter… ça t'évitera de coder toute la partie web.
    
    http://jupyter.org/
    
    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Et l'apprentissage ?

Posté par Hopper (site web personnel) le 23 octobre 2014 à 13:36. Évalué à 4.

Je suis d'accord sur le principe de vouloir faire évoluer les outils, étant moi-même élève en lycée je comprend ce besoin, cependant cela risque d'aller à l'encontre de l'apprentissage réel du code.
Le langage naturel existe déjà pour cela, autant créer des outils pour apprendre facilement mais correctement.
- [^] # Re: Et l'apprentissage ?
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 19:45. Évalué à 4.
  
  Bonjour, merci pour ton commentaire.
  
  […] cela risque d'aller à l'encontre de l'apprentissage réel du code.
  
  Le but ici est l’algorithmique, qui pour moi est un prérequis au «code», voire au «codaz». J’espère que je ne vais pas à son encontre !
  Ou alors je n’ai pas compris ! Tu pourrais détailler ?
  
  Le langage naturel existe déjà pour cela,
  
  Oui, mais il n’est pas exécutable. Par contre je ne crache pas dessus, je m’en sers bien sûr en amont.
  
  autant créer des outils pour apprendre facilement mais correctement.
  
  Comment ça correctement ?
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Et l'apprentissage ?
    
    Posté par Hopper (site web personnel) le 24 octobre 2014 à 23:58. Évalué à 0.
    
    Il est vrai que j'ai un peu confondu "code" et "algorithmique" désolé, mais j'entends par cela que l'élève devrais (à mon sens) apprendre les base sur un langage courant : pas forcément du C mais plutôt du PHP avec un peu de HTML par exemple, il est aisé pour les élèves de faire des algorithmes simples en mettant en place un petit serveur.
    Ce que j'ai trouvé bizarre avec MicroAlg c'est que cela me fait penser à Algobox, mis à part le principe de la rédaction directe du code sans passer par deux-milles boites de dialogue, là je suis tout à fait d'accord.
    L'on peut par exemple imaginer un IDE qui ferait progresser l'élève : au début il écrit son code comme vous le démontrez dans votre exemple, puis petit à petit ce code se transforme, des points-virgules apparaissent, des accolades, … Et on se rapproche d'un langage tel que le C.
    Je ne sais pas si je suis très clair (si ce n'est pas le cas je m'en excuse), en tous cas c'est la vision que j'ai d'un outil d'apprentissage du code.
    
    Mais il est vrai que je m'éparpille vers du codage plutôt que vers de l'algorithmique, et je m'en excuse.
    - [^] # Re: Et l'apprentissage ?
      
      Posté par freem le 27 octobre 2014 à 11:22. Évalué à 5.
      
      Commencer par PHP, avec du HTML?
      Euh… quitte à enseigner le dev/l'aglo, autant utiliser des langages qui sont conçus, dès le départ, pour être enseignés. PHP n'en fait pas partie, il s'agit d'un langage qui me donne personnellement l'impression d'être brouillon.
      Basic, peut-être (suis pas sûr), pascal, très certainement, et idem pour python.
      
      Pour continuer sur PHP, tu dis:
      
      plutôt du PHP avec un peu de HTML par exemple, il est aisé pour les élèves de faire des algorithmes simples en mettant en place un petit serveur.
      
      Monter un serveur (par élève histoire qu'il y en ait pas un qui foute la merde…), enseigner PHP et HTML côte à côte?
      Que ce soit pour enseigner du dev généraliste ou de l'algo, je sais une chose: je ne me tournerais pas vers un langage purement web, tel que PHP: il y à bien trop de choses à apprendre autour pour arriver à comprendre ce que l'on fait. Par exemple, pourquoi le HTML ne réagit pas de la même manière sur toutes les machines (fonction du browser et même de sa version!)? Il n'y à rien de plus frustrant que les bugs qui sont fonction de l'environnement, surtout pour un élève je pense.
    - [^] # Re: Et l'apprentissage ?
      
      Posté par ProfGra (site web personnel) le 27 octobre 2014 à 18:31. Évalué à 2.
      
      […] plutôt du PHP avec un peu de HTML […]
      
      Je suis tout à fait d’accord avec freem: PHP est moche (selon mes critères pédagogiques bien sûr), et c’est du sadisme que de passer par la génération de HTML. En revanche, j’ai des collègues qui utilisent PHP en ligne de commande pour l’algo (je le fais aussi, mais qd je les forme en dev par exemple pour les tests). C’est intéressant car dans ce cas, ça fait un langage de moins à apprendre.
      
      L'on peut par exemple imaginer un IDE qui ferait progresser l'élève : au début il écrit son code comme vous le démontrez dans votre exemple, puis petit à petit ce code se transforme, des points-virgules apparaissent, des accolades, … Et on se rapproche d'un langage tel que le C. […]
      
      Bof. L’idée avec l’algorithmique, c’est de se fabriquer une image mentale d’un algorithme, qui transcenderait les langages. Le coup du morphing, je ne me lancerais pas dedans. Faudrait-il cibler tous les langages impératifs ?
      
      Mais il est vrai que je m'éparpille vers du codage plutôt que vers de l'algorithmique, et je m'en excuse.
      
      Oui, mais pas de problème, merci pour tes commentaires !
      
      Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
- [^] # Re: Et l'apprentissage ?
  
  Posté par lasher le 23 octobre 2014 à 19:55. Évalué à 5.
  
  […] Le langage naturel existe déjà pour cela, autant créer des outils pour apprendre facilement mais correctement.
  
  Le langage naturel ne peut pas être analysé efficacement. :) Il est important de proposer un langage un peu formel pour habituer l'élève à raisonner et exprimer ses idées d'algo « formellement ». Le vrai code de « vie réelle » ressemble de toute façon rarement à celui montré en cours par le prof ou même à celui que les élèves produisent pour leurs projets. Pour l'apprentissage de l'algorithmique, la syntaxe importe peu, du moment qu'elle est simple et cohérente. L'intérêt d'avoir un langage précis pour l'apprentissage de l'algo, c'est que tu peux facilement prévenir des comportements déviants (plus qu'avec un « vrai » langage généraliste). En collège ou lycée, il est plus important de donner de bonnes bases que de chercher absolument à faire apprendre la programmation en utilisant de vrais outils. Mon premier contact avec un langage de programmation, c'était Logo, en primaire. Lorsque j'ai essayé d'apprendre Pascal par moi-même quelques années plus tard, autant te dire que ce n'était pas la fête. Entre les mots en anglais à retenir, la syntaxe, etc., j'ai assez vite jeté l'éponge. J'ai eu mon premier contact avec l'assembleur au lycée sur un processeur 6809, et pas sur du x86, et c'est tant mieux.
# PIP

Posté par Tonton Benoit le 23 octobre 2014 à 14:04. Évalué à 10.

Dans les années 80 on a crées le Lisp sans parenthèses (Logo) pour apprendre l'informatique aux plus jeunes, voilà maintenant les parenthèses sans Lisp :D

Plus sérieusement, bonne initiative !
- [^] # Re: PIP
  
  Posté par ProfGra (site web personnel) le 24 octobre 2014 à 07:15. Évalué à 1.
  
  Bonjour,
  
  Dans les années 80 on a crées le Lisp sans parenthèses (Logo) pour apprendre l'informatique aux plus jeunes, voilà maintenant les parenthèses sans Lisp :D
  
  C’est exactement ça. J’espère quand même que, une fois le minimum vital de l’impératif implémenté, je pourrai caser les fonctions comme entités de première classe. C’est le cas dans le langage sur lequel je me base, il faut juste trouver une interface simple à ces mécanismes.
  
  Plus sérieusement, bonne initiative !
  
  Merci pour ce commentaire chaleureux ! Mais au fait, pourquoi « PIP » ?
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: PIP
    
    Posté par Tonton Benoit le 24 octobre 2014 à 10:47. Évalué à 3.
    
    Plan Informatique pour Tous, toute notre enfance :D
    - [^] # Re: PIP
      
      Posté par NumOpen le 27 octobre 2014 à 17:50. Évalué à 2.
      
      Donc c'est PIT, pas PIP ?
      - [^] # Re: PIP
        
        Posté par Tonton Benoit le 27 octobre 2014 à 20:13. Évalué à 2.
        
        Oui :) Bug d'interface chaise-clavier.
# Décalage

Posté par arnaudus le 23 octobre 2014 à 14:04. Évalué à 10. Dernière modification le 23 octobre 2014 à 14:05.

On a déja vu passer de nombreuses tentatives de traduction de langages informatiques, et, personnellement, je n'en ai jamais compris l'intérêt. Ça semble partir de l'hypothèse que les langages existants sont en anglais, et que cela pourrait constituer une barrière à l'apprentissage.

Or, d'après mon expérience, c'est complètement faux. D'une part, les langages informatique ne sont pas en anglais (seuls quelques mot-clé, souvent très rares, le sont), et d'autre part, la barrière à l'apprentissage est la logique de la programmation, et pas la syntaxe (sauf évidemment pour les langages à la con où on écrit "(Si (< (Nombre (Demander)) 18)"). Personnellement, je me rappelle avoir appris à programmer dans l'espèce de basic moche des calculatrices scientifiques, avec 5 mots clés qui se battent en duel. Ce qui est compliqué, c'est de comprendre le fonctionnement d'une boucle "for", ça n'est pas de piger que "for" veut dire "pour". D'ailleurs, je me rappelle bien avoir compris des années après que "goto" voulait dire "go to". Beaucoup de mots clé sont transparents (library, return, function, vector, stop, break, continue, …), beaucoup sont complètement obscurs même pour un anglophone (cout, cerr, fork, push, chomp, grep…), et dans tous les cas, il est strictement impossible de comprendre intuitivement comment les utiliser.

Si je devais enseigner la programmation à un vrai débutant dans de bonnes conditions, je prendrais un langage simple (if(a>0) et pas if(>(a 0))), interprété (le principe de la compilation est hyper-complexe, en fait), sans pièges syntaxiques (style if (a = 0) vs. (a == 0)), sans trucs énervants (du genre les points virgule…), non-typé (la rigueur, ça viendra après), et avec une bibliothèque graphique simple et naive (parce que les débutants, ils ne voient pas l'intérêt de rentrer des valeurs dans un terminal). Deux structures de contrôle (if/else et for), et c'est parti. En plus, utiliser des mot-clés qu'on ne comprend pas vraiment permet de dissocier la logique de la langue (par exemple, le "ou" qui tend à être exclusif) avec celle du formalisme informatique.
- [^] # Re: Décalage
  
  Posté par Nicolas Boulay (site web personnel) le 23 octobre 2014 à 14:14. Évalué à 4.
  
  Je suis d'accord avec toi, une library graphique apporterait un énorme plus. Tout ce qui est graphique est toujours un plus quand on aborde un nouveau sujet.
  
  Par contre, à la place de if/else et for, je préférais un switch/map, c'est finalement bien plus simple à comprendre qu'une boucle.
  
  "La première sécurité est la liberté"
  - [^] # Re: Décalage
    
    Posté par Tony Flow le 23 octobre 2014 à 17:11. Évalué à 4.
    
    Je suis d'accord avec toi, une library graphique apporterait un énorme plus. Tout ce qui est graphique est toujours un plus quand on aborde un nouveau sujet.
    
    Je suis tout à fait d'accord : un résultat graphique peut être plus parlant et satisfaisant.
    
    Personnellement j'ai fais mes premiers pas avec l'informatique et la programmation dès l'école primaire sur des mo5 avec le logo et sa fameuse tortue. Je suppose que ça a prit un coup de vieux et qu'il en faut sans doute plus pour attirer les jeunes d'aujourd'hui… Néanmoins je pense que ça reste un super outil pédagogique pour s'initier à l'algorithmie.
- [^] # Re: Décalage
  
  Posté par Trollgouin le 23 octobre 2014 à 15:25. Évalué à 3.
  
  Globalement d'accord sur le fond du commentaire. Qq détails néanmoins:
  
  Si je devais enseigner la programmation à un vrai débutant dans de bonnes conditions, je prendrais un langage […] interprété (le principe de la compilation est hyper-complexe, en fait),
  
  Peut-être interprété, mais avec une très bonne vérification syntaxique et des messages d'erreur clairs. Et ça, j'ai pas l'impression que ce soit facile à trouver avec des langages (coïncidence? Erreur de ma part? Corrélation cachée avec d'autre facteurs comme le typage fortement dynamique?).
  
  sans trucs énervants (du genre les points virgule…)
  
  Les étudiants ne butent pas trop sur les points-virgule. C'est assez systématique pour ne pas les gêner.
  
  non-typé (la rigueur, ça viendra après),
  
  Et bien sur ce point, je constate à ma propre surprise que ça dépend vraiment des individus! Ceux qui sont à l'aise (entre autre parce qu'ils ont déjà programmé en typage statique) s'en tirent très bien avec le duck typing (je suppose que c'est ce que tu appelles non typé). D'autres, à l'esprit plus brouillon, sont guidés par les types parce qu'il réduisent les actions possibles sur leurs objets/variables et se retrouvent à débugger des programmes où ils affectent des poires dans des lapins. Bref, pas facile de faire un choix.
  
  Plus généralement, la rigueur, ce n'est pas une discipline ou un savoir faire, c'est d'abord une façon de penser. Beaucoup d'étudiants sont "intentionistes": la "machine" (l'interpréteur de commandes ou de script, le compilateur…) doit s'adapter à moi et comprendre ce que je souhaite parce qu'après tout, mon intention en pseudo-français est indiquée dans le programme. Et beaucoup de dépassent jamais ce stade.
  
  Au contraire, la première chose à comprendre, c'est que c'est à l'humain d'adopter une syntaxe précise et que la sémantique n'a pas une interprétation automagique pour coller à tes besoins non exprimés (hormis peut-être la PLC et encore…).
  
  et avec une bibliothèque graphique simple et naive (parce que les débutants, ils ne voient pas l'intérêt de rentrer des valeurs dans un terminal).
  
  Vrai pour une partie d'entre eux. À tel point que le html devient leur langage de 'programmation' (sisi, je l'entends régulièrement) :( Pour avoir essayé des approches très graphiques (avec des boîtes noires maison qui leur simplifie la vie), on s'est retrouvé avec une partie des étudiant incapables de gérer plus d'un niveau de boucle, ou de coder une couche métier.
  
  Toujours dans les trucs bizarre, il y a des jeunots super doués pour assembler par copié/collé des bouts de code en un ensemble à peu près fonctionnel mais qu'ils ne comprennent vraiment pas!
  - [^] # Re: Décalage
    
    Posté par djibb (site web personnel) le 23 octobre 2014 à 16:03. Évalué à 4.
    
    personnellement, enseignant du python, je peux te dire que le problème des types est un vrai problème en soi et qu'avoir un langage où le typage est statique peut-être un vrai plus pour les débutants.
    
    C'est pourquoi je regarde ça de près: http://www.mypy-lang.org/
  - [^] # Re: Décalage
    
    Posté par arnaudus le 23 octobre 2014 à 16:44. Évalué à 4. Dernière modification le 23 octobre 2014 à 16:45.
    
    Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. Enfin, ça dépend tout bêtement des gens, certains vont capter quelque chose du premier coup, d'autres ne capteront jamais. En particulier, j'ai l'impression que certaines personnes sont totalement inaptes à "exécuter" un programme de tête (a = 1; b = 2; b = (a+b)/b; a=(a+b)/2; est-ce a == b ? "euuuuuhhhhh"), ce qui rend la programmation beaucoup plus difficile pour eux (ils ne s'en sortent qu'en copiant des patterns, mais ne peuvent pas innover).
    
    Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. S'il y a un seul truc que je garderais de perl, c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres. Parce que bon, il faut être honnête, 99.9…% des opérations de ce style ne sont absolument pas ambigües, et je trouve ça super sympa de pouvoir lire une ligne d'entrée du style "tomate oignon 2 carottes 3 poireaux" avec une seule variable…
    
    la sémantique n'a pas une interprétation automagique pour coller à tes besoins non exprimés
    
    C'est peut-être quand même une faiblesse des langages de programmation, non? Et peut-être même des logiciels en général. Souvent, quand on veut concevoir un truc plus intuitif, on peut, et je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
    
    En gros, le problème n'est pas de demander à la machine de choisir entre deux options quand les instructions ne sont pas claires. On est d'accord, c'est quasiment impossible. Le problème est plutôt de concevoir des interfaces souples, qui donnent quelque chose de sensé plutôt qu'une erreur de compilation. Typiquement, les fonctions à arguments facultatifs sont une avancée considérable; mais tous les langages de programmation sont systématiquement truffés d'inutiles lubies psychorigides qui peuvent vraiment rebuter les débutants.
    - [^] # Re: Décalage
      
      Posté par freem le 23 octobre 2014 à 18:05. Évalué à 3.
      
      je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
      
      Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
      D'ailleurs, si j'ai bonne mémoire, le python à justement été créé pour enseigner, car justement le fait d'imposer un coding style permets de faire sauter à l'œil les bugs… ou pas (en fait si, mais c'est plus compliqué que juste prendre en compte les espaces blancs dans le code source…).
      - [^] # Re: Décalage
        
        Posté par arnaudus le 23 octobre 2014 à 18:25. Évalué à 2.
        
        Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
        
        Il existe de nombreux langages où on termine les instructions avec un saut de ligne ET où on peut formatter le code. À commencer par le shell. Quand l'instruction est terminée, on l'exécute, autrement, on continue sur la ligne suivante.
        
        [^] # Re: Décalage
        
        Posté par freem le 24 octobre 2014 à 14:22. Évalué à 5.
        
        C'est vrai qu'on ne peut pas qualifier le shell de psychorigide. En fait, c'est même le contraire, pour faire du shell il vaut mieux ne pas avoir peur du flou artistique.
        Les différences entre les '', les "" deviennent très vite très fun dès que l'on doit utiliser un langage tiers, ce qui est plus que commune avec shell, par exemple lorsque l'on utilise awk.
        
        Je vais pas trop taper sur le shell, cet outil si pratique, mais, il me semblait que l'on parlait dans ce sujet de langages faciles à apprendre. Hors, le shell est bien plus complexe que le C, pour moi. Ok, dans le C, on à la gestion de la mémoire, mais au moins la syntaxe est claire et s'acquiert rapidement. Ça commence à faire quelques temps que j'utilise shell au taf, et même si je ne peux nier qu'il à ses avantages, je pense que si le man était en papier, mon livre de man s'ouvrirait tout seul à, par exemple, la page "test". Ou peut-être à la page "boucles for pour compter" (qui n'existe certes pas).
        
        À choisir entre la "psychorigidité" du C et les trips sous LSD du shell, je n'hésite pas une seule seconde.
        
        Ah, j'oubliais. En C, ton programme il compile ou il compile pas, c'est binaire. En shell, un coup il s'exécute, un coup il s'exécute pas… en fonction des chemins dans le code.
        Du coup, je te rejoins: le ';' c'est pour les psychorigides. Mais l'algorithmique est une science, pas un truc qu'on fait après vidé une infusion de champignons…
        
        [^] # Re: Décalage
        
        Posté par fearan le 24 octobre 2014 à 15:47. Évalué à 2.
        
        "boucles for pour compter" (qui n'existe certes pas).
        
        je dirai que tu as une mauvaise connaissance du shell
        
        for (( i=0 ; i < 5 ; i++ )) do echo $i done 0 1 2 3 4
        
        note bien tu peux aussi utiliser la bonne vieille méthode : for i in $( seq 1 4 )
        
        quant aux ' et ", je n'ai généralement pas de problèmes : soit je veux que mes variables soient interprétées soient je ne veux pas; le shell est devenu d'une simplicité enfantine le jour où j'ai découvert $() à la place de ``; par contre je ne mixe pas du awk et du shell (sauf pour extraire un champ ou les réordonner ), et encore, l'utilisation de read a b c d plop règle bon nombre de problème.
        
        coproc est aussi bien pratique dans certains cas :)
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Décalage
        
        Posté par freem le 24 octobre 2014 à 17:22. Évalué à 4.
        
        je dirai que tu as une mauvaise connaissance du shell
        
        Ton assertion sur ma mauvaise connaissance du shell est vraie, mais je dirais que tu mélanges shell et bash également car:
        
        #!/bin/sh for (( i=0 ; i < 5 ; i++ )) do echo $i done
        
        donne:
        ./test.sh: 2: ./test.sh: Syntax error: Bad for loop variable
        
        note bien tu peux aussi utiliser la bonne vieille méthode : for i in $( seq 1 4 )
        
        Effectivement, j'ai tendance à oublier l'existence de seq (CQFD avec mon mauvais shell;)). Je ne prétends pas être un expert en shell, je ne dirais même pas être de niveau avancé. Je suis sûr que les quelques scripts que je me bricole feraient fuir plus d'un admin chevronné.
        
        par contre je ne mixe pas du awk et du shell
        
        J'ai cité ce problème car je l'ai eu il y à peu sur un usage ponctuel, mais je fais pas mal de scripts pour manipuler du SQL aussi, et là ça devient assez pénible.
        En fait, dès lors que l'on mélange du shell avec un autre langage, ça deviens pénible, j'ai l'impression. (Mais je t'avoue que mélanger les langages est un truc que je préfère habituellement éviter comme la peste)
        
        une simplicité enfantine le jour où j'ai découvert $() à la place de ``;
        
        C'est vrai que c'est une sacrée bouffée d'air pur.
        
        et encore, l'utilisation de read a b c d plop règle bon nombre de problème.
        
        Tu peux détailler un peu? Les connaissances sur le shell sont toujours bonnes à prendre.
        
        coproc est aussi bien pratique dans certains cas :)
        
        Je ne connais pas… Je viens de regarder la doc de bash à son sujet, mais j'ai un peu de mal à voir l'intérêt? (en même temsp, vendredi, gueule de bois qui viens enfin de s'estomper, tout ça… pas au meilleur de ma forme pour découvrir des histoires de pipe redirigés et comprendre l'intérêt xD)
        
        [^] # Re: Décalage
        
        Posté par fearan le 25 octobre 2014 à 13:02. Évalué à 3.
        
        effectivement j'ai tendance à remplacer shell par bash, et j'utilise beaucoup de basheries ;)
        
        Tu peux détailler un peu? Les connaissances sur le shell sont toujours bonnes à prendre.
        
        pour le read je l'utilise souvent de la façon suivante
        
        ps -heo pid,user,nice,pcpu,comm | while read pid user nice pcpu comm do echo "le pid de $comm est $pid il a été lancé par $user (qui est un gros boulet) avec un nice $nice" done
        
        tu peux aussi avoir un nombre de paramètres plus court dans read (dans ce cas le dernier prends le reste)
        
        pour coproc je l'ai utilisé pour éviter de passer par des mkfifo.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Décalage
        
        Posté par freem le 27 octobre 2014 à 11:26. Évalué à 2.
        
        Je t'avoue que j'ai toujours eu une tendance à aimer la portabilité, et souvent se baser sur un standard aide pas mal. Ça explique que je préfère utiliser dash pour les scripts (enfin, /bin/sh, mais sous debian il linke vers dash ;) ce qui est pas plus mal me concernant ).
        
        Ceci dit, pour des one-shot, bash me gêne pas.
        
        [^] # Re: Décalage
        
        Posté par fearan le 27 octobre 2014 à 09:27. Évalué à 2.
        
        pour le for (( ; ; ))je viens de tester sur la machine du boulot, ça passe en ksh, ksh93, bash, /bin/sh (mais c'est un lien sur bash), ça ne passe pas en tcsh ni en dash :)
        
        Parmi mes autre truc que j'aime bien c'est le (expr ) )
        
        i=3
        echo $(( i + 2 ))
        5
        
        sinon pour les seq un peu long il y a aussi le seq 1 10000 | while read i …
        c'est plus passe partout.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # tcsh
        
        Posté par Arthur Accroc le 29 octobre 2014 à 01:27. Évalué à 2.
        
        pour le for (( ; ; ))je viens de tester sur la machine du boulot, ça passe en ksh, ksh93,
        bash, /bin/sh (mais c'est un lien sur bash), ça ne passe pas en tcsh ni en dash :)
        
        Oui, enfin tcsh n’est pas de la famille du Bourne shell mais de la famille de csh… La syntaxe n’a rien à voir (csh est communément appelé C shell, son but était d’avoir une syntaxe proche de celle du C).
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: Décalage
      
      Posté par lolop (site web personnel) le 23 octobre 2014 à 18:50. Évalué à 4.
      
      c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres
      
      Surtout pas. La notion de type est importante à comprendre, les transtypages automatiques de ce genre sont une horreur lorsqu'il faut déboguer.
      
      Perso, en Python, j'aurais même préféré qu'il n'y ait pas de conversion implicite vers/de les booléens (pour l'enseignement du moins — pour programmer je l'apprécie).
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: Décalage
        
        Posté par arnaudus le 23 octobre 2014 à 19:17. Évalué à 7.
        
        Surtout pas. La notion de type est importante à comprendre
        
        La notion de pointeur aussi, l'optimisation aussi… Tout est important, mais l'essentiel est de commencer. Si tu apprends à l'université, tu peux défendre le point de vue d'un théoricien, qui va commencer son cours avec le binaire, le stockage des tableaux en mémoire, le code ASCII, etc. Mais là, on parle d'approche pédagogique : l'objectif, c'est d'aller le plus vite possible vers un code qui fonctionne et qui fait à peu près ce que l'élève souhaite. Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.
        
        Je ne dis pas que c'est facile, il est évident que pour un informaticien, tout est important, l'idée d'oublier volontairement un aspect essentiel comme le typage semble insupportable. Mais pourtant, objectivement, le typage, quand on débute, ça n'a aucune espèce d'importance, parce que c'est indépendant de la logique du code. 42, 42.0, "42", c'est pas grave. Tu vas mettre 10 ans à te former à la programmation, et parmi ces 10 ans, tu passeras 9 ans et 6 mois à faire gaffe aux types. Je pense que ça suffira largement :-)
        
        [^] # Re: Décalage
        
        Posté par lolop (site web personnel) le 23 octobre 2014 à 20:23. Évalué à 7.
        
        Tout n'est pas du même niveau, ils peuvent se passer des pointeurs et de la notion d'adresse mémoire, de l'encodage des fichiers, etc (je passe sur l'optimisation).
        
        Mais "4"+"4" ce n'est pas 4+4. C'est la même notion que les grandeurs en physique, on ne les mélange pas n'importe comment. En algo c'est important de distinguer une valeur numérique, par exemple un compteur, d'une donnée textuelle qui est utilisée par ailleurs.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Décalage
        
        Posté par Maxime (site web personnel) le 23 octobre 2014 à 22:42. Évalué à 5.
        
        En quoi le typage statique permet d'améliorer les choses ? Par exemple en Python tu n'as pas besoin de déclarer explicitement les types mais il y a quand même un type associé :
        
        >>> a = "4" >>> b = 4 >>> a + b Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects
        
        D'un point de vue pédagogique, le message reste le même : « on peut pas additionner une chaîne de caractère avec un entier, on ne mélange pas torchon et serviette ».
        
        Ce qui me dérange c'est plutôt la possibilité pour une variable de changer de type en cours de route. Là ça devrait pas être possible.
        
        [^] # Re: Décalage
        
        Posté par arnaudus le 23 octobre 2014 à 23:29. Évalué à 1.
        
        Ce qui me dérange c'est plutôt la possibilité pour une variable de changer de type en cours de route. Là ça devrait pas être possible.
        
        Pourquoi? Est-ce un argument technique, ou c'est juste parce que c'est (presque) toujours ainsi? Il y a pourtant très peu d'ambiguité. 4+"4", c'est évidemment 8 ; 4."4", c'est "44". Personne ne propose de faire ça en C, mais dans les langages de haut niveau, je ne vois pas le problème. D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?
        
        [^] # Re: Décalage
        
        Posté par Maxime (site web personnel) le 24 octobre 2014 à 08:08. Évalué à 3.
        
        Nous ne parlons pas du tout de la même chose. Ce que je n'aime pas c'est permettre à un étudiant de réutiliser des variables pour faire des choses qui n'ont rien en commun :
        
        >>> a = 42 >>> type(a) <type 'int'> >>> a = "hello" >>> type(a) <type 'str'>
        
        C'est l'une des restrictions de RPython par exemple.
        
        [^] # Re: Décalage
        
        Posté par lolop (site web personnel) le 24 octobre 2014 à 09:03. Évalué à 7.
        
        C'est évident pour nous qui programmons.
        
        Pour des élèves/étudiants dont c'est juste une "option obligatoire qui ne rapporte pas beaucoup de points", le "peu" d'ambiguïté est énorme. Il faut voir ce que l'on retrouve en TPs sur machine…
        
        D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?
        
        Oui. Car on compare des choses qui sont de nature différentes.
        
        Est-ce raisonnable de dire que 2 (bananes) == 2 (carottes) est faux? Il y a pourtant '2' de chaque côté.
        
        La notion de l'existence des types de données, d'opérations sur ces types, et de combinaisons possibles ou non est nécessaire. Les conversions implicites entre données de natures¹ différentes sont franchement mauvaises pour l'apprentissage
        
        ¹ Je parle de 'nature' car, par exemple, 1 + 9.5 combine des données de types différents mais qui sont tous les deux des nombres — le problème de la représentation interne est un problème plus technique (même s'il vaut mieux le voir à un moment).
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Décalage
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2014 à 09:28. Évalué à 3.
        
        Il faut expliquer pourquoi 1 + 8.5 n'est pas si simple. Est-ce que l'on veut 9.5 comme résultat ou 9 en entier ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Décalage
        
        Posté par lolop (site web personnel) le 24 octobre 2014 à 10:03. Évalué à 6.
        
        Pour un étudiant c'est une somme entre deux nombres, il attendra 9.5 (le résultat "mathématique" normal).
        
        Là où je pratique, un truc qui a fait du bien lors du passage au Python3 pour l'enseignement de l'algo, c'est la division / flottante même entre deux entiers. 1/2 c'est 0.5, comme en math. Et si on veut une division entière, on utilise // (% pour le reste).
        La distinction des nombres entre entier et flottant avec juste la présence ou non du point décimal… et le changement de sens de l'opérateur / suivant cela… c'était dur pour certains (ça rentre déjà dans un problème du codage binaire interne - c'est plus de l'algo, c'est de la programmation).
        
        Il faut que l'outil d'apprentissage donne de bonnes pratiques, sans rentrer dans des détails qui font qu'on s'éloigne de l'algorithmique pour aller dans les spécificités d'implémentation du langage.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Décalage
        
        Posté par Nicolas Boulay (site web personnel) le 24 octobre 2014 à 10:04. Évalué à 5.
        
        à ce petit jeu Perl, s'en sort bien.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Décalage
        
        Posté par anaseto le 24 octobre 2014 à 16:42. Évalué à 6.
        
        D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?
        
        Oui. Car on compare des choses qui sont de nature différentes.
        
        En fait moi je me serais attendu à plusieurs choses sauf ça. Soit j'utilise un langage rigoureux comme OCaml et je m'attends à avoir une erreur à la compilation, soit j'utilise un langage typé dynamiquement, et dans ce cas je m'attendrais soit à une exception, soit à obtenir True, mais surtout pas False. Car False ne donne aucune information utile : si ça cache un bug, non seulement on ne s'en rend pas compte immédiatement, mais en plus on obtient un résultat qui probablement est le contraire de ce à quoi on pensait en l'écrivant.
        
        [^] # Re: Décalage
        
        Posté par lolop (site web personnel) le 24 octobre 2014 à 08:54. Évalué à 3.
        
        Je n'ai pas parlé de typage statique, mais de typage tout court. Je pensais à des choses comme:
        
        pointal@soupir:~$ php -a Interactive mode enabled <?php echo(3 + "3"); ?> ^D 6
        
        Pédagogiquement ce genre de comportement est une horreur (je passe sur le == vs === en PHP, s'il faut l'expliquer à des débutants…).
        
        Je suis d'accord avec toi que pouvoir fixer le type d'une variable en Python (par exemple par une option de l'interpréteur) améliorerais probablement la compréhension de ce qui se fait et ce qui ne se fait pas pour des étudiants.
        
        En Python on pourrait même utiliser des module tiers qui permettent d'associer des unités aux valeurs numériques… et de contrôler leurs combinaisons dans les expressions.
        
        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
        
        [^] # Re: Décalage
        
        Posté par rewind (Mastodon) le 24 octobre 2014 à 10:36. Évalué à 9.
        
        Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.
        
        La notion de type est très très loin d'être une notion technique. De nos jours, on a pris conscience que les données sont tout aussi importante que le code qui les manipule. Bien choisir comment représenter ses données, ça fait partie de l'apprentissage de la programmation. Pour moi, apprendre uniquement des structures de contrôles et faire l'impasse sur les types, c'est faire la moitié du boulot. Dans mon univ, on donne un quantité impressionnante d'exercice en première année dans lesquels le choix du bon type est importante pour la résolution du problème. Et je ne parle même pas de structure là, juste entier/flottant/booléen/caractère.
        
        [^] # Re: Décalage
        
        Posté par arnaudus le 24 octobre 2014 à 14:56. Évalué à 4.
        
        La notion de type est très très loin d'être une notion technique.
        
        C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
        
        Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères. Les booléens sont inutiles, parce que dans du code de débutant, ils sont implicites : aucun débutant de va faire "bool ans = a > 2; if (ans) {…}". À l'adolescence, j'ai codé des années sans tilter qu'on pouvait stocker le résultat d'un test dans une variable, et ça ne m'a pas gêné plus que ça.
        
        Il ne faut pas prendre le débutant pour un débile. Quand il fait des cin >> pour lire des données entrées au clavier et les stocker dans des variables, il sait très bien qu'il tape les touches "4" et "2" pour rentrer 42, et que c'est le programme qui les transforme en nombre ou en caractères. Et, contrairement à ce qu'on peut prétendre après 10 ans d'expérience en programmation, ça n'a rien de logique. Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique. La programmation typée crée une différence artificielle entre les deux, et en fonction du langage, le transtypage peut être plus ou moins complexe. Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.
        
        À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible. On demande un password et on n'a pas prévu que l'utilisateur rentre "1234", etc. Mais d'une manière générale, un argument du type "C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque (apprentissage des instruments de musique, par exemple: fais des gammes pendant 3 ans, et après seulement tu auras le droit de jouer un morceau).
        
        [^] # Re: Décalage
        
        Posté par barmic le 24 octobre 2014 à 15:16. Évalué à 6.
        
        La notion de type est très très loin d'être une notion technique.
        
        C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
        
        Je pense que vous avez tous les deux raison. Autant oui quand en C tu utilise des types comme unit32 ça n'est rien d'autres que technique, autant quand tu utilise des langages comme haskell tu encode une bonne partie de ton problème dans les types de données.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Décalage
        
        Posté par Anthony Jaguenaud le 24 octobre 2014 à 15:21. Évalué à 4.
        
        Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.
        
        Bah, la différence, c’est que ta variable est var :
        $var \in \mathbb{R}$ est différent de $var \in \mathbb{N}$ ou plutôt $var \in \mathbb{Z}$ .
        
        Et expliquer : « L’ordinateur est un peu stupide, il ne sait pas additionner un nombre de $\mathbb{R}$ avec un nombre de $\mathbb{Z}$ … ». Les élèves comprennent. Àmha.
        
        [^] # Re: Décalage
        
        Posté par arnaudus le 24 octobre 2014 à 16:43. Évalué à 9. Dernière modification le 24 octobre 2014 à 16:47.
        
        Les élèves comprennent.
        
        Ils sont à polytechnique, tes élèves? :-) Je doute que beaucoup d'élèves de terminale, même scientifique, pigent le coup de R et Z.
        
        Le problème de fond, c'est que c'est faux de dire que l'ordinateur ne sait pas faire. La vérité, c'est que le langage demande parfois une conversion explicite, qui est une étape pénible due à la complexité du stockage des données numériques par un ordinateur. Cette complexité ne pourra pas être cachée éternellement, mais elle n'est absolument pas nécessaire à l'apprentissage de la programmation, surtout quand on parle d'approche ludique ou intuitive.
        
        J'ai l'impression que l'idée, c'est de réduire la taille de la marche intiale, celle qu'il faut escalader pour faire son premier programme, comprendre comment programmer un ordinateur permet de répondre à des besoins. Quand on écoute ce que raconte un informaticien à un public de débutant, on se demande comment il apprendrait à conduire à quelqu'un :
        
        OK, donc là, tu rentres dans le véhicule, et tu vois tout de suite en bas l'allume-cigare. À côté de l'allume-cigare, il y a les boutons pour ouvrir les vitres (mais ces boutons ne sont pas tout le temps à la même place entre les différentes marques de voiture). Là c'est l'autoradio, les boutons sont en anglais, je vais te les traduire parce que sinon tu ne pourras pas conduire : "Vol" c'est le volume, "Stat 1" c'est la première station, etc. Je t'ai collé des post-its partout. Tiens, plus bas, il y a la pédale d'embrayage. Elle est connectée à un cable, qui arrive à un dispositif constitué d'une butée et d'un disque, qui va frotter sur le volant moteur. Quand tu tires sur le cable, ça déconnecte le disque et le volant moteur. Il faudra faire ça quand tu passeras les vitesses, mais on parlera des vitesses plus tard. Là pour le moment, tu as quand même compris le coup du cable? Non, parce que le cable, c'est comme ça sur tous les modèles. Sauf sur ceux qui ont des vitesses automatiques. C'est beaucoup plus facile et je n'aurais pas eu besoin de t'expliquer tout ça, mais c'est moins pédagogique, tu comprends? De toutes manières, les automatiques ont aussi des boutons pour remonter les vitres. Je t'ai dit que l'allume-cigare servait à brancher des trucs électriques? Non non, on ne peut pas y mettre des clopes. Il est branché sur la batterie. En fait, il y a des gens qui s'en servent pour allumer des clopes, mais ça ne sert pas à ça normalement.
        
        [^] # Re: Décalage
        
        Posté par feth le 24 octobre 2014 à 17:28. Évalué à 1.
        
        Je ne suis pas tout à fait d'accord avec toi, mais j'ai ri, c'est très bien écrit !
        Et tout comme faire rire aide à faire passer ton propos, jouer est un moyen de s'approprier outils et concepts.
        
        Je ne suis pas très versé dans la pédagogie, surtout à l'égard d'adolescents… mais spontanément j'aurais assez vite montré comment un objet implémente une opération comme l'addition avec un autre objet. Oui c'est un détail d'implémentation, oui c'est spécifique aux langages objets… mais je crois que c'est un moyen d'introduire une dimension ludique : plus qu'un détail, ce qu'il y a sous le capot est un choix d'implémentation, et on peut en faire d'autres qui donnent des résultats amusants.
        L'aspect «tout est objet et on peut tout introspecter» de Python, par exemple, en fait un outil très ludique, je l'ai constaté chez plusieurs personnes qui du coup s'approprient facilement les outils. Et si on ne développe pas avec un langage de haut niveau, ce qu'il y a sous le capot c'est la représentation binaire, les opérateurs de base.
        
        PS : Rien à voir, mais comme j'ai une mauvaise connexion, je l'écris ici : je déteste l'idée d'enseigner avec un outil qui ferait croire qu'un caractère c'est un octet car certes c'est confortable, mais le réflexe acquis semble difficile à perdre. Les chaînes de caractères, ça se manipule avec des bibliothèques et c'est tout (sauf si on enseigne le codage des caractères) !
        
        [^] # Re: Décalage
        
        Posté par freem le 24 octobre 2014 à 17:32. Évalué à 3. Dernière modification le 24 octobre 2014 à 17:34.
        
        Quand on écoute ce que raconte un informaticien à un public de débutant, on se demande comment il apprendrait à conduire à quelqu'un :
        
        Perso, j'ai une solution pour éviter ça: j'évite autant que faire se peut de parler d'informatique. Et quand on me pose explicitement une question, que je ne peux pas esquiver, je m'arrange pour donner le moins d'info possible.
        C'est pas que je veux pas, mais le souci c'est qu'on s'aperçoit que de toute façon ça va souler l'autre, qui n'en à rien à foutre.
        Au final, quand ils demandent "pourquoi", il demandent une réponse type "ohla, c'est compliqué mais t'inquiètes, je gère", qui leur permets de se dédouaner de devoir cogiter et mettre les mains dans l'informagique…
        Bien entendu, on va me rétorquer que, tout le monde est pas obligé, blabla connaître l'ordi, blabla… sauf que quand c'est le mécano, il va pas se priver de t'emmerder avec ses histoires de delco, par exemple. Même qu'en général ça m'intéresse et je repose des questions, et pourtant j'ai pas l'intention de devenir mécano… (juste un exemple hein)
        
        Je dirais surtout au final, que les informaticiens sont encore un peu vus comme des sorciers, et qu'il est tellement plus simple de se dédouaner de ses conneries en disant "ouai, mais tu comprends, ça marche jamais comme il faut, j'ai rien installé et maintenant c'est super lent! En plus sur les sites ils me disent que mon windows est pas en sécurité et qu'il faut cliquer sur la bannière. D'ailleurs l'autre jour ma banque m'a envoyé un mail, mais c'était bizarre, y'avais pleins de fautes. Enfin, je leur ai envoyé mon code de CB comme ils demandaient, c'était urgent…".
        Bon, j'exagère: le passage "mais c'était bizarre, y'avais pleins de faute" est fictif et irréaliste.
        
        Maintenant, dans la pratique, j'ai déjà expliqué le fonctionnement d'un diagramme de classe qui décrivait un soft qui utilisais une mécanique de plug-in à quelqu'un, qui était un minimum curieuse et dotée de raison.
        Cette personne (adulte, certes) semblait avoir compris… en même temps, la POO + l'UML, ça aide considérablement à expliquer ce qu'un programme fait et comment il le fait. Bien plus que l'algorithmique.
        
        [^] # Re: Décalage
        
        Posté par Zylabon le 24 octobre 2014 à 17:16. Évalué à 9. Dernière modification le 24 octobre 2014 à 17:17.
        
        C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
        
        Non… Les types sont présents dans la nature, si tu mélange de la purée et du jus de pomme, aucune chance que ça fasse de la purée, ni du jus de pomme, ni un mouton.
        
        De la même manière, l'expression 3 + "foo", si aucun langage décent de l'autorise, c'est pas à cause d'une restriction arbitraire lié au codage des valeurs en mémoire, c'est parce que ça n'a aucun sens, et qu'un programme qui voudrait effectuer cette opération n'aurait aucune chance d'être correct, donc autant le rejeter simplement.
        
        Please do not feed the trolls
        
        [^] # Re: Décalage
        
        Posté par freem le 24 octobre 2014 à 17:41. Évalué à 4. Dernière modification le 24 octobre 2014 à 17:42.
        
        c'est pas à cause d'une restriction arbitraire lié au codage
        
        La preuve, on peut surcharger les opérateurs dans certains langages, et la conséquence directe est qu'il est possible de faire que 3 + "foo" fasse "3foo". Certains le font d'ailleurs, et ça donne des choses très drôles. (c'est assez court, mais pour les flemmards: à partir d'1:35 ça commence à parler de ce genre de joyeusetés. Surtout au sujet de JS pour le coup…)
        
        NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman!
        
        [^] # Re: Décalage
        
        Posté par rewind (Mastodon) le 24 octobre 2014 à 17:50. Évalué à 9.
        
        C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
        
        Malheureusement, on ne code pas encore sur des pizzas mais sur des ordinateurs, donc savoir ce qu'est capable de faire un ordinateur pour lui donner les bonnes instructions, c'est ça la programmation.
        
        Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères.
        
        Je vais te donner un problème simple : tu as un tonneau de x litres et des bouteilles de y litres, combien de bouteilles te faut-il pour vider le tonneau ? Et bien si tu ne sais pas si ton nombre est un entier ou un flottant, tu pourrais très bien ne pas savoir résoudre ce problème.
        
        Il ne faut pas prendre le débutant pour un débile.
        
        Ce n'est pas mon cas, moi je veux lui apprendre les types et la manière de les choisir pour résoudre un problème, pas lui faire croire que tout est pareil et que l'ordinateur va bien se débrouiller pour comprendre ce qu'il a voulu dire. Il y a un exercice classique qu'on donne en première année, c'est la calculatrice : il faut rentrer deux nombres (donc deux variables, mettons a et b) et un opérateur (qu'on stocke dans un caractère qu'on appelle op). Et bien c'est généralement là qu'on voit ceux qui ont compris et ceux qui restent à «l'ordinateur doit comprendre ce que je lui dit». Ces derniers écrivent : res = a op b qui n'a absolument aucun sens. Et qui est du même acabit que 4 + "4" à mon avis. Et souvent, même quand on leur a expliqué, ils ont du mal à comprendre pourquoi ça ne marche pas.
        
        C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.
        
        Absolument pas. Voir mon problème simple ci-dessus avec les bouteilles. C'est fondamentalement différent, même sans aller jusqu'à parler des limites des entiers ou des floats.
        
        Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.
        
        J'insiste, un programme, ce n'est pas qu'une «logique», c'est également un choix adéquat de types et de structures de données et ce n'est pas une nouveauté !
        
        À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible.
        
        Ce ne sont pas des ambiguïtés, c'est une manière erronée d'apprendre les choses. Ça va beaucoup mieux dans le sens inverse : quand on a compris les types, on sait mieux utiliser les langages faiblement typés.
        
        "C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque
        
        Premièrement, ce n'est pas compliqué, c'est même plutôt naturel. Deuxièmement, ça a des applications très concrètes et très rapidement, aucun argument d'autorité derrière. On peut montrer que c'est utile (et j'ai donné deux exemples qui montrent que ça a du sens comparé à une approche trop empirique !) et que ça ne gêne personne, au contraire, ça permet d'avoir une meilleure maîtrise de ce qu'on fait.
        
        [^] # Re: Décalage
        
        Posté par Pierre Jarillon (site web personnel) le 25 octobre 2014 à 22:26. Évalué à 9.
        
        Je suis partisan du typage fort. Le jour où le Fortran de HP a inclus «implicit none», j'ai imposé cette instruction dans mon service. Ce fut un gain de temps important car il vaut mieux détecter une erreur à la compilation plutôt qu'à l'exécution.
        L'exemple bien connu de la sonde perdue car un point avait remplacé la virgule en est un bon exemple. Il montre que le type est une caractéristique essentielle des variables : http://fr.wikipedia.org/wiki/Mariner_1
        
        [^] # Re: Décalage
        
        Posté par freem le 27 octobre 2014 à 11:33. Évalué à 4.
        
        J'ai envie de dire que tous ceux étant passés par une STI quelconque devraient être d'accord avec toi: que ce soit en électricité ou en mécanique, le typage des résultats à été la cause de pas mal de points perdus, ou gagnés (parce qu'en fonction des types et des ordres de grandeurs, ou pouvait repérer certaines erreurs dans les ~~algo~~ raisonnements utilisés…).
        
        En tout cas, perso, je ne peux qu'être d'accord avec toi: pour passer d'un type à un autre, passer par une fonction spécifique est une excellente chose. Il m'arrive même de penser que C++ est trop laxiste par moments (il permets toujours les cast implicites, notamment de short vers char, même s'il est possible de demander au compilo d'avertir puis de transformer ce warn en erreur)… alors qu'il l'est nettement moins que le C.
        Que ça oblige à la rigueur n'est pas un problème, mais un avantage, parce que les ordinateurs ne sont, jusqu'à preuve du contraire, pas des être dotés de raison/sens artistique, donc quand on leur "parle" il est évident qu'il faut être rigoureux.
        
        [^] # Re: Décalage
        
        Posté par croux le 25 octobre 2014 à 00:47. Évalué à 10. Dernière modification le 25 octobre 2014 à 00:48.
        
        Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques.
        
        Si cela était vrai alors "00042" serait tout aussi identique à "42", ce qui ne se peut pas. La taille de la chaîne utilisée porte une information qui n'apparaît pas dans le nombre 42. Un digicode sait justement faire la distinction.
    - [^] # Re: Décalage
      
      Posté par ProfGra (site web personnel) le 27 octobre 2014 à 21:49. Évalué à 2.
      
      Bon bah finalement, on est quasi d’accord ! Sauf au niveau des types.
      
      Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. […]
      
      Je pense que ça a un impact minimal sur le design du langage. Ce qu’il faut, c’est que le prof ou formateur construise du contenu. C’est pour ça que MicroAlg est bidouillable (pour que les profs puissent l’intégrer à leur travail) et que j’ai installé une galerie (si les profs n’ont pas les compétences).
      
      Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. […]
      
      Oui, quand on prototype, c’est lourd, mais quand il s’agit de sécurité, un typage statique peut sauver des vies. Là on parle pédagogie, et je pense que dans ce contexte, il faut typer.
      
      Pour la «convivialité de l’interface (visuelle ou la qualité des messages d’erreurs), on est tout à fait d’accord.
      
      Et finalement, je ne comprends pas du tout l’histoire d’une programmation molle mais dure.
      
      Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Décalage
    
    Posté par ProfGra (site web personnel) le 27 octobre 2014 à 19:25. Évalué à 1.
    
    Globalement d'accord sur le fond du commentaire. […]
    
    Bizarre, j’ai l’impression d’être en total désaccord avec arnaudus (voire être totalement descendu en flammes par arnaunus) tout en me sentant proche de ton commentaire.
    
    […] Les étudiants ne butent pas trop sur les points-virgule. C'est assez systématique pour ne pas les gêner.
    
    D’accord je suis. Ce qui est difficile pour les débutants, c’est de passer sans arrêt d’un langage «avec ;» à un langage «sans ;». Là-dessus, dans mon lycée, et avant MicroAlg, on a pu être totalement sadiques.
    
    […] et se retrouvent à débugger des programmes où ils affectent des poires dans des lapins. […]
    
    En forçant un peu, ça doit qd même pouvoir rentrer. Mauvais exemple.
    
    Plus généralement, la rigueur, ce n'est pas une discipline ou un savoir faire, c'est d'abord une façon de penser. Beaucoup d'étudiants sont "intentionistes": la "machine" (l'interpréteur de commandes ou de script, le compilateur…) doit s'adapter à moi et comprendre ce que je souhaite parce qu'après tout, mon intention en pseudo-français est indiquée dans le programme. Et beaucoup de dépassent jamais ce stade.
    Au contraire, la première chose à comprendre, c'est que c'est à l'humain d'adopter une syntaxe précise et que la sémantique n'a pas une interprétation automagique pour coller à tes besoins non exprimés
    
    Waou, tu devrais écrire des bouquins de péda informatique !
    Je peux te piquer tes phrases pour les replacer ? (c’est même pas une blague ! peut-être pas telles quelles, mais rephrasées au moins)
    
    (hormis peut-être la PLC et encore…).
    
    Je ne comprends pas. Parle-t-on d’automatique ici ? C’est juste un petit troll tout mignon ?
    
    […] on s'est retrouvé avec une partie des étudiants incapables de gérer plus d'un niveau de boucle, ou de coder une couche métier.
    
    Tu enseignes où et quoi si ce n’est pas indiscret ?
    Pour les niveaux de boucle, c’est assez haut comme marche, je sais que je dois y passer du temps. C’est vraiment un cours spécifique sur les tableaux de dimension au moins 2.
    
    Toujours dans les trucs bizarre, il y a des jeunots super doués pour assembler par copié/collé des bouts de code en un ensemble à peu près fonctionnel mais qu'ils ne comprennent vraiment pas!
    
    C’est ce que j’appelle le «vaudou-ing», tiré d’une discussion entre élèves.
    
    Bien le merci pour ton commentaire !
    
    Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
    - [^] # Culte du cargo
      
      Posté par Arthur Accroc le 27 octobre 2014 à 20:07. Évalué à 3. Dernière modification le 27 octobre 2014 à 20:08.
      
      Toujours dans les trucs bizarre, il y a des jeunots super doués pour assembler par copié/collé des bouts de code en un ensemble à peu près fonctionnel mais qu'ils ne comprennent vraiment pas!
      
      C’est ce que j’appelle le «vaudou-ing», tiré d’une discussion entre élèves.
      
      Il y a déjà une expression pour ça : le culte du cargo (voir le début de l’article pour comprendre la référence, assez savoureuse).
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Décalage
  
  Posté par Maxime (site web personnel) le 23 octobre 2014 à 19:02. Évalué à 9.
  
  Pour abonder en ton sens : j'ai personnellement appris la programmation avec le basic avant d'apprendre l'anglais. Et ce n'était pas un vrai problème. Alors bien sûr, ça donnait par exemple phonétiquement "elzé" pour "else" et je ne savais pas que c'était simplement le mot anglais pour "sinon", mais en dehors de ça, pas de problème pour l'utiliser.
  
  Tout au plus ça peut jouer sur la facilité pour retenir certains mots clefs. Mais lorsqu'il n'y a pas 10 mots clefs différents à retenir, ça reste raisonnable.
- [^] # Re: Décalage
  
  Posté par palm123 (site web personnel) le 24 octobre 2014 à 08:42. Évalué à 4.
  
  On a déja vu passer de nombreuses tentatives de traduction de langages informatiques,
  
  J'ai bossé à une époque en LEM, un Cobol en français. Je crois que c'est porté disparu
  :-)
  
  ウィズコロナ
- [^] # Re: Décalage
  
  Posté par ProfGra (site web personnel) le 24 octobre 2014 à 08:43. Évalué à 6.
  Bonjour, merci pour ton commentaire.
  
  Si je devais enseigner la programmation à un vrai débutant dans de bonnes conditions […]
  
  Je commence par là, je reviendrai au début après.
  
  Je me suis dit en lisant les différents commentaires de cette dépêche : « Tiens, ça serait intéressant de connaître, disons en années scolaires, l’expérience dans l’enseignement de l’algo ou la programmation des gens que je lis ».
  Du coup cette petite phrase est intéressante:
  - soit tu n’as pas d’expérience dans le domaine,
  - soit tu en as et tu me dis ce que tu as utilisé.
  Je reprends tout.
  
  On a déja vu passer de nombreuses tentatives de traduction de langages informatiques, et, personnellement, je n'en ai jamais compris l'intérêt.
  
  L’objectif est ici purement pédagogique. Je ne cherche pas à faire un langage utilisable en production. Si on est d’accord là-dessus, j’attends tes propositions de langages. J’insiste aussi sur le fait que MicroAlg n’est pas qu’une traduction en français.
  
  Ça semble partir de l'hypothèse que les langages existants sont en anglais, et que cela pourrait constituer une barrière à l'apprentissage.
  
  C’en est une, et ce n’est pas qu’une hypothèse, je l’ai vécu. En tout cas au niveau où j’ai enseigné (de la seconde à bac+2), et j’imagine que c’est pire chez les plus jeunes.
  
  Or, d'après mon expérience, c'est complètement faux.
  
  Tant mieux pour toi, mais d’autres rencontrent des problèmes. On parle d’enseignement ici ?
  
  D'une part, les langages informatique ne sont pas en anglais (seuls quelques mot-clé, souvent très rares, le sont),
  
  Ça c’est moyennement vrai (ce qui veut dire que ce n’est pas totalement faux !). C’est vrai que dans un langage objet, une fois qu’on connaît class et disons def, on peut taper beaucoup de français. Mais quand on fait des petits algos tout simples, les mot-clefs apparaissent plus souvent.
  
  et d'autre part, la barrière à l'apprentissage est la logique de la programmation, et pas la syntaxe […]
  
  J’irai même plus loin : ce que je cherche à enseigner, c’est uniquement la logique de la programmation, et pas la syntaxe. Sauf que les élèves butent sur la syntaxe, c’est inévitable, et ça les ralentit, voire les décourage.
  
  Ce qui est compliqué, c'est de comprendre le fonctionnement d'une boucle "for", ça n'est pas de piger que "for" veut dire "pour" […] et dans tous les cas, il est strictement impossible de comprendre intuitivement comment les utiliser.
  
  Très vrai. Mais il ne faut pas me lancer sur les boucles POUR et sur l’intuitif. Tiens, comme je prends goût aux dépêches sur linuxfr.org, j’en ferai une à ce sujet…
  
  Pour le dernier paragraphe, je suis à la fois d’accord avec l’idée générale, et pas d’accord avec des points de détails. Je pense que ça suffit pour l’instant.
  
  Encore merci pour ton commentaire.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Décalage
    
    Posté par vpo le 24 octobre 2014 à 14:05. Évalué à 6.
    
    Ça semble partir de l'hypothèse que les langages existants sont en anglais, et que cela pourrait constituer une barrière à l'apprentissage.
    
    C’en est une, et ce n’est pas qu’une hypothèse, je l’ai vécu. En tout cas au niveau où j’ai enseigné (de la seconde à bac+2), et j’imagine que c’est pire chez les plus jeunes.
    
    Or, d'après mon expérience, c'est complètement faux.
    
    Tant mieux pour toi, mais d’autres rencontrent des problèmes. On parle d’enseignement ici ?
    
    Ma fille qui devait avoir 7 ans à l'époque me disait que cela devait être dur la programmation.
    Je lui ai fait en 2 minutes le programme tarte à la crème qui demande le nom et l'année de naissance pour afficher 'bonjour tartampion tu as donc X ans'.
    C'était du python.
    
    Je rejoints Leslie dans son commentaire du 23/10/14 à 22:08, je pense que faire à ma fille un programme de PGCD l'aurait fait fuir.
    
    En gros, je lui ai montré en quelques minutes ce que j'avais appris à son âge en primaire sur un MO5 ou un TO7/70 en basic. J'avais été émerveillé de pouvoir faire faire cela à une machine en si peut de temps.
    
    Je me souviens très bien de mes premiers cours avec la directrice de mon école primaire (qui devait avoir déjà à l'époque la bonne cinquantaine dans les années 80 : elle avait appris l'informatique quelques mois avant nous je suppose :-) ) nous expliquer ce qu'était un BIT, un octet, la RAM, la ROM et ensuite embrayer sur SCREEN, INPUT, PRINT. Nous ne savions absolument pas ce que cela voulait dire en anglais. Et finalement ce n'était pas plus mal.
    
    Il s'agissait de mots clés. Cela aurait pu être FRAMBOISE, DROMADAIRE ou même BLYUIOP, ce n'était pas un problème. Un mot-clé = une opération à faire. Qu'importe le flacon pourvu qu'on ait l'ivresse…
    
    Je me souviens même que l'un de nous avait dit un truc du genre "il paraît que connaître l'anglais c'est mieux pour faire de l'informatique". Et que l'instit avait dit "Non, ce n'est pas ça l'important.".
    
    En classe, nous avions appris à poser des additions du type 1 + 2 = 3.
    Utiliser (+,1,2) pour faire 1 + 2, ça par contre, je ne suis pas certains que nous aurions compris.
    
    Finalement, lorsque le public est très jeune, il ne va peut être pas du tout s'attacher au sens possible des mots clés du langage là où un public plus âgé va tenter de se raccrocher aux branches en cherchant la solution au problème en examinant les mots clés plutôt que de réfléchir à l’algorithme. Enfin c'est une supposition en lisant les interventions des uns et des autres et en me fiant à ma propre expérience.
    - [^] # Re: Décalage
      
      Posté par arnaudus le 24 octobre 2014 à 14:40. Évalué à 2.
      
      En fait, je me demande même si des enfants de moins de 10 ans comprennent les structures logiques du langage courant. Est-ce que pour un gamin, la différence entre "tant que" et "jusqu'à" est très nette? Du coup, utiliser des mot-clés qui ne veulent rien dire pour eux n'est peut-être pas plus mal, on n'est pas pollués par une compréhension approximative des concepts en français.
      
      Je n'ai jamais compris pourquoi le premier cours de programmation était toujours dédié aux structures de contrôle. Il y en a plein qui ne sont presque jamais utilisées (while, do…until, etc), et elles sont presque toutes redondantes.
      - [^] # Re: Décalage
        
        Posté par Maxime (site web personnel) le 25 octobre 2014 à 21:08. Évalué à 5.
        
        Est-ce que pour un gamin, la différence entre "tant que" et "jusqu'à" est très nette?
        
        Je crois que tu sous-estimes trop les enfants.
        
        [^] # Re: Décalage
        
        Posté par freem le 27 octobre 2014 à 11:34. Évalué à 1.
        
        La preuve: tant que tu ne lui mets pas de claque, il ne sait pas qu'il à fait une connerie, jusqu'a ce que tu lui en mettes une :p
- [^] # Re: Décalage
  
  Posté par ord le 24 octobre 2014 à 10:44. Évalué à 3.
  
  Je pensais pareil que le GUI est important mais j'en suis plus aussi sure. Mon etude de grande envergure( med 3 gamins) semble montrer que en fait le texte c'est plus facile et plus rigolo:
  myvar = "papa"
  print(myvar, " est tres bete")
  output: papa est tres bete
  
  Tres rigolo !
  
  et apres on peut faire des loop, envoyer un mail, etc
  - [^] # Re: Décalage
    
    Posté par arnaudus le 24 octobre 2014 à 11:03. Évalué à 5.
    
    et apres on peut faire des loop, envoyer un mail, etc
    
    … envoyer 10000 mails à la seconde en combinant les deux… :-)
  - [^] # Re: Décalage
    
    Posté par freem le 24 octobre 2014 à 14:15. Évalué à 4.
    
    D'ailleurs, je pense ne pas être le seul à avoir tapé mes premières lignes sur une calculatrice, et c'était pas en mode "graphique".
    Le programme que tu décrit me rappelle très clairement mes premiers…hum… programmes… pourtant j'étais "déjà" en seconde… (même si le contenu des programmes n'était pas dans le même genre d'humour que ce que tu décris, l'algo devait être assez proche :) )
    Ensuite j'ai codé sur PC avec qbasic, encore une fois le mode texte était mon préféré (en fait, j'utilisais beaucoup de semi-graphique), et si j'avais eu à passer par du gtk, qt, ou je ne sais quoi, je ne pense pas que j'aurai persévéré. Avant de vouloir des choses belles, on veut d'abord un truc facile à faire et manipuler, et pour ça, y'a pas mieux que les bons vieux terminaux (un coup de locate, un coup de color, et un coup de print, et voila, c'est joli :) ).
# Linotte

Posté par barmic le 23 octobre 2014 à 14:21. Évalué à 7.

Connaissais tu linotte ? L'objectif me semble proche (je ne sais pas s'il est disponible par un navigateur par contre).

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Linotte
  
  Posté par pamputt le 23 octobre 2014 à 14:29. Évalué à 3.
  
  Il y a d'ailleurs eu plusieurs dépêches/journaux à son sujet sur linuxfr.
- [^] # Re: Linotte
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 19:01. Évalué à 1.
  
  Bonjour,
  Oui je connaissais Linotte, mais je n’ai pas approfondi. Merci de me le remettre sous le nez, je vais aller y piquer des idées !
  Merci pour ton commentaire.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
# Programmation visuelle

Posté par Anthony Jaguenaud le 23 octobre 2014 à 14:25. Évalué à 5.

Je rejoins ceux qui disent que les fonctions préfixés nuisent à la compréhension. Un langage plus proche du langage naturel me semble mieux.

Néanmoins, il y a vers la fin de la page principale un système de boite permettant de faire de la programmation visuelle, un peu comme dans scratch. Je trouve ça pédagogique, quelqu’un sait-il si ça existe pour d’autre langage ?
- [^] # Re: Programmation visuelle
  
  Posté par davandg le 23 octobre 2014 à 14:46. Évalué à 5.
  
  Pour rebondir la dessus, je connais quelqu'un qui apprend la programmation à des collégiens québécois grâce à scratch. En un semestre, ils créent un jeu de plateforme.
  
  Les "puristes" trouvent scratch (et semblable) trop abstrait et haut niveau mais tout les principes de bases y sont (condition, boucle et fonction). De plus, les élèves obtiennent très rapidement des programmes qui vont les intéresser.
- [^] # Re: Programmation visuelle
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 19:12. Évalué à 3.
  
  Bonjour,
  
  Je rejoins ceux qui disent que les fonctions préfixés nuisent à la compréhension. Un langage plus proche du langage naturel me semble mieux.
  
  Vendredi dernier, j’ai vu quelque chose de très intéressant, basé sur l’indentation, qui ressemble à ce que tu évoques. Mais le domaine d’application restait très limité. Si on veut atteindre quelque chose de généraliste, ça peut vite devenir casse-tête et contraignant au niveau des règles, notamment quand on imbrique des conditionnelles et des boucles. Les parenthèses permettent de disposer le code comme on veut (même si j’impose à mes étudiants un genre de PEP8, ou guide de formattage).
  Après, le préfixé est pour moi une vue directe sur l’arbre que représente le programme.
  
  Néanmoins, il y a vers la fin de la page principale un système de boite permettant de faire de la programmation visuelle, un peu comme dans scratch. Je trouve ça pédagogique,
  
  Merci ! C’est très encourageant !
  
  quelqu’un sait-il si ça existe pour d’autres langages ?
  
  Oui, Blockly peut générer du Python, du JS et du Dart. Et si tu t’y connais en JS, tu peux coder ton propre générateur. Voire créer des blocs totalement persos.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
# Langage en français ?

Posté par Leslie Basmid le 23 octobre 2014 à 15:10. Évalué à 6.

MicroAlg est un langage de programmation en « français »

Vraiment ? Sur le programme donné en exemple, rentrer "a" (la lettre) à la question posée produit:

Rien—Number expected

Pas terrible comme exemple de français…

Je remarque au passage que rentrer "0x0A" ou tout autre nombre en hexadécimal ne semble pas poser de problème… Quoi que…

0x0A -> Tu es mineur, mais tu peux continuer sur le site.
0x20 -> Tu es mineur, mais tu peux continuer sur le site.

Hum… ça ne semble pas très bien interprété ça…

Passé la première étape de je joue avec le truc, j'avoue que comme d'autres ici je suis moyennement emballé par la syntaxe en expression symbolique façon LISP. La marche me semble vraiment très ardue pour les débutants qui vont intuitivement penser:
"si le nombre entré est supérieur à 18" plutôt qu'une comparaison pré-fixée.

Il est certain que la syntaxe du LISP a des avantages, a une certaine forme d'élégance, etc. on se laisse souvent enchanter, ou devrais-je dire "happer". Mais cette élégance est-elle accessible au niveau des personnes visées par ce langage: les très grands débutants ? Peut-on leur mettre des calculatrices qui ne comprennent pas "2 + 2" mais sur lesquelles ils faut taper "+ 2 2" ? Parce que quand même, c'est vraiment plus joli "+ 2 2", conceptuellement, la machine de Turing, tout ça… J'ai mon avis sur la question, et il est (très) négatif.
- [^] # Re: Langage en français ?
  
  Posté par CrEv (site web personnel) le 23 octobre 2014 à 15:41. Évalué à 10.
  
  des calculatrices qui ne comprennent pas "2 + 2" mais sur lesquelles ils faut taper "+ 2 2"
  
  Mieux vaut une bonne HP 4x sur laquelle on entre 2 2 + ;-)
- [^] # Re: Langage en français ?
  
  Posté par jeberger (site web personnel) le 23 octobre 2014 à 19:17. Évalué à 3.
  
  Peut-on leur mettre des calculatrices qui ne comprennent pas "2 + 2" mais sur lesquelles ils faut taper "+ 2 2" ? Parce que quand même, c'est vraiment plus joli "+ 2 2"
  
  Perso, j'ai appris à utiliser une calculatrice sur une HP-12C, donc "2 2 +", et ça ne m'a posé aucun problème.
- [^] # Re: Langage en français ?
  
  Posté par ProfGra (site web personnel) le 23 octobre 2014 à 19:31. Évalué à 2.
  Bonjour, merci pour ton commentaire.
  
  MicroAlg est un langage de programmation en « français »
  
  Vraiment ? Sur le programme donné en exemple, rentrer "a" (la lettre) à la question posée produit:
  
  Rien—Number expected
  
  Pas terrible comme exemple de français…
  
  Vrai. Ça fait partie des limitations. C’est pour bientôt, j’espère début 2015.
  
  […] je suis moyennement emballé par la syntaxe en expression symbolique façon LISP. La marche me semble vraiment très ardue pour les débutants […]
  
  Ils s’en sortent pourtant. C’est vrai que ce n’est pas du tout immédiat pour certains, mais un fois que ça roule, je pense que les bénéfices en valent la peine (consistance du langage, vue sur l’arbre des instructions…).
  
  Dans le tuto, je suis partagé entre :
  - travailler tout de suite sur du texte pour ne pas que ça ait l’air trop matheux,
  - travailler tout de suite sur les calculs en prefixé, pour ancrer la syntaxe directement.
  Je pense que je vais finir par faire deux tutos, ou un tuto arborescent avec plein de petites pages.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Langage en français ?
    
    Posté par Leslie Basmid le 23 octobre 2014 à 22:08. Évalué à 2.
    
    Ils s’en sortent pourtant. C’est vrai que ce n’est pas du tout immédiat pour certains, mais un fois que ça roule, je pense que les bénéfices en valent la peine (consistance du langage, vue sur l’arbre des instructions…).
    
    Je pense que c'est sur cet aspect que tu vas rencontrer le plus de réticences. Comme je le disais, je reconnais à LISP (et consorts) une élégance tout à fait agréable. Maintenant, je n'aime pas ce langage, c'est une opinion tout à fait personnelle qui repose notamment sur ce modèle d'arbre d'instructions que je trouve difficile à utiliser convenablement: il est masqué par les langages comme le C, et de toute façon complètement cassé par les processeurs modernes qui ré-ordonnent les instructions à la volée. Je ne suis pas certaine du tout que faire découvrir l'informatique et l'algorithmique par la construction de tels arbres apporte un bénéfice: le modèle a ses vertus, dans certains cas j'ai été contente de l'avoir dans mes bagages, mais je l'utilise finalement assez peu et pour des cas très particuliers. En conclusion je pense qu'il est important de l'avoir dans sa besace d'ingénieur, mais pas nécessaire à l'apprentissage de l'informatique.
    
    Dans le tuto, je suis partagé entre :
    travailler tout de suite sur du texte pour ne pas que ça ait l’air trop matheux,
    travailler tout de suite sur les calculs en prefixé, pour ancrer la syntaxe directement.
    Je pense que je vais finir par faire deux tutos, ou un tuto arborescent avec plein de petites pages.
    
    C'est une excellente question. L'aspect très mathématique présent dans l'informatique rebute les personnes qui aiment "bidouiller" sur leur windows mais qui ont été catégorisés "nuls en maths". J'ai eu l'occasion de le constater à plusieurs reprises. Si les premières expérimentation en programmation commencent par des algorithmes de calcul de PGCD, cela détournera une partie des élèves, ce n'est pas nécessairement souhaitable.
    
    Pour intéresser les élèves, faire faire un jeu peut être une bonne première approche. Aussi bête que soit le jeu (pile ou face, deviner un nombre, …), et cela permet d'éviter de commencer par des notions compliquées d'arithmétiques. Elles peuvent arriver ensuite…
    
    Par contre, ce faisant, tu risques de détourner les informaticiens que tu cherches pour participer à ton projet: ils ne verront pas tout de suite ce qui leur parle.
    
    Deux publics donc… J'ai envie de dire que tes deux idées de tuto sont nécessaires. Commence par celui à destination des informaticiens, ce seront les premiers à aller voir ta page. Et propose le côté élève sous forme de cours/TD.
    
    Pour courage en tout cas pour poursuivre ton initiative !
# Heureuse initiative

Posté par Nassara le 23 octobre 2014 à 16:43. Évalué à 1.

Bravo pour cette contribution logicielle: effectivement le nombre d'outils à notre disposition étant assez limité, c'est bien à nous (enseignants) de les coder.
Personnellement, j'utilise le pseudocode algobox (et j'en suis assez satisfait) pour une initiation à l'algorithmique telle qu'elle est en vigueur dans les programmes du lycée (voie générale).
La notation infixe peut effectivement paraître déstabilisante, mais à vrai dire, tant que je n'ai pas vu de réactions d'élèves, je n'ai pas d'opinion.
De toute évidence l'existence d'une interface avec geogébra est une excellente idée qui ouvre de belles perspectives en matière de modélisation (car l'algorithmique est pour nous un outil utilisé dans un cadre mathématique).
Le fait que les élèves l'utilisent en client sur un serveur est aussi une piste à creuser. Cela pourrait peut-être permettre au prof d'avoir un oeil sur l'ensemble des productions, ce qui fait gagner beaucoup en efficacité. Et au passage à l'administrateur du réseau - oui la plupart d'entre nous ont double casquette - de ne pas se prendre le chou. J'ai parcouru la documentation, ça n'a pas l'air d'être bien compliqué à installer sur un serveur web (en local) dans un établissement. Le top serait de pouvoir l'intégrer à un serveur WIMS (j'imagine que ça, ça doit être du boulot).
# Ça me rappelle le LSE !

Posté par enikar le 23 octobre 2014 à 20:30. Évalué à 6.

C'est marrant ça m'a fait penser au Langage Symbolique d'Enseignement

C'est le premier langage que j'avais « appris » au début des années 80 quand j'étais en seconde. Ce qui me laisse de grand doute sur l'utilisation du français pour les mots clefs du langage. Après tout dépend du public visé.
# L'epi-algo

Posté par Guillaume Camera le 24 octobre 2014 à 10:00. Évalué à 2.

Ploplop,

Bravo pour l'initiative, mais je ne serais que trop rejoindre les commentaires qui ont été faits plus haut. La notation choisie est bien sur plus facile à gérer , et tout de suite fonctionnel, mais proposer ça à des débutants, j'y crois moyen moins.

Lorsque j'ai été à l'EPITA, on nous a pris un langage algo maison, mais bien foutu. Alors , oui, nos premières lignes de codes on les a écrit sur une feuille de papier, mais la syntaxe du langage invite vraiment à comprendre les bases de manière claire. Un doctorant qui passait par là et merveilleux professeur à ses heures perdus, a eu la bonne initiative de vouloir implémenter un interpréteur du langage pour que les élèves aient d'avantage envie de le pratiquer et de s'exercer sur machine.

Je crois que très franchement, le projet a été plus ou moins abandonné, mais je pense plus par faute de temps et d'utilisation concrète. Cela dit, ce projet mériterait franchement une mise en avant

https://code.google.com/p/epi-algo/source/browse/?r=8 (peut-être y a t'il des sources plus récente)

C'est du CamL, l'outil est merveilleusement bien choisi (oui c'est vendredi \o/) :)
- [^] # Re: L'epi-algo
  
  Posté par Maxime (site web personnel) le 25 octobre 2014 à 21:24. Évalué à 6.
  En dehors de l'usage du Français, est-ce vraiment plus simple que de l'Ada ou du Pascal? Je cite ces langages car en lisant les exemples, j'ai vraiment l'impression de lire de l'Ada traduit en Français.
```
algorithme fonction connexite : entier
      parametres locaux
           t_graphe_s       G
      parametres globaux
           t_vect_entiers      cc
      Variables
           entier       i, no
debut
      pour i <- 1 jusque G.ordre faire
           cc[i] <- 0
      fin pour
      no <- 0
      pour i <- 1 jusque G.ordre faire
           si cc[i] = 0 alors
                 no <- no+1
                 prof_rec (G, i, no, cc)
           fin si
      fin pour
      retourne (no)
fin algorithme fonction connexite
```
  En Ada :
```
function connexite(G : t_graphe_s) return Integer is
      i, no : Integer;
begin
      for i in 1..G.ordre loop
           cc(i) := 0;
      end loop;
      no := 0;
      for i in 1..G.ordre loop
           if cc(i) = 0 the
                 no := no+1;
                 prof_rec (G, i, no, cc);
           end if;
      end loop;
      return no;
end connexite;
```
  Il n'y a vraiment pas en grande différence… Donc est-ce vraiment la peine de s'embêter à utiliser une copie traduite et avec encore moins d'outils à disposition ?
- [^] # Re: L'epi-algo
  
  Posté par ProfGra (site web personnel) le 28 octobre 2014 à 18:23. Évalué à 2.
  
  Bravo pour l'initiative,
  
  Merci.
  
  mais je ne serais que trop rejoindre les commentaires qui ont été faits plus haut. La notation choisie est bien sur plus facile à gérer
  
  Tu parles côté développeur ou utilisateur de MicroAlg? Perso, je pense que c’est bien des deux côtés !
  
  et tout de suite fonctionnel, mais proposer ça à des débutants, j'y crois moyen moins.
  
  Tu dis «fonctionnel» comme le paradigme ? Si oui, j’ai répondu à cette remarque ici:
  http://qr.microalg.info/question/5/pourquoi-un-langage-fonctionnel-pour-les-debutants/
  
  [epi-algo] (peut-être y a t'il des sources plus récente)
  
  Oui, tu donnes un lien vers la r8 mais il y a en effet plus récent.
  Merci, je vais regarder de plus près.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
# Pascal ?

Posté par Kwiknclean le 24 octobre 2014 à 13:15. Évalué à 1. Dernière modification le 24 octobre 2014 à 13:18.

Bonjour,

Je profite de cette louable initiative, pour interroger la communauté.

Je me souviens (fin j'suis pas si vieux quand même …), dans mes premiers cours d'algos/infos le langage d'étude était Pascal, qui semblait de l'avis de tous un bon langage d'étude et d'initiation avant d'enquiller vers le C.

Qu'en est-il aujourd'hui ? J'ai l'impression qu'il est un peu tombé en désuétude ? D'une manière générale on apprend sur "quoi" de nos jours, à niveau plus ou moins BAC ?

… Java ?
- [^] # Re: Pascal ?
  
  Posté par barmic le 24 octobre 2014 à 14:10. Évalué à 3.
  
  De mon expérience, moi qui ai passé mon BAC en 2006, le premier langage que j'ai appris c'est le C++ (en IUT info).
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Pascal ?
  
  Posté par Michaël (site web personnel) le 24 octobre 2014 à 14:19. Évalué à 2.
  
  À la fac de maths en 97 j'ai appris le Scheme et le C.
- [^] # Re: Pascal ?
  
  Posté par freem le 24 octobre 2014 à 14:20. Évalué à 1.
  
  J'imagine que ça dépend de la formation en question, je doute fortement que le C ait été remplacé en STI électronique…
  - [^] # Re: Pascal ?
    
    Posté par rpnpif le 27 octobre 2014 à 00:58. Évalué à 4. Dernière modification le 27 octobre 2014 à 01:03.
    
    J'imagine que ça dépend de la formation en question, je doute fortement que le C ait été remplacé en STI électronique…
    
    Et si… et non. D'abord, STI électronique n'existe plus. Elle est remplacé par STI2D avec une possibilité de spécialité SIN (systèmes informatiques et numériques).
    
    La liberté pédagogique existe en France, donc il n'y a pas de langage réellement imposé.
    Déjà du temps de STI électronique, la programmation se faisait souvent par des algorigrammes donc en graphique, ce qui avantage les lycéens visuels (plus nombreux) et désavantage les "raisonnants" de type audififs. Le C était sous-jacent.
    
    Bien sûr, par écrit (papier ou traitement de texte), les textes décrivant l'algorithmique et les dessins d'algorigrammes sont utilisés depuis plus de 20 ans en lycée technique et en lycée professionnel en France.
    
    Aujourd'hui, tout est possible : en SIN certains profs utilisent la même programmation graphique (par algorigramme avec Flowcode, propriétaire :/, ou plus rarement avec un logiciel libre sous KDE dont j'ai oublié le nom), d'autres introduisent Java par la construction d'applications Android ou sur Processing. D'autres prennent le C++ simplifié d'Arduino, ou bien Python, Qt, etc.
    
    Mais ne pas oublier que, formellement, il n'y a pas d'apprentissage de langage informatique en STI2D, même en spécialité SIN. Seule la découverte simple est au programme.
    
    De plus, les lycéens de STI2D ont un enseignement technique commun avec toutes les spécialités (ITEC plus orientés mécaniques, AC plus architecture et génie civil, SIN et EE plus orientés énergétique) et c'est là que les systèmes pour débutants, tel celui décrit dans cette dépêche, sont intéressants. Leurs profs de maths sont aussi demandeurs de ce genre d'outils pour non-spécialistes. Ils sont bien conformes à l'esprit de l'épreuve technologique commune dite tranversale du BAC STI2D.
    
    Là où ça se corse, c'est quand l'on marie les algorigrammes et l'algorithmique avec l'UML ou plutôt sa déclinaison, le SysML en lycée (!). On n'est plus alors au niveau débutant… et pourtant.
    Mais c'est un autre problème.
    - [^] # Re: Pascal ?
      
      Posté par freem le 27 octobre 2014 à 11:51. Évalué à 2.
      
      Seule la découverte simple est au programme.
      
      Ça, ça à dû changer alors, parce que je me rappellerais toujours avoir été interrogé sur le module "clavier" --qui se constituait principalement de code-- du projet lors du bac (pour mon plus grand plaisir d'ailleurs, j'avoue que le programme était si simple que je n'avais eu ni besoin de réviser, ni même de consulter quelque document que ce soit, j'ai regardé les examinateurs dans les yeux tout le long de ma présentation :D).
      Pour être précis, je ne sais pas si c'était obligatoire, mais on avait étudié la programmation de PIC (par contre, il ne me semble pas qu'on avait manipulé) et du coup, j'ai un peu de mal avec la notion d'utiliser des langages qui ne sont pas capables d'accès bas niveau dans ces classes (d'électronique, hein, pour les autres STI c'est sûr que l'intérêt est restreint) tels que python, par exemple.
      
      En tout cas merci pour ces infos des changements qui ont eu lieu… intéressant de savoir que l'arduino est arrivé dans certains lycées.
      
      SysML
      
      Tiens, je n'avais jamais entendu parler de ça. Vais aller combler ce manque fissa…
    - [^] # Re: Pascal ?
      
      Posté par freem le 27 octobre 2014 à 11:51. Évalué à 1. Dernière modification le 27 octobre 2014 à 11:52.
      
      Et m… double post!
- [^] # Re: Pascal ?
  
  Posté par jean_claude (site web personnel) le 24 octobre 2014 à 19:28. Évalué à 3.
  
  Qu'en est-il aujourd'hui ? J'ai l'impression qu'il est un peu tombé en désuétude ? D'une manière générale on apprend sur "quoi" de nos jours, à niveau plus ou moins BAC ?
  
  Perso j'aimais bien lazarus+pascal
  
  j'enseigne l'isn au niveau lycée. Nous (plutôt je) avons choisit le python. Après quelques années je suis certain d'avoir fait le bon choix, et ce pour plusieurs raisons.
  -> Rapidité d'apprentissage avec peu d'heures d'enseignement.
  -> De nombreuses documentations sur internet
  -> En prépa, ils utilisent python.
  -> On peut faire des maths avec , sites internet, etc ….
  
  Je crois que deux langages sont utilisés en majorité en isn: python et java (Avec plus de python m'a t on dit).
- [^] # Re: Pascal ?
  
  Posté par Maxime (site web personnel) le 25 octobre 2014 à 21:41. Évalué à 6.
  
  Ici j'enseigne l'Ada à Bac+1 (première année école d'ingé en 5 ans). Je n'ai pas beaucoup d'expérience avec le Pascal mais pour moi c'est très proche (pour les bases en tout cas).
  
  Je ne fais que des TD et TP, je n'ai aucun pouvoir décisionnel sur le choix du langage et la façon dont c'est enseigné. Mais ce n'est pas trop mal comme choix. Il y a tout ce qu'il faut pour enseigner les bases sans avoir à parler de pointeur ou d'objet trop rapidement.
  
  Pour moi les inconvénients sont :
  - Le langage n'est pas beaucoup utilisé donc les étudiants sont frustrés et ont le sentiment d'apprendre un truc qui sert à rien. En plus de toute façon on doit leur apprendre le C et le Java peu après (pour ceux qui se spécialisent dans l'info), ils aimeraient passer au Java plus rapidement.
  - C'est un peu verbeux, surtout si on veut faire les choses proprement.
  - Pas beaucoup de tutos sur internet pour ceux qui veulent approfondir.
  - Pas toujours évident de trouver des encadrants qui connaissent bien l'Ada (on a une vingtaine d'encadrants ici pour les étudiants de première année). Heureusement que ce qui est enseigné est trivial (le public ne continue pas dans l'informatique pour 80% d'entre eux).
  
  Mais si je devais choisir un langage pour enseigner, ce serait vraiment pas évident à choisir. Je pense choisir le Python mais ce qui me dérange c'est qu'on ne se rend pas toujours bien compte de la complexité algorithmique de ce qu'on fait. Mais au moins le code serait correctement indenté et les bons seraient davantage motivés pour approfondir.
  - [^] # Re: Pascal ?
    
    Posté par Blackknight (site web personnel, Mastodon) le 28 octobre 2014 à 09:48. Évalué à 1.
    
    Pas beaucoup de tutos sur internet pour ceux qui veulent approfondir.
    
    Que cherches-tu comme tutos pour approfondir ?
    On sait jamais, j'ai peut-être des liens pour toi :)
- [^] # Re: Pascal ?
  
  Posté par lolcat le 26 octobre 2014 à 20:53. Évalué à -3.
  
  Pascal est légèrement désuet. S'il est encore enseigné, ce doit être pour des raisons historiques (les profs ne sont pas à jour). Python est le langage de choix pour enseigner algorithmique et programmation. Pas de complexité de type, interprétation facile, syntaxe concise, etc.
  - [^] # Re: Pascal ?
    
    Posté par Zylabon le 27 octobre 2014 à 00:07. Évalué à 4.
    Pas de complexité de type
```
a = 2/3
b = 2//3
c = 2.0/3
d = 2.0//3

#Que valent a b c et d
#sachant que / est la division et // est la division entière ?
```
    Ce genre de question ressemble à celles que l'on pose lors du premier cours de programmation python, et pourtant, je suis prêt à parier que même des utilisateurs réguliers de python se planteraient.
    La faute à un système de type tout sauf simple.
    
    Please do not feed the trolls
    - [^] # Re: Pascal ?
      
      Posté par Ytterbium le 27 octobre 2014 à 06:50. Évalué à 4.
      
      En python3, pas de problème, les résultats sont bien les plus logiques.
    - [^] # Re: Pascal ?
      
      Posté par Maxime (site web personnel) le 27 octobre 2014 à 07:53. Évalué à 3.
      Il y avait une faiblesse dans Python2 qui a été corrigée. Cela donne donc :
      
      >>> a = 2/3 >>> b = 2//3 >>> c = 2.0/3 >>> d = 2.0//3 >>> print(a, b, c, d) 0.6666666666666666 0 0.6666666666666666 0.0
      
      Il faut donc juste retenir que / c'est la division et // c'est la division entière. Était-ce si difficile ?
      - [^] # Re: Pascal ?
        
        Posté par Moonz le 27 octobre 2014 à 09:17. Évalué à 3. Dernière modification le 27 octobre 2014 à 09:18.
        
        d est quand même surprenant (et dangereux).
        
        [^] # Re: Pascal ?
        
        Posté par freem le 27 octobre 2014 à 11:57. Évalué à 3.
        
        Pourquoi? Faire une division entière de 2 par 3, peu importe que 2 soit float ou pas?
        
        [^] # Re: Pascal ?
        
        Posté par Benoît Sibaud (site web personnel) le 27 octobre 2014 à 13:22. Évalué à 5. Dernière modification le 27 octobre 2014 à 13:24.
        
        Si on considère que la définition mathématique d'une division entière est « une opération qui, à deux entiers naturels appelés dividende et diviseur, associe deux autres entiers appelés quotient et reste » (Division entière), alors c'est étonnant (on a une conversion implicite flottant vers entier avant la division, ou une division entière étendue avec dividende et reste réels, ou une division entière étendue avec dividende réel et reste entier ne redonnant pas le dividende initial…).
        
        [^] # Re: Pascal ?
        
        Posté par Maxime (site web personnel) le 27 octobre 2014 à 13:45. Évalué à 4.
        
        Dans ce cas, on peut dire que // c'est la division qui ne garde en résultat que la partie entière.
        
        [^] # Re: Pascal ?
        
        Posté par Antoine le 27 octobre 2014 à 13:54. Évalué à 4.
        
        Division entière est la traduction approximative, en réalité c'est floor division (et non integer division), ce qui veut dire "division arrondie par en bas" :
        https://docs.python.org/3/glossary.html#term-floor-division
        
        Par ailleurs, l'idée du reste d'une division flottante est aussi normalisée par le C et par POSIX :
        http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmod.html
        
        [^] # Re: Pascal ?
        
        Posté par freem le 27 octobre 2014 à 14:28. Évalué à 1. Dernière modification le 27 octobre 2014 à 14:30.
        
        J'imagine que c'est là la différence entre les maths et le dev. Moi, peut-être à cause de mon bagage matheux quasi inexistant, je perçois les opérateurs arithmétiques comme des fonctions. Du coup, je vois: floor_divide( float, int ). (Je mets floor par rapport au commentaire précédent, qui est plutôt pertinent du peu de connaissance que j'ai)
        
        Que le dividende soit un nombre à virgule ou pas, n'empêche en rien que le résultat d'une telle fonction soit un entier, de 0 en l'occurrence. La question maintenant, c'est qu'est-ce que ferait a = 1.2f % 3.
        Ici, on demande un reste, qui est censé ne pouvoir qu'être entier si j'ai bien compris, ce qui serait surprenant: on pourrait s'attendre, si on remplaçait par une fonction modulo, soit à avoir le résultat mathématique, soit le résultat logique qui serait lui, 1.2f (puisque l'on à pas pu diviser, donc rien enlever, on pourrait arguer qu'il devrait rester la totalité du dividende, qui est 1.2f, alors que ta définition indique que le résultat devrait être 1.).
        
        [^] # Re: Pascal ?
        
        Posté par Anthony Jaguenaud le 27 octobre 2014 à 16:07. Évalué à 3.
        
        La division entière est définie de $\mathbf{N} \longrightarrow \mathbf{N}$
        
        Donc comment définir le résultat de 15,1 / 5,1 ?
        
        Ça revient à 15/ 5 == 3 ?
        
        Ou E(15,1 / 5,1) == 2 ? (15,1 / 5,1 == 2,96… la partie entière vaut donc 2)
        
        [^] # Re: Pascal ?
        
        Posté par Maxime (site web personnel) le 27 octobre 2014 à 17:34. Évalué à 3.
        
        Antoine a très bien répondu à cette question ici : http://linuxfr.org/news/microalg-langage-et-environnements-pour-l-algorithmique#comment-1569901
        
        C'est donc l'arrondi à l'entier inférieur du résultat de la division. Je suis désolé d'avoir utilisé le terme division entière qui est un mauvais terme, je voulais dire par abus de langage : partie entière de la division.
        
        [^] # Re: Pascal ?
        
        Posté par Moonz le 27 octobre 2014 à 16:11. Évalué à 2.
        
        Surprenant parce que faisant une division entière je m’attend à un résultat entier.
        
        Dangereux parce que si je me rend pas compte qu’il m’a renvoyé un flottant au lieu d’un entier, == et != peuvent se comporter de manière inattendue.
        
        [^] # Re: Pascal ?
        
        Posté par freem le 27 octobre 2014 à 16:13. Évalué à 4.
        
        Qu'un des paramètres de la division entière soit un flottant ou pas n'a pas à changer le fait que le retour de la division entière soit un entier…
        
        [^] # Re: Pascal ?
        
        Posté par Anthony Jaguenaud le 27 octobre 2014 à 16:57. Évalué à 4.
        
        Le print d écrit 0.0 donc float sinon ce serait : 0 comme l’autre.
  - [^] # Re: Pascal ?
    
    Posté par ProfGra (site web personnel) le 27 octobre 2014 à 17:43. Évalué à 5.
    
    Pascal est légèrement désuet.
    
    En prod oui.
    Pédagogiquement, pas du tout. Il a été conçu pour l’enseignement.
    
    S'il est encore enseigné, ce doit être pour des raisons historiques (les profs ne sont pas à jour). Python est le langage de choix pour enseigner algorithmique et programmation.
    
    C’est ce que je disais il y a quatre ans. J’étais jeune et beau, je faisais beaucoup de Python pour mon compte perso, et j’en vantais les mérites à un collègue d’une autre génération qui enseignait l’algo avec Pascal. J’en suis revenu. Python n’a pas été conçu pour la pédagogie, mais pour la concision et la lisibilité, voire la multi-pagadigmicité (en gros).
    
    Pas de complexité de type, interprétation facile, syntaxe concise, etc.
    
    Les types, c’est mieux pour enseigner. Ça donne des bases pour réfléchir.
    Interprétation, je ne suis pas sûr de comprendre.
    Syntaxe concise, c’est autant de choses à apprendre (le slicing de listes par exemple, c’est très puissant, mais pas immédiat pour les débutants).
    
    Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
# Pourquoi ne pas utiliser Scheme?

Posté par Michaël (site web personnel) le 24 octobre 2014 à 14:18. Évalué à 6.
Qu'est ce qui ne te plaisait pas avec Scheme et qui t'a poussé à définir ton propre langage?
- Scheme est un langage simple très adapté à l'apprentissage de l'agorithmique.
- Si tu veux traduire les mots-clefs tu peux probablement le faire avec des macros — mais je ne vois vraiment pas trop l'intérêt, l'anglais s'apprend à l'école et ceux qui ont choisi d'autres langues peuvent bien apprendre 4 mots et demi.
- Si tu veux le faire tourner dans un Browser, il y a déjà des implémentations, comme par exemple BiwaScheme.
- [^] # Re: Pourquoi ne pas utiliser Scheme?
  
  Posté par ProfGra (site web personnel) le 28 octobre 2014 à 18:50. Évalué à 2.
  Qu'est ce qui ne te plaisait pas avec Scheme et qui t'a poussé à définir ton propre langage?
  
  Bonjour. Bonne question, je te remercie de l’avoir posée.
  
  Scheme est un langage simple très adapté à l'apprentissage de l'agorithmique.
  
  Tout à fait. J’ai du lire au moins la moitié de SICP avant de vraiment commencer Lisp, et ça m’a permis de voir que c’était un langage non seulement généraliste, mais surtout caméléon.
  
  D’un côté, je suivais depuis longtemps la mailing-liste de PicoLisp (octobre 2010). Même si je n’ai pas utilisé le langage pendant trois ans et demi, la qualité des discussions m’a poussé à lire chacun des posts (bon, la liste n’est pas non plus super active). La philosophie du langage m’a vraiment plu, entre implémentation minimale (et proche du métal) et concepts de haut niveau.
  Je voulais utiliser ce langage.
  
  D’un autre côté, Scheme me paraissait limité par rapport à PicoLisp:
  - IIRC, Scheme a deux espaces de noms: un pour les variables, un pour les fonctions.
  - Niveau évaluation ou non des arguments, PicoLisp a l’air plus souple.
  Si tu veux traduire les mots-clefs tu peux probablement le faire avec des macros — mais je ne vois vraiment pas trop l'intérêt, l'anglais s'apprend à l'école et ceux qui ont choisi d'autres langues peuvent bien apprendre 4 mots et demi.
  
  Oui et non. J’ai préféré le faire en français. Mais on ne va pas relancer le débat «anglais» / «pas anglais» !
  
  Merci pour ton commentaire !
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
# Parenthèses vs indentation

Posté par Arthur Accroc le 24 octobre 2014 à 16:53. Évalué à 2.
(. (À mon avis (sont (les parenthèses) ((non souhaitable) (une difficulté)))))
```
Je pense
    que
        l’indentation est
            au contraire
        quelque chose
            qui améliore la lisibilité
                de la structure
                    du programme,
    et qu’
            en l’imposant,
        un langage
            comme Python
        conduit les débutants
        à faire du code
           plus lisible,
               y compris pour eux.
```
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Parenthèses vs indentation
  
  Posté par anaseto le 24 octobre 2014 à 17:07. Évalué à 3.
  
  La lisibilité du code pour une initiation à l'algorithmique, ce n'est pas l'essentiel, ce n'est pas comme s'ils allaient tous devoir maintenir par la suite de vrais programmes. Et puis, ce n'est pas parce qu'il y a des parenthèses qu'il n'auront pas le droit d'indenter. Enfin, je pense plutôt que des séparateurs bien visuels qui donnent la structure du code sont un plus pour les débutants, et puis ça évite une explication sur la différence entre les tabs et les espaces (parce que je ne crois pas qu'au lycée les élèves soient aujourd'hui tous très habiles avec un éditeur de texte).
  - [^] # Re: Parenthèses vs indentation
    
    Posté par rewind (Mastodon) le 24 octobre 2014 à 17:53. Évalué à 8.
    
    Quand tu dois corriger plein de TP, tu leur apprends très vite à indenter correctement et tu inclues ça dans la notation !
  - [^] # Re: Parenthèses vs indentation
    
    Posté par Arthur Accroc le 25 octobre 2014 à 09:36. Évalué à 5.
    
    La lisibilité du code pour une initiation à l'algorithmique, ce n'est pas l'essentiel, ce n'est pas comme s'ils allaient tous devoir maintenir par la suite de vrais programmes.
    
    Ce n’est pas comme si on voulait qu’ils arrivent à relire les programmes qu’ils ont eux-mêmes écrits il y a 15 minutes…
    
    Enfin, je pense plutôt que des séparateurs bien visuels qui donnent la structure du code sont un plus pour les débutants,
    
    « Bien visuels » ? Des séparateurs où il faut un éditeur qui surligne celui qui fait la paire pour être sûr de ne pas faire d’erreur, même pour un programmeur aguerri ?
    
    et puis ça évite une explication sur la différence entre les tabs et les espaces (parce que je ne crois pas qu'au lycée les élèves soient aujourd'hui tous très habiles avec un éditeur de texte).
    
    Et puis c’est tellement plus contraignant de fournir un éditeur qui remplace les tabs par des espaces plutôt qu’un éditeur qui surligne les paires de parenthèses…
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Parenthèses vs indentation
  
  Posté par freem le 24 octobre 2014 à 18:07. Évalué à 1. Dernière modification le 24 octobre 2014 à 18:08.
  Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…
  
  Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère, et il y à même des gens qui ont créé astyle, qui permets de pull un projet avec mon codestyle, et de le push avec le codestyle d'origine.
  
  Par exemple, est-il possible de faire un truc comme ça:
```
int foo(
  char bar
)
{
  this.is.a.very
  (
   long, line,
   which,
   only,
   serves,
   as, a, dumb,
   example
  );
}
```
  Même si le code que j'ai utilisé en exemple est complètement crétin, il n'empêche que ça serve, parfois.
  De même, en openGL 1 (oui, je sais c'est obsolète, mais la question n'est pas là), il existe des fonction glbegin() et glend() qui permettent de définir entre les blocs une suite d'instructions graphiques.
  Quand je m'en suis servi, j'ai indenté le code entre ces deux fonctions, parce que c'était un peu comme une structure de contrôle au final.
  Avec python, ce serait impossible…
  Ensuite, j'ai pensé à utiliser un bloc d'instruction, c'est plus simple et lisible. Mais avec python, est-ce faisable? Parfois, cette dernière technique me sert aussi quand je refacto du code atteint de gigantisme fonctionnel (fonction qui me force à scroller 5minutes pour en voir la fin…) histoire de pré-découper le code en future fonctions, le jour ou quelqu'un d'autre aura le temps :=) (oui, je devrais le faire moi-même, sauf que, c'est pas parfois pas si simple que ça…).
  Encore une fois, quid de ces cas particuliers en python?
  
  En fonction des réponses, il se pourrait que l'une de mes barrières pour commencer python saute… Parce que oui, l'indentation et le style de code, c'est important, voire sacré pour moi, et j'aime pas spécialement qu'on me les impose (quand je bosse sur un projet, j'essaie de suivre ce qui est utilisé, cependant, mais la situation est différente, l'histoire à toujours raison!)
  
  PS: je n'ai pas réussi à formater correctement de la même façon que toi du texte normal… tu as fais comment? Ni foo ni
```
foo
```
  
  ne marchaient :/
  - [^] # Re: Parenthèses vs indentation
    
    Posté par feth le 24 octobre 2014 à 18:31. Évalué à 3.
    
    Pour fooBEGIN et fooEND, avec Python, je pense que tu devrais écrire un "context manager", qui s'utilise avec un bloc indenté (mot clef with).
    Pour couper du code en futures fonctions, je saute des lignes (peut-être que j'ai mal compris cette demande).
  - [^] # Re: Parenthèses vs indentation
    
    Posté par jeberger (site web personnel) le 24 octobre 2014 à 18:53. Évalué à 1. Dernière modification le 24 octobre 2014 à 18:53.
```
def foo(
  bar
):
  this.is_.a.very \
  (
   long, line,
   which,
   only,
   serves,
   as_, a, dumb,
   example
  )
```
    Note que les seuls trucs moches dans l'histoire n'ont rien à voir avec l'indentation:
    * Le \ est à cause des ; optionnels: si je ne mets pas le \ il croit que this.is.a.very représente une instruction complète et que le truc entre parenthèses est un tuple. Une autre option serait de mettre la parenthèse ouvrante sur la même ligne que this.is.a.very.
    * Le as_ et le is_, c'est parce que as et is sont des mots-clefs (c'est pareil en C: tu ne peux pas avoir de variable appelée while).
    
    PS: pkoi la liste à puces ne marche pas?
    - [^] # Re: Parenthèses vs indentation
      
      Posté par Zylabon le 24 octobre 2014 à 19:16. Évalué à 3.
      PS: pkoi la liste à puces ne marche pas?
      
      pas de ligne vide avant la première étoile :
      * puce 1
      * puce 2
      avec une ligne vide avant la première étoile :
      
      puce 1
      
      puce 2
      
      (c'est pareil pour le code et un peu tout)
      
      ;-)
      
      Please do not feed the trolls
      - [^] # Re: Parenthèses vs indentation
        
        Posté par jeberger (site web personnel) le 24 octobre 2014 à 19:43. Évalué à 2.
        
        Grrr, j'avais essayé de rajouter un espace à la fin de la ligne précédente, je croyais qu'en markdown ça revenait au même qu'une ligne vide…
  - [^] # Re: Parenthèses vs indentation
    
    Posté par zurvan le 24 octobre 2014 à 22:25. Évalué à -1.
    
    Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère
    
    non c'est trop bien python, surtout quand tu copies du code depuis un site blogspot et que l'indexation est complètement cassée et que tu dois donc tout refaire à la main…
    
    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
    - [^] # Re: Parenthèses vs indentation
      
      Posté par ProfGra (site web personnel) le 29 octobre 2014 à 17:35. Évalué à 3.
      
      Tu voulais peut-être dire « indentation ».
      Avant de découvrir de :set paste de vim, les copiés-collés foiraient chez moi. Mais je me disais que ce n’était pas plus mal, ça me forçait à relire et à comprendre le snippet.
      Ça me fait aussi penser que je donne des exos où du code Python a perdu son indentation et où je demande aux étudiants de la refaire connaissant ce que doit faire le snippet.
      
      Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
      - [^] # Re: Parenthèses vs indentation
        
        Posté par zurvan le 29 octobre 2014 à 21:03. Évalué à 1.
        
        Tu voulais peut-être dire « indentation ».
        
        ah oui, mes doigts ont fourché visiblement !
        
        « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
      - [^] # Re: Parenthèses vs indentation
        
        Posté par freem le 30 octobre 2014 à 12:24. Évalué à 4.
        
        Je plussoie pour le :set paste mais par contre, je suis très peu d'accord avec le fait de considérer que perdre l'indentation peut être un avantage. Surtout pour un langage style python, qui n'utilise que des blancs pour identifier les blocs de code. En fait, tu m'as donné un argument supplémentaire contre python: un programme dont le fond ne fonctionne plus parce que la forme à été altérée, je trouve ça dommage.
        
        [^] # Re: Parenthèses vs indentation
        
        Posté par ProfGra (site web personnel) le 30 octobre 2014 à 17:16. Évalué à 1.
        
        […] je suis très peu d'accord avec le fait de considérer que perdre l'indentation peut être un avantage.
        
        C'est pas non plus ce que j'ai dit, sinon je n'aurais jamais connu le :set paste.
        C'est juste que si on a un peu de temps devant soi, ça peut être un petit trip que de refaire l'indentation, que le langage la prenne en compte ou non.
        
        Surtout pour un langage style python, qui n'utilise que des blancs pour identifier les blocs de code. En fait, tu m'as donné un argument supplémentaire contre python: un programme dont le fond ne fonctionne plus parce que la forme à été altérée, je trouve ça dommage.
        
        Bé là, je pense que c'est une histoire personnelle, voire non contradictoire.
        J'adore Python et suis très content qu'il force l'indentation, et pourtant le langage que je crée ne la force pas.
        
        Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: Parenthèses vs indentation
    
    Posté par Anthony Jaguenaud le 24 octobre 2014 à 23:08. Évalué à 5.
    
    Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…
    
    Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère, et il y à même des gens qui ont créé astyle, qui permets de pull un projet avec mon codestyle, et de le push avec le codestyle d'origine.
    
    Honnêtement, quand tu arrives sur un projet, c’est chiant de faire comme tout le monde au niveau de l’indentation… mais quand tu es sur la troisième version d’un projet, avec 30 personnes qui bossent dessus, tu es content que les deux premières versions respectassent des règles de codage… parce que sinon, avec 2 × 30 personnes avant, sur différents composants, je te raconte pas l’horreur de te retrouver dans un code où chaque fichier suis un template différent.
    
    Je suis d’accord pour dire que c’est contraignant et nécessaire.
    
    P.S.: À la place de respectassent, j’avais initialement écrit respectaient… mais antidote RX m’a dit de l’écrire ainsi.
    - [^] # Re: Parenthèses vs indentation
      
      Posté par DerekSagan le 26 octobre 2014 à 10:11. Évalué à -8.
      
      Bof. La bonne façon de traiter une appli qui en est à sa v3 avec 30 personnes c'est de la benner et de la refaire, donc on s'en fout de l'indentation.
      
      (et c'est pas tant un troll que ça)
      - [^] # Re: Parenthèses vs indentation
        
        Posté par rewind (Mastodon) le 26 octobre 2014 à 15:18. Évalué à 6.
        
        C'est triste ton avis sur GNOME
    - [^] # Re: Parenthèses vs indentation
      
      Posté par freem le 27 octobre 2014 à 12:43. Évalué à 1.
      
      Bof, perso, que l'indentation change entre les dev, je m'en cogne mais alors, royal… parce qu'il existe un outil tout simple, tout con, pour éviter ce type d'emmerdes: astyle (d'ailleurs, GNU ferait bien de s'en servir quand ils font des release de la libcpp!).
      Une fois combiné avec des hook dans le gestionnaire de version, ça ne pause plus vraiment de souci, et il n'y à pas que l'indentation que ça permets de corriger (malheureusement, je ne connait pas d'outil permettant d'altérer les noms d'un code-style à l'autre mais c'est la seule chose qui reste :) ).
      Après tout, on impose bien des règles comme "pas d'exceptions, pas de RTTI, etc" dans certains projets, qui sont vérifiées par un outil (le compilo) alors on est plus à ça près.
      
      Et ce n'est pas comme si cet outil était récent, je suis persuadé qu'il existe bien avant python. Au final, mieux vaut laisser les dev faire comme ils veulent, surtout quand on sait qu'il existe des outils permettant de rendre tout le monde heureux (perso, j'utilise -jyntA1 mais il reste quelques détails à corriger qui ne me satisfont pas encore).
      Ce n'est quand même pas compliqué de mettre un hook dans git pour vérifier que le style est correct, rejeter sinon (voire éventuellement demander si on force le nettoyage du style, mais j'ai jamais testé cette solution) histoire que le contributeur mette un coup de astyle pour vérifier qu'il n'y à pas de bug introduit. Juste dommage que git prenne en compte les différences de style quand on diff/add. Me demande si y'a pas moyen de l'éviter. Ça ne me surprendrais pas.
      
      Perso, je suis bien plus gêné non par les espaces, mais par le fait de ne pas avoir les accolades sur des lignes spécifiques, parce que mon œil trace instinctivement une ligne entre 2 accolades de même indentation (c'est aussi pour ça que je ne suis pas un super fan des langages qui utilisent begin/end, ou case/esac, mais bon… tant qu'ils sont sur leur ligne spécifique, j'ai rien à redire, ça reste une question de goût.). Donc, sur du code python je suis au final déstabilisé quand même.
      
      De même, je sait directement qu'une ligne est la continuation de la précédente en fonction de l'alignement (indentation complétée à coups d'espaces => continuation de ligne), sans devoir aller lire la fin de la ligne précédente pour vérifier qu'elle à un '\'.
  - [^] # Re: Parenthèses vs indentation
    
    Posté par Arthur Accroc le 25 octobre 2014 à 09:41. Évalué à 5.
    
    Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…
    
    Oui, la phrase « lispisée » étant tellement plus lisible que la phrase indentée !
    
    Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère
    
    Et penses-tu aussi pertinent que des débutants (le sujet ici) choisissent « l’indentation qu’ils préfèrent » ?
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: Parenthèses vs indentation
      
      Posté par freem le 27 octobre 2014 à 12:34. Évalué à 2.
      Oui, la phrase « lispisée » étant tellement plus lisible que la phrase indentée !
      
      Je n'ai pas dit que la phrase avec lisp est plus belle, juste que celle avec indentation forcée est moche. D'ailleurs, est-il interdit d'indenter en lisp? Je pourrai code que des one-liner en C++ (à l'exception des directives) ce ne serait pas lisible, mais pour autant, il ne m'est pas interdit d'indenter… juste fortement recommandé.
      Je suis largement en faveur de l'indentation, mais largement contre le fait de forcer un codestyle par le langage (par le projet, par contre, ça ne me choque absolument pas: il s'agit d'un choix non lié à la technologie)
      
      Et penses-tu aussi pertinent que des débutants (le sujet ici) choisissent « l’indentation qu’ils préfèrent » ?
      
      Non, mais je pense que ce n'est pas le rôle du langage.
      Le prof peut imposer une indentation, un codestyle (ce qui est largement au-delà de la simple indentation: on fait les choses en entier ou on ne les fait pas), sans pour autant que le langage doive le faire. Et pour le valider c'est quand même simple:
      
      #!/bin/sh astyle < $1 | diff $1 - >/dev/null && echo ok || echo "Tu ne respectes pas le style imposé, corriges!"
      
      Il suffit de remplacer "echo ok" par la commande pour compiler/exécuter/whatever du langage voulu, et si nécessaire d'ajouter des options à astyle, en fonction des goûts du prof.
      À moins que le prof en question ne fournisse pas l'environnement de travail aux élève mais leur demande de l'installer, je ne pense pas que ça pose plus de problèmes que ça.
      Le seul truc qu'il reste à ajouter à ça, ce sont les conventions de nommage et une vérification des éventuelles fautes de frappe, si le prof est un grammar-nazi (quoique, dans le cas d'un langage à typage faible, il me semble important d'utiliser un outil tel que aspell, voire même si c'est un projet sur lequel plusieurs personnes bossent, même en typage fort.).
  - [^] # Re: Parenthèses vs indentation
    
    Posté par Moonz le 25 octobre 2014 à 17:06. Évalué à 6.
    De même, en openGL 1 (oui, je sais c'est obsolète, mais la question n'est pas là), il existe des fonction glbegin() et glend() qui permettent de définir entre les blocs une suite d'instructions graphiques.
```
class glTransaction:
    def __enter__(self):
        glBegin()
    def __exit__(self, exType, exValue, exTb):
        glEnd()
        return False

with glTransaction():
    glFoo()
    glBar()
    glBaz()
```
    Avec la gestion des exceptions qui vient gratuitement en bonus.
    - [^] # Re: Parenthèses vs indentation
      
      Posté par freem le 27 octobre 2014 à 12:49. Évalué à 1.
      
      Ah oui, c'est pas mal en effet.
      Si une variable était déclarée dans le bloc indenté, elle serait libérée à la fin du bloc ou pas? (dans le cas de C/C++ ce ne serait le cas que si le bloc est compris entre accolades, je précise, mais il m'est déjà arrivé d'utiliser cette méthode lors de refactoring, ce qui permets de repérer les diverses extrémités des spaghettis grâce au compilo qui engueule/insulte).
      - [^] # Re: Parenthèses vs indentation
        
        Posté par Moonz le 27 octobre 2014 à 16:19. Évalué à 3.
        
        Non, le plus petit scope en Python c’est la fonction, pas le bloc (comme var en Javascript)
- [^] # Re: Parenthèses vs indentation
  
  Posté par fearan le 25 octobre 2014 à 13:22. Évalué à 4.
  
  au jour ou n'importe quel éditeur de code est capable de refaire l'indentation, c'est un peu la plus mauvaise justification que tu puisse trouver.
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# RPL like

Posté par Laurent J (site web personnel, Mastodon) le 24 octobre 2014 à 17:43. Évalué à 4. Dernière modification le 24 octobre 2014 à 17:44.

Oh, du (presque) RPL (à l'envers) :-)

Les étudiants pourraient presque utiliser une calculatrice HP pour programmer :-)
- [^] # Re: RPL like
  
  Posté par Kwiknclean le 25 octobre 2014 à 13:36. Évalué à 1.
  
  Tu veux parler de la notation polonaise inversée ?
  - [^] # Re: RPL like
    
    Posté par Sidonie_Tardieu le 25 octobre 2014 à 16:07. Évalué à 5.
    
    La fameuse reverse polish Lotation : )
    
    Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
# Où est passé Allogène ?

Posté par Yves Martin le 25 octobre 2014 à 19:06. Évalué à 1.

Il existe (ou a existé) "Allogène" http://www.epi.asso.fr/fic_pdf/dossiers/d14p101.pdf
dont on ne trouve pas grandes traces…

Si les auteurs pouvaient le publier, ce serait une bonne base plus solide plutôt que de reprendre de zéro. Même si il est certain que le code doit être modernisé pour les plate-formes modernes.
- [^] # Re: Où est passé Allogène ?
  
  Posté par lolop (site web personnel) le 28 octobre 2014 à 18:48. Évalué à 2. Dernière modification le 28 octobre 2014 à 18:50.
  
  Au cas où certains seraient intéressés par les travaux réalisés dans le domaine des outils pour l'enseignement de l'algorithmique, je ne sais pas si c'est le même Jean-Pierre Fournier, mais j'ai croisé un homonyme quand je suis arrivé dans mon labo actuel, qui a développé un soft appelé ActiveTutor.
  
  Intégration de cette application avec un agent conversationnel animé:
  Article:
  http://perso.limsi.fr/jps/publications/doc/05.A_WACA.activetutor.14juin05.pdf
  Slides:
  http://perso.limsi.fr/jps/publications/doc/05.S_WACA.activetutor.14juin05.pdf
  
  Et… http://activetutor.free.fr/
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# petit bug dans le tuto + deux questions

Posté par Zylabon le 26 octobre 2014 à 15:11. Évalué à 2.

C'est sympa comme langage :)

Petit bug dans le tuto :

La commande Afficher n’affiche que son premier argument et ignore tous les autres. Ici, le deuxième argument « et encore du texte » est ignoré et seul le premier argument « du texte » est affiché

Je comprend que (Afficher "foo" "bar") est un appel correcte équivalent à (Affiche "foo"), en fait non :)

Sinon, je me demandais pourquoi avoir fait le choix d'un "Retourner" à la sémantique différent des langages impératifs usuels.

Et sinon sinon, autre question, pourquoi accorder plus de confiance à l'utilisateur s'il déclare être mineur que majeur ?

Please do not feed the trolls
- [^] # Re: petit bug dans le tuto + deux questions
  
  Posté par ProfGra (site web personnel) le 27 octobre 2014 à 17:19. Évalué à 1.
  
  C'est sympa comme langage :)
  
  Trop merci.
  Quand il sera intégré à Mario Bros, ça sera encore plus sympa.
  
  […] bug Afficher […]
  
  Passer deux args à Afficher sort une erreur normalement dans la 0.2.0.
  Je ne comprends pas, où est le bug ? (comportement attendu, comportement observé par exemple)
  
  Sinon, je me demandais pourquoi avoir fait le choix d'un "Retourner" à la sémantique différent des langages impératifs usuels.
  
  Ce n’est pas un choix, mais une limitation. Tant que je n’ai pas la gestion des exceptions dans la version JS, je suis coincé. Mais j’ai bon espoir, le Retourner devrait retourner à sa place.
  
  Et sinon sinon, autre question, pourquoi accorder plus de confiance à l'utilisateur s'il déclare être mineur que majeur ?
  
  C’est plus une blague qu’autre chose.
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)
  - [^] # Re: petit bug dans le tuto + deux questions
    
    Posté par Zylabon le 27 octobre 2014 à 18:04. Évalué à 2.
    
    Passer deux args à Afficher sort une erreur normalement dans la 0.2.0.
    Je ne comprends pas, où est le bug ? (comportement attendu, comportement observé par exemple)
    
    Le bug est dans le texte du tutoriel qui annonce "La commande Afficher n’affiche que son premier argument et ignore tous les autres. Ici, le deuxième argument « et encore du texte » est ignoré et seul le premier argument « du texte » est affiché :"
    
    http://microalg.info/tuto.html
    
    Please do not feed the trolls
# JULIA

Posté par NumOpen le 27 octobre 2014 à 17:54. Évalué à 3.

Il y a un langage qui essaie de conserver tout ce qui est bien dans les autres langages et d'être le plus simple possible : JULIA
http://www.julialang.org
- [^] # Re: JULIA
  
  Posté par ProfGra (site web personnel) le 29 octobre 2014 à 17:22. Évalué à 1.
  
  Bonjour, merci pour cette proposition.
  J’ai un peu jeté un œil il y a quelques temps à Julia, mais je ne cherchais pas la silver bullet pédagogique.
  Peux-tu me dire en quoi ce langage serait intéressant pour les grands débutants ?
  
  Créateur de http://microalg.info (langage et environnements dédiés à l’algorithmique)

Suivre le flux des commentaires

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