15 bugs qui ont façonné le langage FLIN

Chaque langage de programmation est façonné par ses bugs. Au cours du développement de FLIN, nous avons rencontré des centaines de bugs. Mais quinze d'entre eux étaient différents. Ces quinze bugs n'ont pas juste cassé des fonctionnalités ; ils ont remodelé l'architecture du langage, influencé sa philosophie de conception et établi des principes qui gouvernent désormais chaque nouvelle fonctionnalité que nous construisons.

1. L'opcode CreateEntity manquant -- a enseigné que les tables de dispatch parallèles sont un risque de maintenance.
2. Le sous-débordement de pile de la boucle for -- le compilateur et la VM doivent s'accorder sur le modèle de stockage.
3. La fuite de pile des fonctions natives -- la discipline de pile doit être absolue.
4. Le TypeError d'accès aux propriétés de None -- FLIN a adopté la propagation implicite du None.
5. Le trimming des espaces blancs HTML -- smart_trim_text() utilise la présence de sauts de ligne comme discriminateur.
6. La version d'entité non synchronisée après sauvegarde -- le pattern de récupération après sauvegarde est devenu obligatoire.
7. Le schéma d'entité non auto-enregistré -- les schémas sont maintenant auto-enregistrés à la première création.
8. Le bytecode écrasant l'état injecté -- l'ensemble protected_globals empêche l'écrasement.
9. Value::Text non géré par Trim -- standard de codage exigeant la gestion des deux variantes.
10. Les contraintes du lexer pour le toggle de thème -- le chaînage d'affectations est devenu un pattern officiellement supporté.
11. Les valeurs par défaut d'entités non appliquées à la construction -- le générateur de code inclut désormais les valeurs par défaut.
12. L'incompatibilité de type .get() vs .find() -- ajout de .get() qui retourne le type de base.
13. L'ordonnancement des entités par HashMap -- toutes les méthodes de requête trient par (created_at, id).
14. Les fonctions de bibliothèque sans annotations de types -- règle établie d'annoter tous les paramètres dans lib/.
15. Les enfants de layout non enveloppés -- principe d'implémentation de fonctionnalités de bout en bout.

Les patterns qui ont émergé

Le spectre des échecs silencieux : sept des quinze bugs ne produisaient aucun message d'erreur. FLIN a répondu en ajoutant des mécanismes de détection proactive.

La taxe de la double représentation : trois bugs étaient causés par le maintien de deux représentations de la même chose. Pour chaque nouvelle opération, nous demandons désormais « est-ce que ça gère les deux X et Y ? »

L'écart d'intégration : cinq bugs étaient invisibles dans les tests unitaires et n'apparaissaient que pendant l'intégration. Cela nous a amenés à établir des scénarios de test de bout en bout.

La correction simple après une investigation complexe : huit des quinze bugs avaient des corrections de moins de 20 lignes de code. Le débogage est principalement un problème de recherche.

FLIN est un meilleur langage grâce à ces bugs. Pas malgré eux.

Ceci est la partie 170 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.

Navigation de la série : - [169] La crise du choix du modèle d'embeddings - [170] 15 bugs qui ont façonné le langage FLIN (vous êtes ici) - Arc suivant : expérience développeur et outillage FLIN