> quand on code, on le fait d'après une spécification.
Certe et le propre d'une spécification "normale" est de ne pas entrer dans les détails sur le comment mais indique le résultat désiré sans entrer vraiment dans le détail non plus d'ailleur.
Par rapport aux spec avec lesquelles j'ai a bosser, pour pouvoir éventuellement genere du code avec, il faudrait que la taille des specs soit multipliées par 10 et encore, c'est probablement sous estimé.
> Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.
Oui, enfin le boulot du codeur n'est pas de prendre la spec et de pisser du code, mais de l'interpreter, remplir les blancs, discuter, etc..
Ce qui permet de trouver aussi des erreurs de specs, et je peux te garantir que j'en ai trouvé quelqu'une.. Avec une spec qui grossit d'une taille *10, le nombre d'erreurs grossira aussi.
La génération automatique de code, j'ai déja donné et même sans partir de spec, cela a des avantages mais aussi de gros inconvénient: temps de compil monstreux (genre le générateur qui génere une classe différente par type d'entier différent, oui c'est du vécu), opacité du code généré (à débugger c'est "sympa": les débuggeur remontent rarement au niveau du générateur initial, débuggé du code généré automatiquement c'est à peu près aussi drole que d'aller chez le dentiste).
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par reno . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Certe et le propre d'une spécification "normale" est de ne pas entrer dans les détails sur le comment mais indique le résultat désiré sans entrer vraiment dans le détail non plus d'ailleur.
Par rapport aux spec avec lesquelles j'ai a bosser, pour pouvoir éventuellement genere du code avec, il faudrait que la taille des specs soit multipliées par 10 et encore, c'est probablement sous estimé.
> Une erreur de spec c'est d'autant plus dramatique si tu dois faire du code derrière.
Oui, enfin le boulot du codeur n'est pas de prendre la spec et de pisser du code, mais de l'interpreter, remplir les blancs, discuter, etc..
Ce qui permet de trouver aussi des erreurs de specs, et je peux te garantir que j'en ai trouvé quelqu'une.. Avec une spec qui grossit d'une taille *10, le nombre d'erreurs grossira aussi.
La génération automatique de code, j'ai déja donné et même sans partir de spec, cela a des avantages mais aussi de gros inconvénient: temps de compil monstreux (genre le générateur qui génere une classe différente par type d'entier différent, oui c'est du vécu), opacité du code généré (à débugger c'est "sympa": les débuggeur remontent rarement au niveau du générateur initial, débuggé du code généré automatiquement c'est à peu près aussi drole que d'aller chez le dentiste).