Je suis presque d'accord avec toi, à quelques détails près :
D'autres ont répondu.
Oui, ça c'est vrai. Tant que tu as de bons développeurs. Il n'y en a pas assez pour tout le monde(jeunisme, diplomisme, etc.....)
Voilà, tu as une idée du pourquoi je n'avais pas accès à SQL. 9 mois de paperasse pour avoir le droit de créer une base. Le délai du projet était inférieur à ça. Mais c'est la vraie vie, les contraintes auxquelles nous sommes soumises. Autre exemple : je suis dans un contexte ou livrer un modif en prod, c'est 4 minutes chrono, et faire modifier une table de paramétrage, c'est une semaine. Dans ce contexte, la bonne pratique de ne pas mettre de données en dur dans le programme, de tout mettre en paramétrage - parce-que c'est plus efficace à maintenir, ne tient pas. Je ne suis pas très fier de ça. Mais quand on me demandait un changement rapide, changement rapide il y avait.
(merci d'envoyer les tomates trop mures à la rédaction, qui transmettra)
Sauf que certains idées passent mieux dans certains paradigmes que dans d'autres. 90% de mon boulot, en COBOL, c'était de longues suites de garnissages de données. Des scripts fonctionnels, quoi. Aucune algorithmique - à part parfois le rapprochement de fichiers. Le procédural, dans ce cas, c'est le plus efficace - ça va droit au but. Pas de fioritures fonctionnelles(l'immutabilité quand tu dois mettre à jour des montants, et que ta spec, c'est tout un tas de petites mises à jour successives, euh, tu oublies) ou objet(une classe avec 50 données et 2000 méthodes, c'est à peu près la seule manière de faire ça sans des découpages ineptes. Ai-je besoin de dire pourquoi il ne faut pas faire ça?).
Les 10% restants étaient les plus marrants, et en même temps j'y ai senti les limites du procédural pur. Douloureusement pour cette histoire ensembliste. Mais j'ai réussi quand même. Comme tu dis, on arrive à faire passer les idées quand même.
Réponse d'ingénieur : ça dépend. Mes clients actuels(des hôpitaux) ont tendance à faire des économies de bout de chandelle sur tout, et la problématique de performance pour eux est fondamentale...vu les brouettes dont ils disposent. Un de nos concurrents à quitté la France(et l'Espagne, de mémoire) la queue basse - sa solution demandait 10 fois plus de CPU que la notre. Aux USA, ils se donnent les moyens(en même temps, il faut voir le coût de leurs frais médicaux)
Deux points fondamentaux, l'algo et l'I/O. Que tu as bien raison de souligner. A ajouter un troisième point : le contexte. L'algo ensembliste que j'avais mis au point prenait une minute - sur un traitement total de 6 heures. Sur les 6 heures de la chaîne complète, tu avais facilement 5h30 d'I/O. Je n'ai donc pas optimisé l'algo - ça n'était pas pertinent.
Le contexte, c'était que ça s'appliquait par agent, pas sur la volumétrie totale. Chaque agent n'avait pas plus de 150 entrées(par définition, on me faisait sabrer au delà) - et généralement moins de 50. Donc, l'algo immonde à la puissance 4 que j'avais fait ne débordait pas. Bien évidemment, si ils avaient voulu faire leurs regroupements sur toute la banque, j'aurais explosé le CPU. 1000 fois 50 à la puissance 4, contre 50 000 à la puissance 4... Ca fait un milliard de minutes, à vue de nez(sans calculatrice - si je me suis gouré, une correction est la bienvenue). Dans un autre contexte(banque entière et non pas chaque agent calculé séparément), mon algo aurait été définitivement inacceptable.
A ce niveau, la puissance de la machine n'importe plus du tout. Un milliard de minutes, même en rajoutant du CPU, euh... Et justement, en utilisant des standards ensemblistes optimisés(genre SQL), on retombe sur des choses gérables en termes de performances. J'aurais eu bien du mal, avec du procédural, à approcher leurs performances, comme fredoche le dit si bien. C'est mon point : ce n'est pas toujours vrai, mais dans certains cas, le choix du paradigme est stratégique.
(après, Python C++, je ne suis pas assez calé, je vous laisse vous écharper).
Partager