Mon post était bien évidemment provocateur pour le 99%. ceci dit je parle de temps, pas de nombre de bugs. Donc 50 bugs de type qui te prennent 3 secondes à corriger te font perdre moins de temps que la subtile race condition sur ton algo de cache réparti sur cartes graphiques qui va te faire pleurer pendant 2 jours. C'est ça qu'il faudrait comptabiliser pour parler de productivité.
Je ne dis évidemment pas qu'il faut arrêter de faire de nouveaux langages parce qu'ils n'apportent rien et qu'on en serait au même point en codant tout en assembleur x86. Mais en l'occurrence je fais aussi du JS, mais mon langage serveur est Python, et moi aussi je vois clairement la différence de productivité entre les 2. Outre les (nombreux) défauts inhérents au JS, le fait que l'environnement de développement soit particulièrement hostile n'aide pas non plus (ça évolue, heureusement).
Non franchement, en pratique, quand OCaml te dit "ok, pour la compil, pas d'erreur" ton code bug rarement.
D'un côté je suis assez d'accord. La plupart du code qu'on écrit est trivial ; le plus important se situe plus dans son design général qu'on doit garder propre. Peu de codeur passent la majeure partie de leur temps à plancher sur les algos vraiment pointus. Pourtant, sans test unitaire derrière, je ne ferais pas confiance à un programme en Ocaml, aussi puissant soit son typage, pour ce qui est de la gestion des régressions notamment. Ce n'est pas le compilateur qui va te dire "Andouille ! Ta fonction n'était pas prévue pour gérer une liste avec des doublons, donc en changeant tel comportement, tu as cassé telle autre fonctionnalité de ton programme (que tu ne vas pas tester en cliquant forcément, tu testes celle que tu viens de coder)." En revanche des tests unitaires bien fait vont souvent le faire, et ce même dans un langage pas aussi bien que Ocaml.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 1.
D'un côté je suis assez d'accord. La plupart du code qu'on écrit est trivial ; le plus important se situe plus dans son design général qu'on doit garder propre. Peu de codeur passent la majeure partie de leur temps à plancher sur les algos vraiment pointus. Pourtant, sans test unitaire derrière, je ne ferais pas confiance à un programme en Ocaml, aussi puissant soit son typage, pour ce qui est de la gestion des régressions notamment. Ce n'est pas le compilateur qui va te dire "Andouille ! Ta fonction n'était pas prévue pour gérer une liste avec des doublons, donc en changeant tel comportement, tu as cassé telle autre fonctionnalité de ton programme (que tu ne vas pas tester en cliquant forcément, tu testes celle que tu viens de coder)." En revanche des tests unitaires bien fait vont souvent le faire, et ce même dans un langage pas aussi bien que Ocaml.