Lisibilité : Lua VS Axe

[Adriweb]

Ben pour moi, ton code ne fait rien. Il initialise x et y, ok. Il déclare deux fonctions, ok. Mais c'est tout, il n'y a pas de code qui dit "on va boucler, vérifier les touches et dessiner", juste deux fonctions.
À la limite, si on réfléchit, on peut se dire que la première fonction s'exécute toute seule quand on appuie sur une touche fléchée avec le on.arrowKey, mais alors la deuxième je ne sais pas du tout.

Ca, c'est le langage (enfin, l'implémentation Nspire-Lua) qui est fondée sur ce principe de base : le côté événementiel.
Une fois que tu as vu ca (ça se remarque assez vite : on.xxx, ca veut bien dire ce que ca veut dire...), ben, t'as compris.
Ce n'est pas vraiment rare d'avoir ce genre de fonctionnement : les choses sont déclenchées quand il y a besoin, et desinnées quand il y a besoin aussi, pas en permanence.
Je peux dire que ton code est tout autant fou parce que tu fais une boucle infini et vérifie les getKey même quand l'utilisateur n'appuie pas sur une touche, quelle consommation inutile !
Au moins, en Nspire-Lua, ben les trucs se déclenchent quand il y a besoin, pas en permanence
Ca se rapproche des interruptions dans la prog. bas niveau. C'est une réaction à un quelque chose qui s'est passé, pas des trucs qui sont vérifiés en permanence inutilement.

Mon avis là-dessus est que de la maintenance, il va forcément y en avoir si le projet est suffisamment important où que le code est partagé entre plusieurs personnes etc.

Projet important, non. Par exemple sur Topaze, je fais des mises à jour quand on me parle d'un bug mais c'est tout. Et je n'ai aucun problème à comprendre mon code qui est écrit "de la manière débutante".

Et... voilà, c'est le problème : d'autres personnes ne pourront pas forcément lire ton code facilement, seulement toi pourra
Et à un moment, ceci (source) va devenir vrai :

Code: Select all

// When I wrote this, only God and I understood what I was doing
// Now, God only knows

Tu conçois bien que ça peut être problématique, sur le long terme.

[Hayleia]

quelqu'un qui n'a jamais programmé ne comprendra rien à cette ligne

Là je te dirais : quelqu'un qui n'a jamais programmé ne comprendra jamais n'importe quelle ligne de n'importe quel programme, à moins que ce soit du type : demanderAuProgrammeDeLancerLeJeuSnake()

Pourtant, c'est comme ça que j'ai commencé à programmer, en lisant du code sans jamais avoir programmé avant, sans jamais avoir vu du code avant

Là je suis d'accord, mais de toute façon je mets a = x*2 + c*4 - d/2 et non pas a = x * 2 + c * 4 - d / 2, mais encore moins a=x*2+c*4-d/2 (ça passe encore, mais selon les cas ça peut devenir illisible ^^).

On est d'accord que plus c'est long, plus on met d'espaces, mais sans en mettre trop non plus.
Pourtant, mon école nous a dit "mettez des espaces de part et d'autre de chaque opérateur +,-,*,/", ce qui donne bien le truc ridicule que j'ai posté.
Et pour les lignes courtes du genre "a=0", je ne vois pas non plus l'intérêt des espaces, censés rendre plus lisibles en séparant les groupes (dans a = x*2 + c*4 - d/2, on a bien les multiplications qui sont des groupes, le a tout seul d'un côté et le reste de l'autre) mais tu ne vas quand même pas me dire que tu veux séparer un "a" tout seul d'un "0" tout seul séparés d'un "=" tout seul -.-

Pour moi int *a est logique, simplement du fait que int* ne s'applique qu'à la première variable qui suit. Si int* s'appliquait à toutes les variables, pourquoi pas, mais là ce n'est pas le cas, donc on fait avec .

Bof. Si on peut éviter la "situation problématique", je ne vois pas pourquoi on devrait se forcer à avoir un code moins intuitif partout ailleurs
À part ça, l'Axe Parser avait un jour eu un bug qui faisait qu'on devait ajouter 11 à tous les pointeurs dans les commandes de dessin. Est-ce que pour autant le compilateur est resté comme ça en disant "démerdez vous si je suis con et faites des programmes pas intuitifs" ? Non, le bug a été corrigé. Je ne vois donc pas pourquoi les compilateurs C ne règlent pas ce problème si le seul argument en faveur de votre écriture est "le compilo le comprend comme ça" alors que nous on a plein d'arguments de clarté.

Je peux dire que ton code est tout autant fou parce que tu fais une boucle infini et vérifie les getKey même quand l'utilisateur n'appuie pas sur une touche, quelle consommation inutile !

Pour la boucle infinie, oublie. J'ai écrit ça par habitude mais un débutant n'écrirait pas comme ça. Il aurait écrit :

Code: Select all

.AA
0->X
0->Y
Repeat getKey(15)
  ClrDraw
  If getKey(1)
    Y++
  End
  If getKey(4)
    Y--
  End
  If getKey(2)
    X--
  End
  If getKey(3)
    X++
  End
  Rect(X,Y,8,8)
  DispGraph
End


Quand à la consommation inutile, explique moi pourquoi un Flappy Bird en Axe sur z80 est plus rapide qu'un Flappy Bird en Lua
Non, ne me l'explique pas, on ne compare que la lisibilité des programmes, pas leur exécution qui dépend de plein de choses.

Quand au côté évènementiel, il est quand même obscur pour quelqu'un qui n'a jamais lu une ligne de code. Chez moi, ok quelqu'un qui réfléchit trop pourrait se dire "quel gâchis de ressources" mais en tout cas il comprend bien que le code se Repeat tant qu'on n'a pas appuyé sur la touche 15 (peu importe laquelle c'est) et qu'on déplace un Rect de dimensions 8x8 en utilisant les touches 1,2,3,4.

Projet important, non. Par exemple sur Topaze, je fais des mises à jour quand on me parle d'un bug mais c'est tout. Et je n'ai aucun problème à comprendre mon code qui est écrit "de la manière débutante".

Et... voilà, c'est le problème : d'autres personnes ne pourront pas forcément lire ton code facilement, seulement toi pourra
Et à un moment, ceci (source) va devenir vrai :

Code: Select all

// When I wrote this, only God and I understood what I was doing
// Now, God only knows

Tu conçois bien que ça peut être problématique, sur le long terme.

Ben regarde les dates des mises à jour de Pokémon dans mon topic (si tu oses parcourir toutes les pages ), tu verras qu'il s'est passé énormément de temps entre les updates et pourtant je n'ai jamais eu de problèmes à comprendre d'où venaient les bugs qu'on me rapportait (à part le bug de la perte de combat, mais lui est un bug qui a toujours été là et que je n'ai jamais réussi à résoudre, pas un que l'on m'a rapporté et que je n'ai pas réussi à résoudre).

[Adriweb]

Quand à la consommation inutile, explique moi pourquoi un Flappy Bird en Axe sur z80 est plus rapide qu'un Flappy Bird en Lua
Non, ne me l'explique pas, on ne compare que la lisibilité des programmes, pas leur exécution qui dépend de plein de choses.

Effectivement, la rapidité de l'un et de l'autre ne dépend absolument pas du tout que du code constituant le jeu (une fois que les codes sont optimisés correctement, je veux dire)

Quand au côté évènementiel, il est quand même obscur pour quelqu'un qui n'a jamais lu une ligne de code.

A mon avis, c'est juste une façon de penser - quelqu'un qui n'aura vu que ça dans sa vie va être choqué par des boucles de ce genre s'il tombe sur de l'impératif un jour
Mais c'est d'autant mieux de comprendre et de maîtriser ces deux façons de faire. Chacune a ses avantages.

Ben regarde les dates des mises à jour de Pokémon dans mon topic (si tu oses parcourir toutes les pages ), tu verras qu'il s'est passé énormément de temps entre les updates et pourtant je n'ai jamais eu de problèmes à comprendre d'où venaient les bugs qu'on me rapportait (à part le bug de la perte de combat, mais lui est un bug qui a toujours été là et que je n'ai jamais réussi à résoudre, pas un que l'on m'a rapporté et que je n'ai pas réussi à résoudre).

Mais... ça n'empêche que ça reste toi qui le maintient.
En gros, est-ce que quelqu'un d'autre pourrait d'un coup se mettre à continuer/étendre le programme sans avoir à "déchiffrer" des codes non commentés ?
Ce n'est pas forcément souvent que ça arrive à l'échelle de programmes pour calculatrices, mais ailleurs, ce n'est pas forcément si rare....

[m@thieu41]

Pourtant, c'est comme ça que j'ai commencé à programmer, en lisant du code sans jamais avoir programmé avant, sans jamais avoir vu du code avant

Dans ce cas là tu peux comprendre que s'il y a une ligne avec platform.window:invalidate(), à chaque fois qu'on est supposé changer l'affichage, et qu'éventuellement dans certains codes il y a un commentaire avant pour dire qu'on demande à actualiser l'écran, bah c'est une commande pour dire qu'on veut réafficher l'écran

Pourtant, mon école nous a dit "mettez des espaces de part et d'autre de chaque opérateur +,-,*,/", ce qui donne bien le truc ridicule que j'ai posté.

Là on est d'accord, ça tourne au ridicule... Mais bon quand on voit ce qu'ils nous apprennent parfois dans les écoles... Je ne sais pas si c'est pareil après, mais au niveau terminale ils sont capables de nous faire faire :

Code: Select all

A, B et C sont des nombres
Saisir A
B prend la valeur 2 * A;
C prend la valeur B + 2;
Afficher C

Alors que toi et moi on ferai : Saisir A / Afficher 2*A + 2.

Concernant les lignes courtes, ça devient une question de cohérence : si tu en mets pour les grandes lignes, autant en mettre pour les petites, ça fait plus aéré, et c'est logique par rapport au reste.

Je ne vois donc pas pourquoi les compilateurs C ne règlent pas ce problème si le seul argument en faveur de votre écriture est "le compilo le comprend comme ça" alors que nous on a plein d'arguments de clarté.

Ce n'est certainement pas le seul argument, c'est le seul que je connaisse, et celui qui me fait utiliser int *a. Après je suis sur qu'il y a une autre raison à ce "problème".

Je peux dire que ton code est tout autant fou parce que tu vérifie les getKey même quand l'utilisateur n'appuie pas sur une touche, quelle consommation inutile !

En même temps ce n'est pas la même chose, c'est comme si tu comparais un code orienté objet à un qui ne l'est pas. Celui qui ne fait pas de l'orienté objet (ou qui le fait comme en lua) pourrait se dire : ah mais pourquoi faire une fonction juste pour retourner la valeur d'une variable alors qu'on pourrait faire monObjet.maVariable? Quelle consommation inutile de ressources! Ben non ça s'appelle l'encapsulation, et ce n'est certainement pas inutile.

D'ailleurs tester en temps réel si une touche est appuyé est bien mieux qu'une fonction appelée avec une rémanence, puisque dans ce dernier cas on a aucun controle sur le temps nécessaire pour la rémanence... Ca peut faire des trucs pas fluide...

Code: Select all

    // When I wrote this, only God and I understood what I was doing
    // Now, God only knows

Tu conçois bien que ça peut être problématique, sur le long terme.

En même temps quand on programme avec des ressources limitées faut faire avec. Encore qu'en Axe on peut mettre des commentaires, en basic z80 c'est même pas possible. Donc oui quelqu'un qui veut faire du retro engineering aura plus de mal qu'en Lua ou que dans un code fait sur l'ordi (quoique vu comme il y en a qui ne commentent jamais leurs codes...). Mais pour comprendre son propre code normalement ça devrait aller, puisqu'on connait notre façon de coder.

[Hayleia]

Étant d'accord avec le reste, je ne commente que la partie suivante.

Mais... ça n'empêche que ça reste toi qui le maintient.
En gros, est-ce que quelqu'un d'autre pourrait d'un coup se mettre à continuer/étendre le programme sans avoir à "déchiffrer" des codes non commentés ?
Ce n'est pas forcément souvent que ça arrive à l'échelle de programmes pour calculatrices, mais ailleurs, ce n'est pas forcément si rare....

Bon, en fait, j'ai parcouru les pages du topic moi même
Et j'ai écrit ici :

UPDATE

1. it sais "your pokemon was send to the box" but the box is empty...

Fixed. I am glad I coded Pokemon when I had no skills, I can understand my code in one minute

for me it's the opposite. For my early games, I now understand the code even less than back when I wrote it in 2001-05 O.O

Yeah, it is also true that I didn't have coding habits that would have made the code clearer, such as using evocative names for labels and variables. But I know which part of the code does what thanks to the Text commands (for example, I know where the Pokemon catching part is thanks to "Capturé !"), and then since there is absolutely no optimization, I guess easily what the code does and where the problem comes from (when there is a precise bug report).

Il reste que ça parle toujours de moi en train de maintenir mon code, oui. Mais comme le disent ces quotes, même sans commentaires, il y a tellement de commandes Text dans Pokémon que tu sais toujours où tu es sans avoir besoin de commentaires

En gros, est-ce que quelqu'un d'autre pourrait d'un coup se mettre à continuer/étendre le programme sans avoir à "déchiffrer" des codes non commentés ?

Oui. J'ai envoyé mon code à nikitouzz (en lui disant de ne pas toucher à tout puisqu'il se pouvait que je le fasse moi aussi de mon côté et on aurait eu l'air bien cons après pour merger) et il a ajouté un Pokédex dedans.

[Adriweb]

D'ailleurs tester en temps réel si une touche est appuyé est bien mieux qu'une fonction appelée avec une rémanence, puisque dans ce dernier cas on a aucun controle sur le temps nécessaire pour la rémanence... Ca peut faire des trucs pas fluide...

Cf. les interruptions en code bas niveau - c'est au programmeur de ne pas faire des choses qui prendront trop de temps dans le code de l'interruptHandler....
Ca posera effectivement problème s'il y a des timers quelque part (par exemple). Mais, ces problèmes de "désynchronisation", ca arrive partout, si c'est pas géré correctement.

[Hayleia]

(je n'avais pas vu ce post o.o)

Pourtant, c'est comme ça que j'ai commencé à programmer, en lisant du code sans jamais avoir programmé avant, sans jamais avoir vu du code avant

Dans ce cas là tu peux comprendre que s'il y a une ligne avec platform.window:invalidate(), à chaque fois qu'on est supposé changer l'affichage, et qu'éventuellement dans certains codes il y a un commentaire avant pour dire qu'on demande à actualiser l'écran, bah c'est une commande pour dire qu'on veut réafficher l'écran

Oui, comme ça je peux comprendre le DispGraph, mais pas le platform.window:invalidate().
Dans le code d'Adriweb, il est dans le "si touche appuyée" en gros. Et pourquoi, même si je comprends d'une manière ou d'une autre que ça rafraîchit l'écran, pourquoi le rafraîchir après avoir bougé X et Y sans avoir rien redessiné ? Vous me direz "évènementiel, tout se dessine tout seul". Je vous réponds "pas écrit, pas clair".

Je ne vois donc pas pourquoi les compilateurs C ne règlent pas ce problème si le seul argument en faveur de votre écriture est "le compilo le comprend comme ça" alors que nous on a plein d'arguments de clarté.

Ce n'est certainement pas le seul argument, c'est le seul que je connaisse, et celui qui me fait utiliser int *a. Après je suis sur qu'il y a une autre raison à ce "problème".

Ben c'est le seul argument que j'aie jamais entendu
C'est par exemple le seul argument que tu aies sorti

[m@thieu41]

Ben après tu peux te documenter un minimum
Parce qu'on comprends pas un code si on a jamais programmé sans faire un minimum d'effort

Par exemple, que fais Output(1,1,3) ? Pour toi c'est évident, pour quelqu'un d'autre non.
Autre exemple : tu comprends ce que fait pxl-on. Mais quelle est la différence avec point-on? Si tu ne cherches pas, tu n'auras pas ta réponse, même avec des noms aussi clairs...

Dans le code d'Adriweb, il est dans le "si touche appuyée" en gros. Et pourquoi, même si je comprends d'une manière ou d'une autre que ça rafraîchit l'écran, pourquoi le rafraîchir après avoir bougé X et Y sans avoir rien redessiné ? Vous me direz "évènementiel, tout se dessine tout seul". Je vous réponds "pas écrit, pas clair".

C'est écrit dans pleins de tuto pour qui sait chercher. Le but n'est pas de démontrer qu'un programme ne peut pas être compris si on fait pas un tuto en commentaire quand même ? --'
Dans ce cas : pourquoi tu ne documentes pas Repeat avant de l'utiliser dans ton code ?

C'est par exemple le seul argument que tu aies sorti

Oui j'ai bien dit que c'est le seul que je connaisse .

[Hayleia]

Ben après tu peux te documenter un minimum
Parce qu'on comprends pas un code si on a jamais programmé sans faire un minimum d'effort

Quand même, j'ai appris le TI Basic en cours d'espagnol, crois pas que j'avais internet avec moi

Par exemple, que fais Output(1,1,3) ? Pour toi c'est évident, pour quelqu'un d'autre non.

Cette commande est justement la première que j'ai comprise pendant ces cours d'espagnol. Si on veut être plus précis, c'était Output(1,X,"O".
Je me souviens encore de la parenthèse manquante et du guillemet final présent quand même. Rappel : je n'avais jamais programmé avant. Pourtant, j'ai bien compris que c'était ça qui dessinait le joueur à l'écran car il ne bougeait que selon l'abscisse X et était représenté par un O. J'ai tenté de modifier juste le "O" en "^" et ça marchait donc Output n'était plus obscure
Pour "moi" c'est évident, oui. Pour quelqu'un d'autre, je ne vois pas pourquoi ça ne serait pas évident si ça l'a été pour moi à l'époque où je ne savais rien faire.

Autre exemple : tu comprends ce que fait pxl-on. Mais quelle est la différence avec point-on? Si tu ne cherches pas, tu n'auras pas ta réponse, même avec des noms aussi clairs...

Ça, c'est plus un problème pour le programmeur que pour le lecteur
En général, un programme (on parle du Basic) ne comporte pas les deux commandes donc le lecteur n'a pas à se demander quelle est la différence.

Dans le code d'Adriweb, il est dans le "si touche appuyée" en gros. Et pourquoi, même si je comprends d'une manière ou d'une autre que ça rafraîchit l'écran, pourquoi le rafraîchir après avoir bougé X et Y sans avoir rien redessiné ? Vous me direz "évènementiel, tout se dessine tout seul". Je vous réponds "pas écrit, pas clair".

C'est écrit dans pleins de tuto pour qui sait chercher. Le but n'est pas de démontrer qu'un programme ne peut pas être compris si on fait pas un tuto en commentaire quand même ? --'
Dans ce cas : pourquoi tu ne documentes pas Repeat avant de l'utiliser dans ton code ?

Ben les tutos d'Axe sont quand même assez rares, et pourtant tout le monde s'en sort. Le seul truc pour débutants complets c'est le Documentation.pdf (les autres tutos étant des tutos spécifiques, comme "comment se servir des variables externes une fois qu'on sait déjà faire de l'Axe") inclus dans le zip, qui explique effectivement ce que fait DispGraph, mais en même pas une ligne alors qu'Adriweb en a mangé trois pour me dire ce que qu'était platform.window:invalidate() (une ligne vite fait comme celle de DispGraph et deux qui expliquent pourquoi ce nom à rallonge) et même avec ces trois lignes, je ne sais toujours pas que le rectangle se dessine tout seul. Dans le Documentation.pdf, il est écrit pourquoi la sprite se dessine, c'est parce qu'on l'a demandé avec la commande qui précède le DispGraph.

Quant à Repeat, inutile de le documenter, c'est un mot anglais
Ok, Répète touche(15) ça veut rien dire, mais en lisant d'autres lignes, tu vois des If et des End qui correspondent, des While et des End qui correspondent, des Repeat et de End qui correspondent, et ayant compris comment les deux premiers fonctionnent, tu comprends le troisième (en tout cas, ça a marché pour moi en Basic, le plus dur ayant été de comprendre pourquoi certains If n'avaient ni Then ni End, surtout avec l'absence d'indentation).

[mdr1]

Sauf que

• tu ne peux pas avoir 50 initiales,

C'est bien le problème. ^^

• de toute façon, personne n'utilise 50 variables, en tout cas pas en Axe,

À cause du nombre de lettres dans l'alphabet. ^^

• si tu utilises vraiment 50 variables, rien ne t'empêche d'en déclarer, et puisque d'après le premier point, tu ne peux pas avoir 50 initiales, autant déclarer 50 variables avec un nom potable.

C'est bien ça, on se ramène à la meilleure solution : déclaration de variables avec un vrai nom. ^^

Si ça existe, tu peux très bien mettre L5+02→°MaVariable n'importe où dans ton code, y compris à la fin pour ne pas nuire à la lisibilité, et tu obtiens une variable qui s'appelle MaVariable avec laquelle tu peux faire MaVariable++ et tout ce que tu veux.

Bon bah voilà, parfait. Tout juste comme en Lua (sauf pour le "++").

J'ai toujours parlé des programmes "normaux" ou "de débutants", c'est juste toi qui a encore inventé quelque chose dans mes paroles en disant que je parlais de programmes optimisés.

Mmh, je vois, c'est toi qui définis les règles du jeu, maintenant.
Je te rappelle que la discussion est née de la liste d'Adriweb caractérisant les langages dans leur globalité et non juste pour les noob.

Les programmes "normaux" en Lua utilisent tous le "platform.window:invalidate()" dont j'ai parlé plus tôt et qui n'est pas clair selon moi. Déjà, à quoi sert "platform" ? À dire que la fenêtre dont on va parler n'est pas une fenêtre de mon Android ? Inutile. Ça ne fait que rallonger la ligne et embrouiller le lecteur en lui faisant croire qu'il y a des choses à lire. La partie "window" est la seule sur laquelle je n'ai rien à dire. Quant à "invalidate", ça a beau être utilisé dans beaucoup de librairies graphiques, ça reste obscur.

Ce que tu dis est absurde. La plupart des bons langages sépare ainsi de manière événementielle le dessin, ce qui découpe bien le code et le rend bien plus lisible.

Faut l'inventer quand même la ligne qui ne serait pas claire dans ce code.

Encore plus clair en Lua (CF Adriweb).

C'est bien ce que je dis, le code est mal présenté. Même quand on fait une ligne très longue, on doit être capable de la mettre sur plusieurs niveaux, correctement indentés et commentés.

Ah mais ça on peut le faire en Axe aussi. C'est juste qu'on en a jamais besoin puisque notre calcul est au début, tient sur la ligne (encore une fois, ne prenez pas mes programmes pour exemple), et le →Variable est à la fin, au pire sur la ligne d'en dessous, comme ça :

Code: Select all

LeDébutDuCalcul LaFinDuCalcul
→CeciEstMaVariable


Il n'y a que vous pour faire ça :

Code: Select all

CeciEstMaVariable = LeDébutDuCalcul ##notez les espaces inutiles de part et d'autre du "="
                    LaFinDuCalcul ##je dois aller à la ligne puisque j'ai gâché de la place


Le théorique m'est égal, je veux voir ton code illisible sur plusieurs niveaux commentés. Quand à ton code, je préfère ceci :

Code: Select all

CeciEstMaVariable =
   LeDébutDuCalcul LaFinDuCalcul

que ceci :

Code: Select all

LeDébutDuCalcul ## je dois aller à la ligne puisque je suis un abruti
LaFinDuCalcul → CeciEstMaVariable ## notez les espaces inutiles de part et d'autre du "="

Bref, tout ça pour montrer que ton exemple est absurde.

Les lignes en Axe n'ont pas besoin d'être longues pour être incompréhensibles. Des flèches que l'on met deux fois de suite,

Tu vas pas me dire que 0→A→B est illisible quand même -.-
Et les débutants ne l'utilisent pas, il chargent 0 deux fois, comme dans mon exemple ci-dessus.

Je ne parle pas de ça, mais de ça :

Code: Select all

:0→→°G3

(trouvé dans le code de Runer dont tu as parlé)

des symboles degré

Que les débutants n'utilisent pas non plus.

Arrête avec les débutants ! On parle du langage lui-même !

et exposant r qui se baladent partout

D'abord, petite précision pour ceux qui ne connaissent pas l'Axe (ceci ne vise personne) : le ^^r, c'est ce que sort TokenIDE. En vrai, ça ressemble à ^r. C'est tout de suite moins long et moins moche.
Deuxièmement, chez les très débutants, il n'y a pas non plus ce ^r, mais on va éviter de parler d'eux quand même.

Pour l'exposant, je le sais bien, quand aux débutants, CF ci-dessus.

Et chez les pas trop débutants, il y a ce ^r, mais soit toujours après une "}", soit toujours après une commande de dessin. Même si tu ne comprends pas son but exact, tu comprends toujours que la commande de dessin dessine, et ce n'est pas le ^r qui va t'empêcher de comprendre les {}, qui certes ne parlent pas d'elles mêmes mais qui ne sont pas moins claires que l'étoile en C (surtout avec le coding style ridicule en C que les gens utilisent en écrivant int *a au lieu de int* a).

Mdr, on passe au C maintenant. Sauf qu'en Axe, tu as le r, le double r, le degré, la double-flèche etc. on a l'impression de coder en BrainFuck !

Sauf qu'encore une fois, si on cherche à étudier la lisibilité de l'Axe, il ne faut pas lire mes programmes. Mais même en parlant de ce programme, un commentaire par étape est inutile puisque si, il y a des étapes, et elles s'effectuent bêtement de gauche à droite. Inutile de commenter.
Quand à la maintenance, pourquoi faire ? On n'a pas de problèmes d'API 2.0 ou je ne sais quoi, nous.

Quoi quoi quoi ? Tu dis que les commentaires ne servent à rien ? Tout commentaire sur cette affirmation sera également inutile dans ce cas.

Non, tu confonds tout. Tu n'as jamais utilisé mon programme SaisieRPN visiblement. Il permet de saisir les calculs en RPN parce que c'est plus rapide, c'est tout. Mais ils sont affichés normalement.

Je ne confonds rien du tout. Tu crois que mon programme quand il tourne, il affiche et des trucs illisibles à l'écran ? Non.
Donc toi quand tu écris ton calcul, tu l'écris en RPN illisible selon certains mais plus intuitif selon toi tout comme moi j'écris mes calculs dans l'ordre illisible selon certains mais plus intuitif selon moi, et ce sans que cela ne change rien au résultat final chez toi comme chez moi.

Je répète : l'affichage avec SaisieRPN est normal. C'est la saisie qui est en RPN. Alors que toi, ton programme Axe se voit exactement de la même façon qu'il se saisit. Donc parler d'illisibilité pour SaisieRPN n'a pas de sens.

Oui mais il reste le "invalidate"
C'est clair pour tous ceux qui ont déjà utilisé une librairie qui utilise ce mot, mais quelqu'un qui n'a jamais programmé ne comprendra rien à cette ligne. Il ne comprendra rien non plus à mes lignes d'Axe mais encore une fois, on ne parle pas de mes lignes d'Axe. Par contre, il comprendra le code qui déplace un rectangle. Pas le While 1, pas les numéros dans les getKey(), mais il comprendra quand même que ces getKey vérifient l'appui sur des touches, qu'ils font varier la position (X,Y) et que Rect dessine le rectangle (surtout s'ils ont déjà lancé le programme avant d'étudier son code).

"invalidate", que c'est dur à comprendre dis-moi... Tu dis que le débutant pourra comprendre ce code dans sa globalité en laissant de côté les détails (comme les r, degrés et compagnie). Tu te contredis, tu disais tout à l'heure que ton mode d'écriture en Axe RPN était justement plus pratique pour comprendre les choses en profondeur.


Hayleia, tu es en train de complètement modifier la discussion de base. Elle portait sur le fait qu'Adriweb disait que l'Axe est pratiquement fait pour être illisible. À la place, tu dérives le sujet en parlant du survol à l'oeil d'un programme par un débutant qui n'a quasiment jamais programmé ni même appris le langage, ce dont on se fiche ici tous royalement. Parler du débutant qui va comprendre un programme de 10 lignes comme quoi il permet de déplacer un rectangle, tel n'est pas le sujet ici. Parler du "débutant" qui crie horreur devant platform.window:invalidate() qu'il ne connaît pas alors que c'est la première chose qu'on apprend, c'est comme dire "Le Java est illisible à cause du System.out.println(...)". Et enfin, nous dire que tu es très bien capable de lire ton propre code ne prouve en aucun cas que l'Axe est plus lisible que le Lua.