En plus de IEEE754 que je trouve utile pour les cpu, mais compliquer pour les développeurs et les compilateurs, il y a bien d'autre sujet difficile à creuser.
Je pense à l'usage par des langages des instructions cpu un peu spécifique, il y a eu le SIMD qui a entrainé l’auto-vectorisation dans GCC, mais il y a plein d'autre instruction ésotérique comme pour aes ou la manipulation de bit (popcount).
Il y a le refactoring de code, on peut par exemple penser à la sortie d'une nouvelle version de lib, et le bordel, l'énergie dépensée uniquement pour porter les applications dans la nouvelle version. Je crois que le problème s'est posé avec Qt4 et Gtk3. On pourrait imaginer un moyen de décrire sémantiquement la migration automatiquement un programme d'une version de lib à l'autre.
Concernant le test, avec mon expérience dans le code aéronautique, il manque des outils pour générer automatiquement des entrées, pour "couvrir" totalement le code. Ensuite, il faut un moyen pour valider les sorties. Le plus simple est un modèle complet de test. Si on a un "équivalence checker" pas besoin du générateur d'entrée. Les techniques de "fuzzer" s'approche de ce modèle, mais sans garanti sur la couverture du code. Par définition plus un code est complexe, et moins il est couteux de redévelopper un code différent de test, que de faire une couverture total par des tests classiques.
Pour aller encore plus loin, même si il existe des outils proprio qu'il le fait, on pourrait imaginer des tag pour faire la traçabilité entre la spec, le code, procédure de test et code de tests. Ainsi on peut savoir ce que les tests valident. On peut vérifier que les tests du 1.1 de la spec, couvre bien entièrement le code lié au point 1.1, et non pas un autre test qui le fait par hasard et sans vérifier les sorties (vécu). Si un outil vérifie la cohérence de l'ensemble, il devient facile d'estimer l'impact dans un projet en cas de modification de spec. Actuellement, c'est fait avec divers outils, Excel inclus.
J'imagine qu'il y a plein d'autres problèmes de ce genre.
[^] # Re: Perl6
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 3.
En plus de IEEE754 que je trouve utile pour les cpu, mais compliquer pour les développeurs et les compilateurs, il y a bien d'autre sujet difficile à creuser.
Je pense à l'usage par des langages des instructions cpu un peu spécifique, il y a eu le SIMD qui a entrainé l’auto-vectorisation dans GCC, mais il y a plein d'autre instruction ésotérique comme pour aes ou la manipulation de bit (popcount).
Il y a le refactoring de code, on peut par exemple penser à la sortie d'une nouvelle version de lib, et le bordel, l'énergie dépensée uniquement pour porter les applications dans la nouvelle version. Je crois que le problème s'est posé avec Qt4 et Gtk3. On pourrait imaginer un moyen de décrire sémantiquement la migration automatiquement un programme d'une version de lib à l'autre.
Concernant le test, avec mon expérience dans le code aéronautique, il manque des outils pour générer automatiquement des entrées, pour "couvrir" totalement le code. Ensuite, il faut un moyen pour valider les sorties. Le plus simple est un modèle complet de test. Si on a un "équivalence checker" pas besoin du générateur d'entrée. Les techniques de "fuzzer" s'approche de ce modèle, mais sans garanti sur la couverture du code. Par définition plus un code est complexe, et moins il est couteux de redévelopper un code différent de test, que de faire une couverture total par des tests classiques.
Pour aller encore plus loin, même si il existe des outils proprio qu'il le fait, on pourrait imaginer des tag pour faire la traçabilité entre la spec, le code, procédure de test et code de tests. Ainsi on peut savoir ce que les tests valident. On peut vérifier que les tests du 1.1 de la spec, couvre bien entièrement le code lié au point 1.1, et non pas un autre test qui le fait par hasard et sans vérifier les sorties (vécu). Si un outil vérifie la cohérence de l'ensemble, il devient facile d'estimer l'impact dans un projet en cas de modification de spec. Actuellement, c'est fait avec divers outils, Excel inclus.
J'imagine qu'il y a plein d'autres problèmes de ce genre.
"La première sécurité est la liberté"