Linotte 2.0

Posté par cpc6128 (site web personnel) le 14 novembre 2012 à 15:12. Édité par Benoît Sibaud, baud123 et Florent Zara. Modéré par Florent Zara. Licence CC By‑SA.

Étiquettes :

nov.

2012

C'est avec fierté que je vous présente la version 2.0 du langage de programmation Linotte. La particularité de ce langage est qu’il est entièrement en français. Ainsi, il offre à des jeunes programmeurs (jeune par l’âge ou l’expérience dans ce domaine) d'entrer dans le monde de la programmation très facilement, de par sa syntaxe simplifiée et son approche programmatique particulière.

Cette version 2.0 marque le passage vers l'âge adulte du projet (8 ans de vie !).

Un nombre important de changements ont été apportés notamment dans le cœur du langage : des erreurs de jeunesse corrigées, un travail sur l'amélioration de la lisibilité du langage et des corrections de bogues.

Avant de détailler la liste des changements qu’apporte cette version, il est important de noter que tous les anciens programmes qui ont été développés avec les versions antérieures restent compatibles si (et seulement si) l'option « Compatible 1.X » est activée. L’option activée, les nouveautés syntaxiques ne sont plus disponibles… Il faudra donc penser à désactiver cette option pour en profiter de nouveau ! Quelles sont donc les nouveautés apportées par la version 2.0 ?

une simplification du langage : les articles et la forme « présent simple » ne sont plus proposés. Il n'est plus possible d'écrire : « tu affiches le tableau » mais seulement « affiche tableau ».
une modification de la visibilité des variables : les variables sont maintenant locales à un contexte (fonctions ou blocs) et non avec une visibilité globale par défaut. Dans l'ancienne version, il fallait préfixer une variable par le caractère § pour indiquer qu’elle était locale. Ce symbole n'est plus utilisé avec la version 2.0.
un changement dans l’utilisation du vocabulaire : la notion de fonction est apparue. Afin d’éviter certaines confusions, ce mot remplace le mot « paragraphe ». Les « sous-paragraphes » disparaissent également pour devenir des « blocs ».
une simplification de la structure d'un programme : plus besoin de nommer son programme, un livre commence directement par une fonction. De plus, les sections "rôles" et "actions" disparaissent. C’est le mot clé "début" qui délimite la création des variables et la liste des actions à effectuer.
un nouveau format des commentaires : la forme ("mon commentaire") n'est plus utilisable, il faut utiliser /*mon commentaire*/ ou //mon commentaire.
ajout des casiers anonymes : on peut écrire : pour chaque {"Pierre", "Paul", "Jacques"}, affiche joker

Cette liste est non exhaustive car elle ne contient pas les corrections de bogues et quelques autres nouveautés.

Ainsi, en version 1.7, un programme a la structure suivante :

Mon programme :
syracuse :
    rôles :
        durée est un nombre
        e est un nombre
    actions :
        demande e
        tant que e est différent de 1, lis
            durée vaut durée + 1
            si (e mod 2) est égale à 0 alors e vaut e / 2
            sinon e vaut e * 3 + 1
        ferme
        affiche durée

Ce même programme devient en version 2.0 :

Syracuse :
    durée :: nombre
    e :: nombre
    début
        demande e
        tant que e != 1, lis
            durée vaut durée + 1
            si (e mod 2) == 0, e vaut e / 2
            sinon e vaut e * 3 + 1
        ferme
        affiche durée

L'écriture de son code est plus rapide et le développeur est moins exposé à la production d'erreurs syntaxiques.

La sortie de cette version 2.0 est importante car, au-delà de l’apport de nouveautés, elle s’est attribuée plusieurs missions :

faire de Linotte un langage de référence dès que l'on souhaite programmer en français,
faire de Linotte un vrai langage de programmation et qu’il soit reconnu comme de qualité,
et enfin démontrer que l'on peut programmer en français !

À mon grand étonnement, j'ai rencontré une certaine résistance lors de la présentation de cette nouvelle syntaxe à des utilisateurs du langage. Pour ces utilisateurs, la verbosité du langage et son approche littéraire avec des phrases proches du français étaient l'essence même du langage Linotte. C'était pour eux un moyen de se rassurer en entrant dans le monde de la programmation.

C'est pour cela que Linotte proposera toujours les deux syntaxes : une version concise et une autre plus verbeuse.

La mise à jour de la documentation est en cours (c’est le talon d’Achille du projet…).

Bon téléchargement et bonne programmation !

Aller plus loin

page principale et téléchargement (627 clics)
documentation (304 clics)
galerie (313 clics)
copie d'écran de l'environnement de développement (510 clics)

# L'anglais à la vie dure + remarques

Posté par Mimoza le 14 novembre 2012 à 16:09. Évalué à 10.

Dans le lien "copie d'écran de l'environnement de développement" le nom de tes variables sont en anglais … comme quoi les habitude ne sont pas si facile à changer … (idem pour la fonction "sleepsort" dans ta page "Découvrir Linotte 2 en dix minutes"
Sinon l'interface de développement semble simple mais complète.
Remarque :
-- On sent l'inspiration venant du C++
-- Pourquoi avoir introduit les pointeurs ? C'est une notion pas vraiment facile à appréhender et à utiliser.
-- "si , lis" => J'aurais mis "alors" plutôt que "lis"
-- Dans ta page de présentation en 10 minutes
—les exemples de code sont bien mais on ne sait pas a quoi ressemble la sortie console.
—"xou", je le connais sous le nom de "ou exclusif", pas "Xou logique". Du coup j'aurais plus vue "ouex" comme nom, ou "oux", là on est trop proche de l'anglais.
—il te manque le "nonet" (nand) comme opérateur primaire.

Mais joli projet, et bonne réalisation, bonne continuation pour ton projet.
# syntaxe simplifiée ?

Posté par goom le 14 novembre 2012 à 16:18. Évalué à 7.

Quand on ne connait pas la programmation, la lecture du programme dans la version 1.7 est plus compréhensible que celle de la version 2.0.

Pourquoi ces changements (si ce n'est pour se rapprocher de ce qui existe par ailleurs) ?
- [^] # Re: syntaxe simplifiée ?
  
  Posté par arnaudus le 14 novembre 2012 à 16:56. Évalué à 10. Dernière modification le 14 novembre 2012 à 16:56.
  Je ne veux pas répondre à sa place, mais j'imagine qu'il faut prendre en compte la possibilité pour les utilisateurs d'évoluer dans leur compréhension de la programmation.
  
  Après, on peut toujours se demander si la difficulté principale pour un débutant est réellement la syntaxe. Est-ce que
```
si x est égal ou supérieur à 0, fais
     x vaut x + 1
```
  est réellement différent de
```
if (x >= 0)
    x = x + 1
```
  en terme de compréhension pour un débutant? J'ai appris les bases de la programmation à l'adolescence, et je ne me rappelle plus vraiment ce qui me posait problème. J'avais par exemple tendance à dupliquer le code, car je me sentais très mal à l'aise avec les boucles while, repeat, et for, dont j'avais du mal à saisir les nuances (à raison d'ailleurs, elles sont totalement redondantes). Plus tard, je me rappelle avoir bien galéré avec les pointeurs et les tableaux, y compris avec l'horrible char** dans les paramètres du main() en C. Mais franchement, je ne crois pas avoir jamais lutté avec des syntaxes comme "x = y + z", ou des trucs comme "if (x < 3)". Je me demande donc si tout ça n'est pas un peu un faux problème.
  - [^] # Re: syntaxe simplifiée ?
    
    Posté par reno le 14 novembre 2012 à 17:16. Évalué à 3.
    
    Le '=' pour 'vaut' est censé poser des problèmes d'après les apôtres du := personnellement je pense que <- (ou encore mieux U+2190) est supérieur d'un point de vue lisibilité car plus proche de ce qui est fait en math.
    
    Pareil pour != ou U+2260..
    
    Et le '==' à la place d'égal est un C-isme.
    - [^] # Re: syntaxe simplifiée ?
      
      Posté par arnaudus le 14 novembre 2012 à 18:01. Évalué à 0.
      
      Je suis d'accord pour le <- , très lisible et intuitif. Moins pour le truc qui ne passe pas en ascii :-)
      
      Le == est un problème majeur, je doute qu'une construction syntaxique n'ait jamais créé autant de bugs difficiles à trouver. J'imagine que le seul intérêt de distinguer = de == est de pouvoir retourner la valeur assignée pour =, de manière à construire des trucs comme a = b = 3, vs a = b == 3. À mon avis, le gain est mineur comparé à la catastrophe sémantique qu'est "==".
- [^] # Re: syntaxe simplifiée ?
  
  Posté par El Titi le 14 novembre 2012 à 17:08. Évalué à 4.
  
  Extrait de la dépêche:
  
  À mon grand étonnement, j'ai rencontré une certaine résistance lors de la présentation de cette nouvelle syntaxe à des utilisateurs du langage. Pour ces utilisateurs, la verbosité du langage et son approche littéraire avec des phrases proches du français étaient l'essence même du langage Linotte. C'était pour eux un moyen de se rassurer en entrant dans le monde de la programmation.
  
  C'est pour cela que Linotte proposera toujours les deux syntaxes : une version concise et une autre plus verbeuse.
  - [^] # Re: syntaxe simplifiée ?
    
    Posté par arnaudus le 14 novembre 2012 à 18:05. Évalué à 5.
    
    Ça ne répond pas vraiment à la question. C'est bien beau de permettre deux syntaxes très différentes, mais la lecture d'un code devient alors très compliquée, car il faut absolument connaitre les deux syntaxes. Ça impose de réserver tout plein de mot-clés qui ne sont jamais utilisés, et ça autorise d'écrire en créole, ce qui peut rendre le code franchement illisible. Ce qui semble une solution raisonnable à court terme peut s'avérer difficilement gérable à long terme…
# Initiative intéressante....

Posté par core le 14 novembre 2012 à 18:00. Évalué à 4.
Projet qui permet de se poser quelques questions "utiles" comme :
- l'omniprésence de la langue anglaise dans les langages de programmation et plus généralement le monde du logiciel, vaste débat !
- la pédagogie de l'enseignement des langages informatiques, en particulier aux enfants…
Néanmoins, est-ce qu'une syntaxe en français aide l'apprentissage ?
Un langage informatique me semble être une construction abstraite qui prend son "indépendance" assez vite.

C'est comme quand on fait des maths ou de la physique, on utilise des concepts qui ont leur propre vocabulaire, on l'acquiert, ce n'est pas la partie la plus difficile :-)

Ce que je veux dire par là c'est que je ne me souviens pas, quand j'ai appris à programmer (en BASIC), vers l'âge de 9 ans, avoir eu une quelconque difficulté avec le vocabulaire anglophone du langage… Chaque mot avait son sens propre et je ne soupçonnais même pas que ça puisse avoir une signification en anglais, ne connaissant absolument pas cette langue à l'époque… Et finalement je me demande si ça ne facilite pas l'apprentissage de l'abstraction du langage de découvrir des mots inconnus, plutot que d'essayer de se reporter à son sens initial dans une langue parlée.

Par contre je me souviens avoir souffert en lisant plus tard des bouquins de programmation écrits en anglais, mais davantage à cause de ma maîtrise imparfaite de la langue dans les explications qu'à cause de la syntaxe du langage elle-même :)

Néanmoins c'est une expérience intéressante de lire du code en français !
- [^] # Re: Initiative intéressante....
  
  Posté par Pierre Jarillon (site web personnel) le 14 novembre 2012 à 19:39. Évalué à 4. Dernière modification le 16 novembre 2012 à 01:35.
  
  Les mots du langage informatique réservés aux instructions ne sont pas nombreux. Il est donc facile de les apprendre en très peu de temps. On ajoute ensuite les bibliothèques de fonctions (libraries) qui ajoutent d'autres mots réservés. En fin de compte, on n'aura réservé que des noms de la langue anglaise et tous les mots du français sont encore disponibles !
  
  Il m'est parfois arrivé malgré cela de me trouver à court de mots concis et j'ai pu faire appel au basque. Je plains les anglophones qui sont à court de mots bien avant moi et sont obligés de créer des noms de fonction ou de variable de plus de 20 caractères. Des noms trop longs nuisent à la compréhension du programme et peuvent induire des confusions.
  
  Finalement, je pense que les langages basés sur l'anglais ne sont pas un handicap pour nous, C'est plutôt une chance. Qu'auriez-vous dit si les instructions standards étaient en katakana ou en sanskrit ?
  - [^] # Re: Initiative intéressante....
    
    Posté par lendemain le 14 novembre 2012 à 23:04. Évalué à -2.
    
    Qu'auriez-vous dit si les instructions standard étaient en katakana ou en sanskrit ?
    
    UTF8 n'existerai pas, ont aurai un encodage direct avec Unicode.
  - [^] # Re: Initiative intéressante....
    
    Posté par koxinga le 15 novembre 2012 à 14:28. Évalué à 7.
    
    Finalement, je pense que les langages basés sur l'anglais ne sont pas un handicap pour nous, C'est plutôt une chance. Qu'auriez-vous dit si les instructions standard étaient en katakana ou en sanskrit ?
    
    Désolé du hors-sujet, mais une petite précision: Les katakanas sont un système d'écriture utilisé en japonais. Le sanskrit par contre est une langue, ancêtre de l'hindi. Le système d'écriture du sanskrit, ainsi que de la plupart des langues du Nord de l'Inde, est la devanāgarī.
# Hmmhmm

Posté par Dinosaure (site web personnel) le 15 novembre 2012 à 14:34. Évalué à 7.
Sommaire
Avec un titre aussi explicite, je risque d'aller très loin dans ce commentaire mais c'est justement le cas car il y a beaucoup de chose à dire. En vérité, ce que je vais écrire ici a déjà était dit sur un forum concernant l'objectif du langage et de ce qu'il en est aujourd'hui. Force est de constater que, au vu des partis pris dans cette version, vous allez plus à contre sens qu'autre chose. Je m'explique.

il offre à des jeunes programmeurs (jeune par l’âge ou l’expérience dans ce domaine) d'entrer dans le monde de la programmation très facilement, de par sa syntaxe simplifiée et son approche programmatique particulière.

Bon, ce langage se positionne donc comme un tremplin à la programmation de façon général. Vous avez donc une vision didactique en voulant proposer un langage où les concepts de programmation tel que les structures conditionnelles, itératives, récursives et tout le tralala, soit accessible par le plus novice d'entre nous pour débuter la programmation.

On peut dire que c'est louable de vouloir faire ça, je n'est rien contre cette approche et beaucoup cherche à offrir ce tremplin pour que la science de l'informatique soit plus ouverte (et peut être moins caricaturé comme elle l'est aujourd'hui). Donc je vais me baser sur ce constat pour montrer le point de vue que j'ai sur vos objectifs et pour éviter le malentendu, si il y en a un.

Le Français

Dans cette optique de faciliter l'apprentissage de la programmation, vous avez pris comme choix le Français comme langue de base à votre langage. Ce choix peut s'expliquer du fait qu'il est, selon vous, plus difficile d'apprendre un langage fait à partir de mot-clé Anglais qu'avec des mot-clés Français. Non ? Si on suit cette logique, on peut imaginer qu'il est plus facile pour un anglais ou un américain d'apprendre à programmer (car on est face à des mot-clés Anglais). Il est vrai qu'il n'a guère besoin de traduction à côté (on se souvient tous des pseudo-codes Si ... Alors ... Sinon). Mais en somme, est ce réellement difficile d'associer le mot-clé if à sa traduction Si ? C'est un travail en plus, est ce vraiment un frein dans un apprentissage de l'informatique ?

Le fait est de constater que la difficulté qu'éprouve les personnes à apprendre l'informatique n'est pas la langue en somme, ou tout du moins les mots qui sont utilisés. Sinon, de l'autre côté de la Manche, nous aurions que des lumières en informatique (mais nous en avons ici aussi). La difficulté qu'éprouve un français quand il débute la programmation, c'est pas le mot-clé if qui le dérange, c'est surtout et c'est là où est le fil rouge de tout ce que je vais dire, c'est sa signification. Qu'est ce que je veut vraiment dire un if dans mon code ? C'est quoi sa signification ? À quoi il sert ? Mais le mot en lui même, on pourrait le remplacer par toto, ça ne changerais très peu au problème. La seul chose que c'est qu'il y a une approximation entre la signification du mot dans la langue naturelle et celle dans la langue formelle.

Le véritable problème

Le véritable problème quand on se lance dans la programmation, c'est pas réellement les mots-clés qui ont était choisi arbitrairement pour représenter des concepts (comme class par exemple). Le véritable problème dans l'apprentissage, c'est comprendre et utiliser ces concepts. C'est d'ailleurs pour ça qu'il est aussi facile de switcher d'un langage à un autre. Les mot-clés sont différents, la syntaxe est différente mais les concepts globaux (boucle, condition, fonction), sont les mêmes.

Par contre, dès qu'il s'agit de maîtriser un concept comme l'OO ou le fonctionnel, cela prend plus de temps et cela demande de la pratique. Ce que je regrette dans ce langage, c'est qu'il n'est pas du tout à la hauteur de vos objectif. C'est d'autant plus vrai quand on voit l'intégration des pointeurs dans le langage (intégrer une notion complexe dans un langage qui se veut simple, c'est un paradoxe). Vous vous êtes focaliser sur cette problématique du français mais qui est véritablement qu'un faux problème. Et il faut aller un peu plus loin que de simplement dire: « les langages informatiques sont en anglais, c'est compliqué, nous on fait du français ».

C'est plutôt les concepts sous-jacent comme notamment les pointeurs qui sont complexes. Tout le monde se mange les dents dessus et c'est pour ça que des langages de haut niveau comme le python ne les intègrent pas (ou tout du moins, il ne le mettent pas en avant comme en C). Ces langages haut niveau mettent de côté des problématiques complexes (comme la gestion de la mémoire) pour faciliter l'apprentissage de celui-ci et ne pas se soucier (tout du moins, au départ) de ces points qui sont le véritable frein dans l'apprentissage d'un langage informatique.

Ce que j'essaye de dire, c'est qu'importe quel mot-clé on mettra à la place de if ou de while, ça ne change absolument rien pour le programmeur et les concepts difficiles qu'il a l'habitude de manipuler sont toujours là. Mais c'est ces concepts qui sont dur à expliquer, comprendre et manipuler - je trouve même un peu plus complexe votre langage car les mots que vous utiliser s'écarte des concepts auxquels ils font référence, je parle notamment de paragraphe.

Conclusion

Je dirais pas que le projet est mauvais, ou même bon. Je dis simplement qu'il n'est pas à la hauteur de ce qu'il souhaite pour plus tard et vous ne faites que vous écartez du chemin et c'est bien triste. C'est dommage car il peut être de plus en plus intéressant de lancer ce genre d'approche pour les générations futures pour lesquelles l'informatique est une science obscure.

Sinon, bonne continuation dans ce que vous faites et j'espère que vous prendrez en compte non seulement ma remarque mais celles aussi présentent dans le forum.
- [^] # Re: Hmmhmm
  
  Posté par gillux le 16 novembre 2012 à 09:31. Évalué à 1.
  
  Je suis assez d’accord. J’ai l’impression que seule la forme a été « embellie » mais le fond reste le même. Or pour moi, la vraie difficulté en programmation, elle est dans le fond. Qu’est-ce vraiment qu’un programme, une instruction, une expression, une variable, un type, une boucle, une fonction etc. ? Ça paraît évident aux programmeurs mais les débutants n’en savent strictement rien. Et surtout : comment traduire ce que je veux que mon programme fasse en une liste d’instructions qui marche ? Je doute un peu que l’usage du français aide à tout cela.
  
  Après, je peux concevoir que pour certains l’anglais pourrait peut-être être un frein au tout début, mais franchement, apprendre une vingtaine de mots-clés ça représente quoi à côté du travail qu’est l’apprentissage des concepts de la programmation ? Et puis de toute façon, j’imagine que les personnes qui ne connaissent pas ces mot-clés les apprendront bien un jour, vu que l’anglais est quasiment enseigné à tous les élèves francophones, alors autant les apprendre tout de suite.
  
  Pour moi, apprendre la programmation dans un français verbeux, ça me semble mal se préparer à l’ensemble des autres langages de programmation qui non seulement utilisent l’anglais mais aussi partagent pas mal d’éléments syntaxiques communs, genre fonction(), =, [ ], ==… C’est un peu comme démarrer l’enseignement des mathématiques en faisant écrire aux élèves « 3 fois 4 égalent 12 » au lieu de « 3 x 4 = 12 ». Ça peut paraître sympa pour celui qui ne connait pas les symboles x et =, mais au final ça rend les choses plus compliquées et ça ne prépare pas à la réalité du domaine. Les débutants se retrouvent face à des concepts nouveaux, alors autant utiliser des mots et symboles nouveaux pour les désigner. Donner à un concept nouveau un nom qui lui est propre ne peut qu’aider à mieux le fixer dans sa tête.
  
  Je pense que si on en est venu aux syntaxes qu’on a aujourd’hui en programmation, c’est qu’il y a des raisons, et elle ne sont pas qu’historiques. Y a qu’à voir Python, c’est ce qu’il se fait de plus clair dans le genre à mon avis. Le français est adapté à la communication entre francophones, et les langages de programmation sont adaptés à la communication avec les machines. Je déplore souvent l’omniprésence de l’anglais en informatique, mais pour le coup, je pense qu’avoir les mot-clés dans une langue différente de sa langue maternelle est plus une chance qu’un défaut. Ça permet de les distinguer du reste et de leur donner cette signification toute particulière qu’ils ont dans un code source. Quand je parle d’un « if » ou d’un « while » à un ami programmeur, il voit tout de suite de quoi je veux parler, même hors contexte. Alors que si je lui dis que j’ai un problème avec mon « vaut » il risque de se demander si je me suis lancé dans l’élevage… ;-)
  
  Voilà, désolé de te descendre ton projet, ça doit pas faire plaisir à lire. Mais surtout ne te décourage pas et continue quand même. L’apprentissage aux débutants reste un objectif on ne peut plus louable.
- [^] # Re: Hmmhmm
  
  Posté par Sytoka Modon (site web personnel) le 16 novembre 2012 à 09:42. Évalué à 2.
  
  Pour la problématique des pointeurs, je trouve que la voie prise par Fortran est bonne (Fortran est dédié au calcul). Les pointeurs sont en fait des références et on ne les déférence jamais. Il retourne toujours la valeur pointée. Ce sont plus des alias en fait. Évidement, pour les modifier, on n'utilise pas l'affection = mais un autre opérateur plus parlant <-
  
  Comme cela ne résoud pas tout, il y a aussi la notion d'ALLOCATABLE sur les variables. Ce signifie qu'elles seront alloués plus tard. C'est très pratique pour les tableaux. L'avantage, en fin de block, tout est automatiquement déalloués. Bref, cela permet une gestion bien plus fine qu'un pointeur plus un malloc pour le compilateur !
  
  Avec cela, on se passe pas si mal des pointeurs du C qui sont au final bien plus complexe à gérer. Cette complexité est inutile dans une grande majorité des cas.
  - [^] # Re: Hmmhmm
    
    Posté par cpc6128 (site web personnel) le 16 novembre 2012 à 10:35. Évalué à 1.
    
    Dans la documentation du langage, je ne parle jamais des pointeurs même si j'utilise l'astérisque dans le langage : il faut le prendre plus comme un alias ou un représentant.
    
    Mais vous avez raison dans le sens où le passage des paramètres se fait par référence quelque soit le type car tous les types sont (en quelque sorte) des objets.
    
    Et quand on parle de passage par référence, on peut parler des pointeurs… mais ça s'arrête là !!
# Comparaison avec le langage PASCAL et Lazarus

Posté par Marotte ⛧ le 16 novembre 2012 à 11:15. Évalué à 3.

J'ai fait du PASCAL au lycée. Je me souviens que le prof nous avait dit que ce langage était en quelque sorte localisé, car on pouvait trouver des versions où tous les mots-clés était en français. Si c'est vrai ça doit vachement ressembler à du Linotte, non ?
- [^] # Re: Comparaison avec le langage PASCAL et Lazarus
  
  Posté par Benoît Sibaud (site web personnel) le 16 novembre 2012 à 11:31. Évalué à 2.
  
  L'Éducation nationale française avait (fin des années 90) une bibliothèque avec des fonctions en français en tout cas. J'ai eu à l'utiliser en classe prépa., où l'on nous demandait juste de coder des fonctions mathématiques sans trop connaître la programmation en général. Donc pour nous « simplifier » la vie, on utilisait des effaceEcran(), des lire(), des ecrire(), etc. Et puis un jour tu veux coder sur ton ordi chez toi et tu découvres ton programme ne compile pas. Et puis un jour tu découvres qu'il existe une notion de pointeur et de gestion mémoire dont personne ne t'avait jamais parlé. Et puis un jour tu veux afficher un point en couleur sur l'écran et ça n'existe pas dans la bibliothèque. Bref, un jour j'ai ramené cette bibliothèque chez moi, j'ai regardé comme on faisait en vrai un « effaceEcran », etc. et j'ai fait du Pascal qui compilait « normalement », pour coder le Jeu de la vie avec un millier de fourmis multicolores par exemple (et plus tard j'ai arrêté le Pascal aussi).
  - [^] # Re: Comparaison avec le langage PASCAL et Lazarus
    
    Posté par Marotte ⛧ le 16 novembre 2012 à 11:37. Évalué à 2. Dernière modification le 16 novembre 2012 à 11:37.
    
    Je parlais carrément d'une traduction des mots-clés eux-mêmes. Genre begin remplacé par début, if par si, etc…
    
    Le LOGO est dans le même cas il me semble.
    
    Peut-être que je raconte n'importe quoi, ce prof était assez « space » et ça remonte à plus de dix ans maintenant.
    - [^] # Re: Comparaison avec le langage PASCAL et Lazarus
      
      Posté par lolop (site web personnel) le 16 novembre 2012 à 15:41. Évalué à 2.
      
      Dans le genre, il y a le LSE:
      
      http://fr.wikipedia.org/wiki/LSE_%28langage_de_programmation%29
      
      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# AlgoBox

Posté par Grégory Soutadé (site web personnel) le 16 novembre 2012 à 18:07. Évalué à 1.

Dans la même veine que Linotte, il y a AlgoBox (http://www.xm1math.net/algobox/) et en plus c'est libre. Il est développé par Pascal Brachet, professeur de mathématiques au lycée Bernard Palissy à Agen.