C'est très difficile de connaitre les vrais besoins.
Toutafé. C'est bien pour ça qu'en général il est difficile de se contenter de demander aux utilisateurs ce qu'ils veulent. Ils faut le deviner, anticiper, proposer, attirer et parfois créer le besoin.
Le minimum, c'est de regarder l'état de l'art de ce qui se fait.
La plupart des environnements modernes proposent un feedback instantané au développeur : ca se traduit par des IDE qui propose coloration contextuelle, completion, compilation en arrière plan, deboggage avec modification du code en live, ca se traduit également par des langages s'utilisant principalement avec un interpréteur (je test en direct le code auquel je pense), etc.
Maintenant les utilisateurs sont habitués à ça, et ca va être difficile pour eux de revenir en arrière, même si vous proposez d'autres atouts.
Comme déjà dit, les assertions c'est gentil, mais encore faut-il savoir les écrire. Encore faut-il savoir quoi mettre dedans. Encore faut-il ne pas se tromper lors que l'on écrit ce que l'on met dedans. Encore faut-il que les specs que l'on implémente soient correct. Encore faut-il qu'on les est bien comprises.
Les environnements actuels sont pragmatiques : rien ne vaut une exécution pour s'assurer que ce que fait le programme semble correspondre au besoin de son (futur) utilisateur.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
C'est pour ça que dans tous les cas il ne faut pas ignorer le temps de compilation, les outils de déboggage, les outils de vérifications de code, les outils de test, les IDE, bref toute la chaîne de production. Et oui : la plateforme (langage+runtime+lib) doit être conçu dès le départ pour prendre en compte ces différents aspects, sinon c'est l'assurance d'avoir un joli truc bon pour le placard.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
Toutafé. C'est bien pour ça qu'en général il est difficile de se contenter de demander aux utilisateurs ce qu'ils veulent. Ils faut le deviner, anticiper, proposer, attirer et parfois créer le besoin.
Le minimum, c'est de regarder l'état de l'art de ce qui se fait.
La plupart des environnements modernes proposent un feedback instantané au développeur : ca se traduit par des IDE qui propose coloration contextuelle, completion, compilation en arrière plan, deboggage avec modification du code en live, ca se traduit également par des langages s'utilisant principalement avec un interpréteur (je test en direct le code auquel je pense), etc.
Maintenant les utilisateurs sont habitués à ça, et ca va être difficile pour eux de revenir en arrière, même si vous proposez d'autres atouts.
Comme déjà dit, les assertions c'est gentil, mais encore faut-il savoir les écrire. Encore faut-il savoir quoi mettre dedans. Encore faut-il ne pas se tromper lors que l'on écrit ce que l'on met dedans. Encore faut-il que les specs que l'on implémente soient correct. Encore faut-il qu'on les est bien comprises.
Les environnements actuels sont pragmatiques : rien ne vaut une exécution pour s'assurer que ce que fait le programme semble correspondre au besoin de son (futur) utilisateur.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
C'est pour ça que dans tous les cas il ne faut pas ignorer le temps de compilation, les outils de déboggage, les outils de vérifications de code, les outils de test, les IDE, bref toute la chaîne de production. Et oui : la plateforme (langage+runtime+lib) doit être conçu dès le départ pour prendre en compte ces différents aspects, sinon c'est l'assurance d'avoir un joli truc bon pour le placard.