Acid, le lisp-like de la communauté !

En soi, c'est très exactement ce qu'il propose : repousser tout ce qui n'est pas la base à plus tard.

Le pire, c'est ce que tu dis est très souvent juste (là, tu te contentes d'approuver ce qu'il dit), mais pense aussi à la forme de tes messages. Même si je n'approuve pas le message juste au dessus, je le comprends parfaitement. Ça ne te couterai rien de ne pas mettre de petites piques dans tes messages en permanence.

Et commencer par implémenter ces « fonctionnalités de base » (en fait, la plupart sont déjà probablement trop compliquées) avant de tirer des plans sur la comète pour la suite ? Ça me paraît être une excellente idée

Est-ce que quelqu'un pourrait, s'il vous plaît, reformuler pour moi ce message pour qu'il ne contienne pas de "petite pique" qui fait "chier le monde" ?

Commencer par implémenter ces « fonctionnalités de base » me paraît être une excellente idée

Par exemple. Je pense ne pas avoir déformer le message.

Non, c'est même exactement le même. Merci de confirmer que c'était bien l'interlocuteur qui posait problème.

N'importe quoi. À chaque fois que tu interviens depuis plusieurs messages on a l'impression que tu fais le coup du binôme qui en branle pas une et qui se permet de la ramener.

Essaie d'éviter de donner l'impression que tu sais tout et que ta solution est la meilleure. La correction de Gabbro est un conseil, le message original un conseil suivi d'une pique.

Tu as raison, le problème est l'interlocuteur. Par contre c'est pas celui que tu penses.

Non. Pour être clair : ça fait depuis le début du sujet que vous partez complètement dans la mauvaise direction, et que de fait rien n'avance. J'ai pourtant précisé plusieurs fois que si je n'implémentais rien, c'est parce que ça n'aurait aucun intérêt pour vous comme pour moi : implémenter ce genre de langage, c'est la partie boilerplate de mon travail quotidien. Ça ne m'empêche pas de donner des conseils. Maintenant, si ces conseils vous déplaisent, que ce soit parce que vous les trouvez condescendants, piquants ou simplement vexants, le problème vient effectivement de vous.

La "correction" de Gabbro va exactement dans ce sens : d'accord, c'est très satisfaisant de s'auto-congratuler et de faire semblant que tout va bien. Mais la réalité des choses est piquante, et ce n'est pas parce qu'on l'enlève d'un message qu'elle disparaît. La partie qui disait que vous avez mis (beaucoup) trop de choses dans vos spécifications était importante, et vous n'arriverez jamais à implémenter ça tels que vous êtes partis, que ce soit après le bac ou pas. Vous êtes exactement dans la situation où quelqu'un vient raconter qu'il va écrire un nouvel OS en détaillant précisément toute l'interface graphique et les fonctionnalités réseaux alors qu'il est manifestement évident qu'il n'a pas la moindre idée de comment écrire un noyau. Et comme dans cet exemple, quand on vous le fait remarquer (y compris avec des gants : vous êtes furieux parce que le message venait de moi, mais au fond de vous-mêmes vous savez bien qu'il n'avait rien de méchant), ça vous vexe et vous vous réfugiez derrière la condescendance des messages qui ne participent pas au cercle des auto-satisfaits pour refuser de voir les choses en face. Vous voulez vous planter ? Très bien, continuez exactement comme ça. Mais ayez au moins l'humilité d'accepter qu'on vous le dise.

PS : et pour citer quelqu'un du site d'où on vient et qui avait bien raison : mon but est de vous aider, pas d'être gentil. Libre à vous d'accepter cette aide ou pas, mais si vous la refusez uniquement parce que la forme est "piquante", ça ne va pas vous faire plaisir, mais vous êtes de parfaits idiots.

Je ne sais pas si tu réponds à mon message ou pas, mais si oui, je n'ai il me semble jamais dit qu'il ne fallait pas définir son langage avant de l'implémenter.

Bon, bon bon bon bon. Et si on évitait de tendre l'atmosphère. J'ai masqué deux messages qui lançaient les hostilités. Ces masquages sont un appel au calme, pas une sensure, si le calme revient, il se peut même que je les démasque. L'idée étant de ne pas défacer les forums.

Une fois cela dit, si une personne ne croit pas en un projet ou un atelier, c'est son droit, et c'est une bonne chose qu'elle le dise. Mais une fois que l'avis a été donné, il serait agréable que cette personne accepte aussi que son avis ne soit pas suivi et advienne que pourra du projet qu'elle critique.

Je vous conseille de ne reprendre les discussions que si une des deux conditions suivante est remplies:

• vous avez un avis neuf sur le projet –i.e qui n'a pas encore été donné–.
• vous êtes totalement calme, et sans frustration.

Merci à tous, et bonne chance pour ce projet.

Je présente mes excuses pour m'être emporté.

Bon c'est tout à fait calmement que je dis ça :

Eusèbe, il n'y a aucun mal à dire ce que tu penses, mais puisque tu t'y connais et que tu vois que les choses ne vont pas dans le bon sens selon toi, pourquoi te contenter de dire que ça va foirer plutôt que d'aider, notamment en prévenant les gens qui interviennent ici des difficultés concrètes auxquelles ils se préparent à faire face, et en leur donnant une ou deux pistes pour les anticiper ?

Parce que, certes, avec tout le mielleux et le sucre qu'on veut, "donner son avis, même contraire, c'est sain, c'est une bonne chose, blabla", mais partager avec les gens le recul que tu as visiblement, c'est encore mieux. Et je pense que c'est ce qui agace les gens ici : ils essayent de se lancer dans un projet qu'ils savent ambitieux, leur dire qu'ils font n'imp sans leur expliquer ce qu'ils devraient faire (enfin si, ça tu le dis) et surtout pourquoi, ou bien les rabaisser gratuitement, c'est du pareil au même : ça les découragera sans jamais les aider.

Et si on se posait quelques jours pour vraiment réfléchir au lieu de s'emporter ?

Aujourd'hui, on a des specs qui d'après certains sont trop complexe. Et il y a une chose qui est vraie : nos specs ne sont pas adaptées à notre développement, nous avons un langage détaillé pour des implémentations à l'état embryonnaire.

Et si on s'organisait par étapes et qu'on revoyait nos specs pour qu'elle devienne ce qu'elles auraient toujours dû être : les specs d'un langage simple à implémenter et à coder. C'était le principe de base, coder un lisp-like car c'est plus simple.

Pour finir, je propose que l'on organise nos specs par étapes (et qu'on évite de les brûler) :

• Etape 1 : On définit les règles de bases : Quelle est la syntaxe de chaque instruction ? Comment les paramètres peuvent-ils être séparé ? Et aussi les principes techniques : Est-ce qu'on compile en AST Python ?

• Etape 2 : On définit ce que notre langage fournira par défaut : les fonctions, les types, et ce qui fera parti d'une bibliothèque (standard ?)

• Etape 3 : On définit les fonctionnalités par défaut de notre langage en gardant à l'esprit le principe du langage simple à implémenter et à utiliser.

• (Etape 4) : On améliore nos specs.

• Et on implémente (entre l'étape 3 et 4), en patientant le temps et que nos cerveaux aient bien travaillés qu'un maximum de volontaires soient disponibles.

En ce qui me concerne je suis plutôt d'accord avec Eusèbe sur un point : vous avez largement assez de specs pour commencer à faire vos essais. De toute façon vous ne réussirez pas à tout coder comme il faut du premier coup (ce n'est pas de la condescendance : personne ne code comme il faut du premier coup). Conscients de ça : codez un truc, voyez si ça marche, ce qui bloque, pourquoi ça bloque, corrigez, arrêtez vous un peu plus loin, grattez-vous la tête, etc.

Sans ça vous ne commencerez jamais à coder. Il faut que vous fassiez des erreurs, et que vous les fassiez le plus tôt possible.

Je ne souhaite pas rajouter des specs mais plutôt les répartir en étapes pour mieux avancer.

La plupart des contributeurs passent leurs bac, ils n'ont pas le temps de coder, mais ils peuvent donner rapidement leur avis ici, c'est donc le moment idéal pour essayer de s'organiser.

Ce que je veux dire, c'est que là vous en êtes déjà à 11 pages de discussion. À ce niveau, passer une petite heure à faire deux trois essais en quick'n dirty vous sera largement plus profitable que de continuer à discuter.

Ça vous donnera du concret sur lequel réfléchir et discuter. Par exemple pour répondre à la question "AST Python ou pas ? " : essayez, voyez ce que ça vous apporte, et écartez la solution en toute connaissance de cause si ça vous va pas.

Sans petits codes de test à droite à gauche, vous n'avancerez plus.

Oui oui, dans ce cas, je suis d'accord.

Ça vous donnera du concret sur lequel réfléchir et discuter. Par exemple pour répondre à la question "AST Python ou pas ? " : essayez, voyez ce que ça vous apporte, et écartez la solution en toute connaissance de cause si ça vous va pas.

Si le but est que chacun fasse son implémentation, c'est pas spécialement une bonne idée de le "fixer". Ceux qui le font en Python peuvent pour gagner du temps mais dans le cas général c'est trop dépendant de l'implémentation pour mériter une discussion.

Ce qui manque c'est probablement des précisions sur la spec (bien clarifier les deux versions plutôt que de dire que des trucs optionnels, préciser les built-in sur les opérations math entre autre, etc.)

Est-ce que vous êtes sûrs d'avoir vraiment besoin de fixer des spécifications rigides à votre langage ? Partir sur une base commune, c'est une bonne idée, ça permet de comparer les solutions et les choix d'implémentation ou de sémantique de chacun. Mais vous n'êtes pas le comité de normalisation du prochain C : personne n'utilisera ce langage "dans la vraie vie", il est là uniquement pour vous permettre d'apprendre des choses liées à la compilation ou l'interprétation. Partant de là, il est inutile de vouloir à tout prix définir des spécifications uniques ou parfaites : vous avez l'avantage énorme de ne pas avoir d'utilisateur, profitez-en !

Concrètement, partez sur une base commune minimaliste, et laissez chacun implémenter ce qu'il veut dessus. Et ne cherchez pas à vouloir tout définir proprement et précisément à tout prix : s'il reste des points flous (par exemple, est-ce que les entiers sont sur 32 bits ou sont des vrais entiers), ce n'est pas un problème, chacun l'interprétera comme il l'entend (et vous en parlerez une fois les résultats obtenus). Encore une fois, ne tombez pas dans le piège qui consiste à croire que vous visez un langage utilisable : ça paraît être une bonne idée, mais c'est partir dans une direction qui vous fera perdre beaucoup de temps et vous fermera beaucoup de portes. Je rejoins un peu ce que dit Nohar ici (et je crois que je l'ai dit il y a quelques semaines) : la bonne conception d'un langage, c'est un travail difficile, et ce n'est pas en essayant de faire ça parfaitement avant même d'avoir implémenté quoi que ce soit que vous y arriverez. Vous devez commencer par programmer, et c'est avec beaucoup d'expérience, d'utilisation de langage variés et d'implémentations de proofs of concept que vous aurez les idées un peu plus claires sur le sujet (et que vous pourrez alors avoir des discussions raisonnables). Ça ne doit vraiment pas être votre priorité actuelle.

–

J'ai parlé d'une base minimaliste plus haut. Le Lisp a ses vertus, et dans l'absolu ce n'est pas une mauvaise idée pour implémenter un langage jouet (notamment parce que la syntaxe est très facile à analyser, ce qui permet de se concentrer sur les problèmes intéressants), mais je ne pense pas que ce soit le plus adapté ici. C'est un langage très lié au paradigme fonctionnel, et sans l'avoir pratiqué un minimum (c'est-à-dire pas en ayant écrit une lambda en Python et une fonction récursive une fois), c'est un peu difficile de comprendre où on va; et pour ceux qui veulent en profiter pour apprendre le fonctionnel (bonne idée !), je ne pense pas que l'implémenter soit une bonne méthode (pratiquez plutôt, avec un langage comme OCaml qui est à mon avis un très bon choix pour découvrir et continuer - mais il y en a d'autres. Posez la question.)

Je vous conseille plutôt un langage impératif simple, dont vous maîtrisez à peu près tous les concepts de base. J'avais (ou quelqu'un d'autre avait) mis un lien vers un cours de thizanne sur progdupeu.pl, c'est déjà une bonne base : quand vous aurez implémenté ce qu'il propose avec les suggestions, ce sera déjà un petit succès. Vous pourrez ensuite par exemple vous intéresser à la compilation, et rien qu'avec un langage aussi minimaliste, vous aurez déjà suffisamment de boulot pour vous occuper quelques mois

Si vous voulez vraiment partir sur Lisp (je me répète : sans vous familiariser avant avec ce genre de langage, je pense que c'est un mauvais choix et un piège), et que vous voulez réviser un peu vos spécifications pour partir sur une base plus raisonnable (je pense que c'est indispensable), je posterai sans doutes quelques idées demain.

Ça me plaît plus quand tu t'exprimes comme ça, on va pouvoir s'entendre.

Sinon, je suis d'accord qu'il est temps de commencer à coder. Après, pour le choix du langage, je n'ai pas d'avis tranché sur la question, donc je ne me prononcerai pas.