pulkomandy a écrit 1928 commentaires

Le client Mender était écrit en Go au moins depuis 2016 d'après https://github.com/mendersoftware/mender/commits/69da9a6a90c73fd218ad0d34addfc7617371c246/client.go?browsing_rename_history=true&new_path=client/client.go&original_branch=master

Donc effectivement l'article est un genre de rétrospective?

Mais vraissemblablement il a suffi d'un (ou plusieurs) client prêt à payer assez cher pour avoir une version du client fonctionnant sur QNX ou un autre système embarqué où c'est compliqué de faire du Go pour convaincre Mender de changer d'avis. Ils n'avaient pas du tout imaginé ce cas de figure lors de l'écriture de l'article, je pense? En tout cas ce n'est pas listé dans les arguments pour ou contre dans la comparaison.

étiquettes à fusionner: go et golang

C'est rare que la réponse à "le logiciel est compliqué à maintenir" soit "il faut tout réécrire à partir de 0".

Le but de Wayland, dès le début, c'était de simplifier les choses en retirant des fonctionalités. Ce n'est finalement pas très surprenant que ça n'est pas très utilisé parce qu'il manque des fonctionalités.

Ça montre aussi l'une des difficultés de la façon de travailler dans "gnu/linux": le système est un assemblage de composants développés par différentes équipes ou personnes. Il est difficile dans ce contexte de faire des gros changements d'architecture qui mettent en jeu plusieurs de ces composants. Résultat: Wayland ne s'en sort qu'en mettant à disposition une couche de compatibilité avec X11, qui fait que les problèmes qu'il était sensé faire disparaître ("X11 c'est compliqué") sont en fait toujours là, mais avec une couche logicielle de plus.

Et le discours dans l'article va pasmal dans ce sens aussi: Wayland s'intègre mal dans les applications existantes. L'article dit que ça marche peut-être très bien pour les smart TV, pour avoir essayé d'aider un collègue sur un système embarqué utilisant Wayland, je n'en suis pas convaincu. On voulait faire un truc simple: placer deux fenêtres, une en haut et une en bas de l'écran (résolution fixe, on peut coder en dur la taille et position). Mon collègue m'a dit que ça ne semblait pas possible. Au début je ne l'ai pas cru. Pourtant il avait raison: pour faire ça, il faut développer son propre gestionnaire de fenêtres. On s'est arrangés pour se débarasser de Wayland dans ce projet…

Qu'est-ce qu'on entend par passerelle dans ce contexte?

Au sens xmpp, il existe un mécanisme qui permet à un serveur xmpp de se connecter comme un client à un autre réseau de messagerie. Pour ça il faut ouvrir une session par utilisateur du serveur, et le serveur doit connaître (et stocker en clair) les mots de passe des services auxquels il se connecte.

Ici l'idée semble plutôt d'avoir une connexion serveur à serveur, ce qui se fait naturellement aussi bien dans Matrix que dans XMPP, tous deux étant des protocoles fédérés. Cela peut rendre les choses transparentes entre les deux protocoles: les clients xmpp pourront se connecter à des salons Matrix, et inversement, les salons de discussion du serveur xmpp seront disponibles directement via le réseau Matrix.

Je ne pense pas qu'une passerelle externe permettrait ce niveau d'intégration dans les 2 directions?

Gemini est conçu pour faire que de la lecture seule globalement. On oublie dont les sites de vente en ligne, la réservation de billets de train, etc. ça fait donc moins bien que le Minitel.

Il peut trouver ses usages mais ça ne remplacera pas une grande majorité des usages du web.

des navigateurs qui restreignent l'utilisation de services non écologiques par défaut

Oui mais la question est, qu'est-ce qui est vraiment non-écologique dans une page web.

Comme le disent les commentaires au-dessus, c'est parfois contre-intuitif, et en plus c'est difficile à mesurer parce que ça implique du matériel un peu partout sur internet (le terminal qui lit la vidéo ou affiche la page, le serveur qui envoie les données, les routeurs au milieu). Et c'est pas sûr que ça fasse une différence massive parce que un équipement qui ne fait rien ne consomme pas forcément beaucoup plus qu'un équipement qui transmet un flux vidéo.

Donc c'est bien de vouloir rendre la "consommation" de la page visualisée, mais avant ça il faudrait pouvoir savoir ce qui consomme vraiment des ressources.

Oui la migration est déjà en cours pour les listes dont je suis responsable.

Depuis environ 1 an, il y a de nombreux problèmes de mails qui n'arrivent plus chez différents abonnés des listes hébergées chez free. Je suppose que Free a préféré abandonner le service plutôt que de passer plus de temps à essayer de régler le problème.

Le but du journal est surtout de prévenir si jamais vous avez de vielles archives de listes de diffusion à récupérer avant que le service soit coupé plus ou moins dans l'indifférence générale.

Je n'ai pas été clair apparemment, il y a confusion entre Caprice Forever (windows, toujours maintenu) et Caprice Reloaded (Linux et Windows, projet mort depuis 10 ans).

Ces deux projets sont tous les deux des forks de Caprice 32 mais à part ça, ils n'ont rien en commun.

Le lien dans votre message pointe sur une page qui s'appelle "Caprice Forever" et parle bien de Caprice Forever.

Euh il faut pas tout mélanger, Caprice Reloaded c'est un projet sur lequel j'ai pas mal travaillé (mais pas tout seul) et ça fonctionnait sous Linux (mieux que sous Windows). Le projet était un genre de "WinAPE, mais pour Linux".

Il y avait pas mal de problèmes dedans liés à l'utilisation de WxWidgets et WxFormsBuilder (il fallait utiliser une version patchée de ce dernier…) plus divers problèmes de fiabilité du coeur de l'émulateur malgré les efforts de Ramlaid qui en avait réécrit de gros morceaux. En particulier l'émulation du contrôleur de disquettes était assez mauvaise.

Le projet est abandonné depuis longtemps. Tout le code de Caprice 32 avait été réécrit en C++ ce qui a rendu compliqué la collaboration avec les nombreux autres forks de Caprice 32, dont Caprice Forever vers lequel ce lien pointe.

Le point le plus intéressant de Caprice Reloaded était d'avoir une interface graphique similaire à celle de WinAPE, avec un debugger, etc. Mais ça n'a jamais vraiment abouti.

Aujourd'hui le projet est abandonné, les efforts se concentrent sur ACE, avec la version Haiku pour ma part et du travail en cours mais pas fini et non diffusé pour une version Linux pour les deux autres développeurs qui avaient participé à Reloaded. Malheureusement ce n'est pas sous licence libre (par choix de l'auteur de ACE qui préfère garder ses secrets).

Je vois pas le rapport avec les économies.

Amstrad avait prévu de pouvoir connecter un lecteur de disquettes mais ils (ou plutôt Locomotive Software qui s'occupait du logiciel) ont développé la ROM correspondante après la sortie de la machine. Ils avaient tout prévu pour le faire, avec un mécanisme générique pour ajouter des ROMs a posteriori, qui est utilisé encore aujourd'hui.

Par exemple on peut (avec du matériel de ma conception) connecter une carte microsd ou une clé USB et y accéder avec une ROM qui remplace l'AMSDOS en apportant de nombreuses fonctionalités supplémentaires (répertoires, gestion de différents supports de stockage, …).

Cela aurait été impossible si la gestion des disques avait été "en dur" dans la ROM interne.

De plus, la ROM AMSDOS peut se substituer complètement au BASIC, on obtient alors un CPC qui va démarrer directement sur une disquette pour lancer un logiciel CP/M. Cela a pu être utilisé dans des applications industrielles (pilotage de chaîne de montage) ou ainsi la machine peut démarrer directement avec le logiciel dédié.

C'est plutôt bien pensé tout ça. Et je doute que ça fasse des économies, cela a forcé à utiliser 2 ROMs (le système + l'AMSDOS) là ou ils auraient pu tout rentrer dans une seule.

Ce schéma non légendé n'est vraissemblablement pas conçu pour être sorti de son contexte: il est effectivement incompréhensible sans lire avant la page dont il est tiré qui fournit les données brutes.

Je tente une légende:

Une flèche a->b indique que la proposition 'a' a reçu plus de votes que 'b'. Le nombre indiqué est la différence de points entre les deux.

La proposition en bleu en haut du graphe a gagné sur toutes les autres.

Les propositions dans le schémas n'ont qu'une description courte, les détails sont dans les pages mises en lien.

Mais c'est effectivement quelque chose qu'on peut repprocher aux méthodes de vote Borda/Condorcet: pas de résultat sous forme d'un simple score en % pour chaque candidat et de classement final. Ce qui complique un tout petit peu l'interprétation des résultats au-delà de la simple détermination du gagnant. Mais il y a l'avantage qui va avec: on a un peu plus d'information à interpréter

À noter que le choix gagnant implique un changement du contrat social (SC pour « social contact ») donc il n'est pas exclu qu'il y ait encore des débats pour arriver au résultat attendu.

La proposition contient le changement précis qui doit être appliqué et a obtenu, si je lis bien les résultats détaillés, une majorité qualifiée suffisante (2/3 des votants).

Sur quoi peut-il y avoir encore débat? (vraie question, je ne connaît pas en détail l'organisation du projet Debian).

Il semblerait plutôt (vu la liste d'options de vote possibles d'une part, et le vote très en faveur de ce résultat d'autre part) que les débats ont déjà eu lieu et que ce vote n'était quasiment plus qu'une formalité pour valider la décision déjà prise après cette discussion.

Perso, je prends des cartouches, mais surtout parce que la cartouche me parait plus durable que la carte SD que je vais devoir acheter pour stocker les jeux de 20 gigas qu'on trouve.

ça m'étonnerait, aujourd'hui les jeux sur cartouches (je crois qu'il n'en reste que chez Nintendo?) utilisent de la mémoire flash qui n'a pas une meilleure durée de vie que celle utilisée dans les cartes SD.

La durée de vie de ce type de support est peut-être de 10 ou 20 ans, ensuite il est probable qu'on commence à voir des corruptions sur les cartouches et les cartes SD surtout si elles ne sont pas utilisées.

On est loin des durées de vie des "mask ROMs" utilisées quelques années auparavant qui peuvent conserver leurs données quelques dizaines d'années supplémentaires.

Les deux solutions qui marchent:

• Compter sur soi-même pour avoir un plan de backup,
• Faire confiance à une plateforme en ligne (Steam, Stadia, ou autre forme) pour gérer ça et pour pouvoir continuer de retélécharger ou d'accéder à ses jeux dans le futur.

Tu as comparé le moins cher.

Oui je voulais juste dire que ce n'est pas très cher dans les deux cas.

Bref, la licence sur le nom n'est pas le sujet du prix, le sujet est combien tu dois mettre au minimum sur la table pour fabriquer un CPU minimal en production. Je veux 1000 unités d'un CPU qui me fait 100 additions par secondes avec 4 KB de RAM (nombre au pif complet), combien ça me coûte en SPARC et combien en RISC V? Je ne connais pas les prix mais rien qu'à voir la différence de taille entre les intervenants SPARC et ceux RISC V, j'ai une idée que ce n'est pas la même ordre de grandeur au détriment de SPARC.

Probablement, le RISC-V a commencé par se développer sur le marché des microcontrôleurs sur lequel SPARC n'avait pas forcément mis les pieds. Je ne pense pas que ça serait impossible de le faire, mais c'était pas le marché ciblé.

Wikipedia me parle de GPL, d'où ma remarque sur la différence copyleft vs copyfree.

Il s'agir de la license de plusieurs implémentations de SPARC en VHDL, pas de la license de la spécification du jeu d'instructions et de l'architecture.

Le projet GNU ne dit pas que ces systèmes ne sont pas totalement libre. Il dit qu'il ne peut pas soutenir ces projets car ils aident à l'installation de firmware non libres sur ton OS. C'est totalement différent.

Je peux parler pour le cas de Haiku que je connaît bien.

L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:

• Wonderbrush, un outil de dessin
• liblayout, une bibliothèque pour faciliter la réalisation d'interfaces graphiques, utilisée par le lecteur PDF BePDF

Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.

Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).

Non tu pars d'une interprétation que tu inventes.

Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?

On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.

Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?

Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:

• Qu'est-ce que veut dire "Hare"? Est-ce que c'est le langage de programmation ou est-ce que c'est l'équipe qui le développe? Cela a des conséquences si une autre équipe voulait assurer le support pour des systèmes propriétaires tout de même, est-ce que l'équipe actuelle y serait franchement hostile, ou est-ce qu'ils soutiendraient l'initiative en étant bien content d'être déchargé de ce travail de support?
• Qu'est-ce qu'un "système propriétaire"? J'ai tenté de donner une définition qui n'est bien évidement pas la bonne, mais personne n'a su en donner une autre.
• Qu'est-ce que "supporter un système" pour un langage de programmation?

Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.

je peux dire des bêtises la dessus mais RISC-V me semble plus accessible au commun des mortels et répond à des besoins plus spécialisés qu'un CPU généraliste pas cher comparé à faire pareil en libre.

Oui, ce n'est pas la question, c'est super que RISC-V propose une architecture mieux conçue et c'est super que ce soit libre.
Et il était tant de mettre SPARC à la retraite.

C'est juste que je ne vois pas en quoi RISC-V serait "la première architecture libre" dans ce cas (pourtant je vois cet argument répété partout). Je ne vois pas en quoi SPARC n'est pas une architecture libre.

Mais peut-être devrait-on en effet dire que RISC-V est le premier CPU copyfree. Ou le premier libre et utilisable sans trop de fric. Ou le premier libre et utilisable sans réacteur nucléaire. Ou le premier libre et multi-usage.

La license pour avoir le droit d'utiliser le nom "SPARC" coûte 99 dollars (prix inchangé depuis au moins 1997, en tout cas c'est ce que j'ai trouvé sur les versions archivées par archive.org de sparc.org). ça me semble plutôt raisonable.

L'adhésion à RISC-V à un niveau suffisant pour pouvoir faire une utilisation commerciale de la marque RISC-V, c'est 2000$ pour une entreprise créée il y a moins de 2 ans et avec moins de 10 employés, et 15000$ entre 500 et 5000 employés par exemple.

Donc c'est raté pour l'argument "sans trop de fric".

Dans les deux cas, les spécifications sont accessibles sur le site internet des fondations respectives. Celle de RISC-V est sous licence CC-BY, celle de SPARC, il n'y a pas l'air d'avoir d'infos de license (ou j'ai pas cherché au bon endroit). Est-ce que c'est ça qui fait la différence?

On peut re-citer la phrase qui est sur le site de Hare:

Hare does not, and will not, support any proprietary operating systems.

Je traduis:

Hare ne fournit pas et ne fournira pas de support pour aucun système propriétaire.

ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:

• Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.

• Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.

Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.

D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.

Je ne vois rien qui indique que les processeurs Elbrus sont compatibles SPARC. Il y a bien eu des CPU SPARC fabriqués par le MCST mais on dirait qu'ils sont passé à autre chose avec Elbrus.

En regardant un résumé du jeu d'instruction ça ressemble vaguement à du SPARC mais ce n'est pas compatible.

Je ne vois toujours pas la différence entre SPARC et RISC-V.

Oui, aujourd'hui SPARC est mort et il n'y a plus d'évolutions dessus, et c'est normal de passer à autre chose pour cette raison et pour d'autres aussi (l'architecture SPARC est loin d'être parfaite). Mais là je trouve qu'on a tendance à l'effacer un peu vite de l'histoire alors que pour moi, ce n'était pas moins ouvert et pas moins collaboratif que RISC-V, à l'époque où il y avait de l'activité dessus.

Il y a eu au moins 4 familles d'implémentations: chez Sun, Fujitsu, ceux du Moscow Center of SPARC Technology, et le LEON de l'ESA.

Il y a eu des processeurs SPARC produits par Sun, Fujitsu, TI, Atmel, Ross, …

Le développement de la version 64 bit a été fait par un commité formé de Amdahl Corporation, Fujitsu, ICL, LSI Logic, Matsushita, Philips, Ross Technology, Sun Microsystems, et Texas Instruments.

Est-ce que ce n'est toujours pas suffisant pour considérer que l'architecture a été conçue de façon collaborative? Il faut combien de douzaines d'entreprises pour que ça soit collaboratif?

Ne pas développer d'implémentation pour un OS privateur est un choix de développement comme un autre. L'équipe de Hare ne doit rien à quiconque (encore moins aux OS privateurs, qui nous pourrissent déjà suffisamment la vie). Ils proposent un travail, dont on fait ce qu'on veut.

C'est vrai, mais choisir de ne pas utiliser un langage ou une bibliothèque parce qu'elle ne fonctionne pas ou que son équipe ne fournit pas de support technique pour certaines configuration, c'est aussi un choix qu'on peut facilement comprendre. Il est probable que ça réduise l'adoption de ce langage. Ce qui fait que ça va être difficile de trouver des développeurs qui l'utilisent et le maîtrisent. Cela constitue un risque pas négligeable et qui peut pousser les gens à choisir un langage plus connu ou plus ouvert à ce genre de choses, ou à n'en avoir rien à faire et choisir quand même de programmer en Hare. Selon le cas et selon le projet, ça peut être un problème ou pas du tout.

La license n'implique rien à propos du support technique. Plutôt au contraire, il y a une clause écrite en majuscule sur l'absence de garanties, etc.

Donc Drew pourrait, par exemple:
- Refuser de fournir du support aux gens essayant de construire une version Windows,
- Fermer tous les rapports de bugs concernant des systèmes non-libres,
- Refuser d'héberger des binaires pour Windows ou d'intégrer le code dans sa version de Hare,
- Faire exprès de changer l'architecture du code pour rendre la vie plus compliquée aux forks qui tenteraient de le faire sans son aide,
- Interdire l'utilisation du nom "Hare" pour toute implémentation autre que la sienne,
- Encourager les gens à écrire du code non portable,
- Concevoir des APIs difficiles à faire fonctionner sur un système non-UNIX.

Sans pouvoir strictement l'interdire, il y a quand même tout un tas de moyen de mettre des bâtons dans les roues à quelqu'un qui se lancerait là-dedans. Même si on peut supposer que ce ne sera pas le cas, on peut considérer ça comme un problème si on veut écrire du code qui pourrait fonctionner sur un système non-libre (et personnellement, je pense que chacun devrait avoir le droit d'écrire du code qui fonctionne où il veut, et qu'on devrait essayer de rendre ça le plus facile possible).

Ça ne serait pas un problème si Drew disait, personellement, "je ne souhaite pas assurer le support pour les systèmes propriétaires". Mais là c'est présenté comme un choix plus global de toute la communauté Hare. Ce qui est surprenant parce que d'un autre côté, un des messages de blog dit qu'ils n'apprécient pas l'évangélisme de la communauté Rust qui veut réécrire et remplacer tout le code C existant. D'une certaine façon, ce choix de ne pas faire fonctionner Hare sur des systèmes non-libres et de s'engager à ne pas le faire ou à empêcher d'autres gens de le faire, relève pourtant un peu de la même attitude qui consiste à imposer ses propres idées là ou ce n'est peut-être pas nécessaire.

Ça pose aussi la question de savoir si le langage est conçu par une communauté, ou par une seule personne qui a tout pouvoir de décision. Les deux choix se défendent, mais là, la présentation qui est faite se retrouve du coup un peu entre les deux, quelque part entre le "c'est un projet personnel pour mes propres besoins, je fais ce que je veux" et le "on va construire une communauté de développeurs avec des objectifs communs". Ce qui donne une position peut être moins facile: "on va construire une communauté de développeurs qui sont d'accord avec mes objectifs". Cela dit, ça a fonctionné pour d'autres projets (Linux, Python, …) donc, ce n'est pas forcément un mauvais modèle en soi.

Autre bizarrerie, Haiku, FreeBSD, OpenBSD et NetBSD ne sont pas totalement libre d'après la FSF, cependant ils sont dans la liste des systèmes que Hare "prévoit" de supporter (et pour FreeBSD c'est même déjà fait). On peut en déduire que la définition de "propriétaire" n'est pas la même que celle de la FSF, mais du coup, quelle est-elle? Est-ce que le support de ReactOS (et par extension de Windows, son clone propriétaire) est prévu? Qui décide quels systèmes sont supportés ou pas? Est-ce que ça peut changer au cours du temps?

Swift (qui au passage n'est pas disponible pour plein d'autres systèmes —à tout hasard, je ne l'ai pas trouvé pour Haiku par exemple.)

Il est disponible dans le dépôt de paquets de Haiku suite au travail de return0e pendant le Google Summer of Code 2017.

Par contre nous n'avons pas encore de version de Hare disponible.

C'est la fin pour SPARC…

Je suis toujours un peu embêté que des articles présentent l'ouverture de RISC-V comme une nouveauté, alors que SPARC est dans la même situation depuis 1989. Toutes les spécifications de l'architecture sont sur le site sparc.org et il existe de nombreuses implémentations.

Certes l'architecture est vieillissante et pas exemptes de défauts. Mais ce serait bien de se souvenir que RISC-V n'est pas la première architecture de CPU ouverte.

Certes, Fujitsu et Sun/Oracle ont arrêté les développements de CPUs utilisant cette architecture, mais l'ESA n'avait de toutes façons jamais utilisé leurs puces (le SPARC LEON a été développé indépendamment). Donc le problème n'est pas vraiment là.

J'avais un prof en école d'ingénieur qui était très énervé par le fait que tout le monde code en C alors que lui, dans sa jeunesse, il avait appris le Simula-67 et c'était vachement plus cool.

C'est un langage objet dérivé de Algol 60, un langage qui ressemble pas mal à Go.

Pourquoi, soixante ans après, on est encore en train d'inventer des nouveaux langages?

Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?

-pedantic c'est plutôt pour le code de type "la spécification du langage dit que c'est interdit mais en fait ça marche quand même".

Ce type de chose serait plutôt détecté par les warnings activés par -Wextra, de type "la specification du langage dit que c'est autorisé, mais ça sert à rien à part écrire du code buggé".

Cependant il peut arriver que les warnings rangés dans -Wextra se déclenchent sur du code qui utilise volontairement un des aspects tordus du langage.

(ça n'enlève rien à l'intérêt des analyseurs statiques en plus du compilateur, ou d'utiliser des langages qui ont moins de chausse-trappes lorsque c'est possible)