"Parler de conservatisme en informatique de gestion parce qu'on utilise encore du cobol c'est un peu la même chose que de dire que c'est du conservatisme de faire du C sur unix pour des services bas niveaux."
Entièrement d'accord sur ce point. Il y a deux écoles en gestion. La première, la méthode DSI : "mon système marche aux petits oignons, alors, NON, tu ne toucheras pas au code, on ne va quand même pas risquer de tout foutre en l'air pour gagner quelques secondes de traitement, et OUI, même si toutes ces secondes font des heures". A opposer à l'approche de l'ingénieur : "si ça marche sans problème depuis longtemps, c'est le moment idéal pour optimiser tout ça". Evidemment, ça clashe souvent (pour info, je ne suis pas DSI). Maintenant le problème de l'immobilisme est partout le même : arrive un jour où on est dépassé par son environnement, et là il faut bien se résoudre à se mettre à jour. Exemple pratique : sur le projet où j'exerce, l'essentiel du développement est fait en Java. C'est assez caricatural parce que l'environnement J2EE évolue à la vitesse du son. Donc, au bout de trois ans, il a bien fallu rentrer dans le lard d'exploitants hurlant à la mort (j'exagère un peu, mais bon) pour migrer tout le bazar vers un environnement (un peu) plus à jour. Et ce non par pur plaisir, mais tout bonnement parce qu'il était devenu nécessaire de faire rentrer au forceps la moindre demande d'évolution (l'interfaçage avec des web services externes en est un bon exemple), ce qui occasionnait des cycles d'intégration abonimablement longs et coûteux. Certes il a fallu se creuser un peu le citron, mais au bout du compte on en ressort largement gagnant, avec de meilleures performances et des cycles de développement/intégration complètement maîtrisés.
Cette petite digression pour revenir à la guerre des langages : en ce qui concerne Cobol, il serait mensonger de prétendre que le langage n'a pas évolué d'un pouce depuis trente ans. D'abord il y a eu Pacbase et sa pléthore de modules, puis tout simplement des évolutions du langage, avec la possibilité de faire de l'objet (pas vraiment utilisée d'accord) et un interfaçage web, par exemple. Ces évolutions n'ont a mon avis pas été seulement motivées par la mode, mais répondent à de réels besoins d'intégration.
Alors maintenant la question est : est-ce que les programmeurs Cobol apprécieraient de pouvoir prouver leurs algorithmes lors de la compilation (généralement interminable sur du code conséquent, NDLR) ? C'est tout l'objet de ce débat.
[^] # Re: Caml
Posté par ang . En réponse au journal Les ratés historiques de l'informatique française. Évalué à 3.
Entièrement d'accord sur ce point. Il y a deux écoles en gestion. La première, la méthode DSI : "mon système marche aux petits oignons, alors, NON, tu ne toucheras pas au code, on ne va quand même pas risquer de tout foutre en l'air pour gagner quelques secondes de traitement, et OUI, même si toutes ces secondes font des heures". A opposer à l'approche de l'ingénieur : "si ça marche sans problème depuis longtemps, c'est le moment idéal pour optimiser tout ça". Evidemment, ça clashe souvent (pour info, je ne suis pas DSI). Maintenant le problème de l'immobilisme est partout le même : arrive un jour où on est dépassé par son environnement, et là il faut bien se résoudre à se mettre à jour. Exemple pratique : sur le projet où j'exerce, l'essentiel du développement est fait en Java. C'est assez caricatural parce que l'environnement J2EE évolue à la vitesse du son. Donc, au bout de trois ans, il a bien fallu rentrer dans le lard d'exploitants hurlant à la mort (j'exagère un peu, mais bon) pour migrer tout le bazar vers un environnement (un peu) plus à jour. Et ce non par pur plaisir, mais tout bonnement parce qu'il était devenu nécessaire de faire rentrer au forceps la moindre demande d'évolution (l'interfaçage avec des web services externes en est un bon exemple), ce qui occasionnait des cycles d'intégration abonimablement longs et coûteux. Certes il a fallu se creuser un peu le citron, mais au bout du compte on en ressort largement gagnant, avec de meilleures performances et des cycles de développement/intégration complètement maîtrisés.
Cette petite digression pour revenir à la guerre des langages : en ce qui concerne Cobol, il serait mensonger de prétendre que le langage n'a pas évolué d'un pouce depuis trente ans. D'abord il y a eu Pacbase et sa pléthore de modules, puis tout simplement des évolutions du langage, avec la possibilité de faire de l'objet (pas vraiment utilisée d'accord) et un interfaçage web, par exemple. Ces évolutions n'ont a mon avis pas été seulement motivées par la mode, mais répondent à de réels besoins d'intégration.
Alors maintenant la question est : est-ce que les programmeurs Cobol apprécieraient de pouvoir prouver leurs algorithmes lors de la compilation (généralement interminable sur du code conséquent, NDLR) ? C'est tout l'objet de ce débat.