Discussion :

[gangsoleil]

C'est pas curieux que les banques n'investissent pas pour remplacer à terme le "kobold" par un langage plus courant comme le C, pour faciliter la maintenance ?

If it works, don't fix it.

Le C est un langage beaucoup trop permissif pour remplacer "comme ca" les programmes existants par des nouveaux. Et les preuves de programme ne sont pas assez connues des dirigeants pour etre valides (il faut savoir que les programmes embarques dans les voitures n'ont pendant longtemps pas du tout ete verifies -- je ne sais pas ce qu'il en est aujourd'hui).

Et je te rassure, les banques investissent continuellement dans leur infrastructure informatique.

[souviron34]

Effectivement mais il faut admettre qu' il y a dix ans le monde du développement n'était pas aussi complexe qu'aujourd'hui et je me base sur le fait que certains de mes profs connaissaient beaucoup moins de choses à l'époque.

Non, il n'est pas devenu plus complexe...

Simplement les managers, prof, et VOUS êtes devenus plus sensibles aux modes et arguments marketings... en particulier grâce aux forums et buzz...

Il suffit de regarder ici dans la partie "Actualités" ou sur ce sous-forum particulier, sur les 6 ou 7 dernières années...

Je pense que le développement informatique se complexifie en terme de technologies et en abstractions à l'époque tu connaissais le C et deux trois trucs c'était bon aujourd'hui c'est une autre histoire...

Je ne crois pas...

Tu veux quelques exemples ?

En plus de ton langage préféré, il te fallait en général connaître le langage de l'imprimante (et donc soit savoir programmer en postscript, soit en Tektro, sot en .....). Pour les interfaces, il te fallait apprendre la biblothèque pour chaque constructeur (par exemple sur HP, ou sur PDP, ou sur Vax, ou SGI), et aussi pour chaque écran ou type d'écran (par exemple quand on affichait sur un moniteur couleur Barco, ou sur un terminal VT100...)

Bref, il y avait une foultitude d'à-côtés à apprendre à chaque fois.. et de concepts (par exemple les terminaux Tektro fonctionnaient à la manière d'un scanner, avec un faisceau lumineux balayant vertcalement... Donc pas vraiment le même concept qu'une impression Postscript, où il fallait "conceptualiser" la sortie graphique en relatif avant...).

A l'époque tu étais déjà en bas niveau et donc les développeurs savaient comme s'y prendre mais aujourd'hui il faut s'y connaître en bas niveau et en haut niveau.

Euh, faut pas charrier, hein ???

ça c'est ce qu'on vous met dans le crâne, mais C ou Fortran ou Cobol ne sont pas des langages bas niveaux....

Il falait EN PLUS connaître du bas niveau mais les langages eux-mêmes sont haut niveau : il suffit de voir la liste des instructions... Un petit nombre (moins de 40) pour tout faire, c'est pas vraiment du bas niveau, et c'est même pas mal de l'abstraction... Les maths, c'est pas ce qu'il y a de plus concret, hein ???

Quelles sont les instructions "informatiques" pures en Fortran , par exemple ?? on se sert en général de 8 ou 10 instructions en général : tu as "open", "close", "read", "write", "do", "for", "return", "call" ...

Tu trouves ça bas niveau ????

ça n'est pas ce qu'on vous enseigne comme étant "abstraction" aujourd'hui, mais ça rejoint mon point ci-dessous....

Donc personnellement on va dans une simplification à double tranchant, c'est-à-dire plus facile dans un sens mais plus difficile dans un autre.

ça oui, vraisemblablement, mais je pense en sens contraire de ce que tu penses


Je pense que l'intégration des choses et l'abstraction des concepts fait qu'au contraire les "nouveaux" développeurs tendent à moins réellement posséder la conceptualisation , en étant bornés par les outils/langages et les concepts qu'ils véhiculent/sous-tendent...

Et que c'est ça qui va rendre la tâche aussi difficile qu'avant. On aura sans doute augmenté l'abstraction mais diminué la capacité d'abstraction

A ce propos, c'est pas curieux que les banques n'investissent pas pour remplacer à terme le "kobold" par un langage plus courant comme le C, pour faciliter la maintenance ? (en plus en rajoutant un peu de preuve de programme pour la robustesse ils pourraient faire passer ça pour de la recherche, et demander du CIR)

"Rewrites considered Harmful"....


C'est quelque chose de très très très longue haleine, quand tu possèdes des dizaines de millions de lignes de code avec des implications critiques et plus de 40 ans de debugs et ajustements...

Je n'ai jamais pratiqué Fortran mais je me suis laissé dire que c'était assez proche des mathématiques brutes, on est loin de domaine spécialisé comme le calcul de structure ou l'analyse financiere dans le cas de COBOL.

Je ne comprend pas ce que tu veux dire...

Justement parce que c'est proche des maths (ça veut dire "FORmula TRANslator"), ça a un domaine d'application assez spécialisé : tout les calculs scientifiques... (physique, chimie, etc)

Pour certaines parties du domaine avionique, COBOL a été remplacé par le couple Java/SAP. Non sans heurts. Quand au résultat, c'est assez mitigé, on a des formats de sortie plus ouverts et plus faciles à manipuler mais des erreurs plus visibles et une perte en fonctionnalité dont l'optimisation en performance (maj-par-incrément VS annule-et-remplace). Après le soucis n'est pas spécialement technologique mais plus les décisions qui ont été prise, les formats n'étant pas en bijection.

Et on rejoint un peu mon premier paragraphe...

Il y a depuis environ 15-17 ans une sensibilité extrêmement forte des managers, et des développeurs, à la mode, et un "jeunisme" appliqué, qui voudrait que forcément tout ce qui est vieux est obsolète et tout ce qui est nouveau est bon...


Dans les faits, cela amène extrêmement souvent à au minimum des bilans mitigés, au pire des catastrophes....

Tout simplement par le cumul de par exemple tout ce qui est exposé dans ce post : manque de capacité d'abstraction et de culture générale des intervenants, technologie peu stable, manque de connaissance de l'historique, non prise en compte de l'héritage, etc etc....


(je vois que ta position évolue avec le temps, par rapport il me semble me souvenir à nos conversations d'il y a 3 ans ou à peu près )

[el_slapper]

A ce propos, c'est pas curieux que les banques n'investissent pas pour remplacer à terme le "kobold" par un langage plus courant comme le C, pour faciliter la maintenance ? (en plus en rajoutant un peu de preuve de programme pour la robustesse ils pourraient faire passer ça pour de la recherche, et demander du CIR)

Pour rajouter à ce qu'en on dit les autres, "kobold" a survécu là ou il est le meilleur : le noyau comptable et gestionnaire des grands comptes. Partout ailleurs il a disparu, et c'est une bonne chose. (exemple ici ou Jeff Atwood fait un bouton en 2 lignes en C#, et en 8 en COBOL. Là ou il fait fausse route, c'est que tous les problèmes ne ressemblent pas à des boutons).

Récemment encore, un grand compte de l'industrie financière vient de déclarer obsolète une refonte de son système de gestion(100M€ à la baille, au bas mot). En termes de performances et de maintenabilité, il n'arrivait pas à la cheville du vieux clou en kobold.

Je ne connais pas l'aéronautique, par contre. Je ne me serais jamais douté qu'il y avait jadis du COBOL là-dedans. J'aurais plus vu de l'ADA. Hier comme aujourd'hui.

[Logan Mauzaize]

Non, il n'est pas devenu plus complexe...

Il est devenu complexe dans le sens où le minimum à savoir à augmenter. Et que le marché tend à te rendre ultra flexible en terme de technologie, domaine et autres.
Il n'a jamais été utile à la base de savoir "coder" une impression. C'était le contexte à un instant T qui te le demandait. Tout ce qu'on te demandait c'est de connaître un OS et un langage.

Simplement les managers, prof, et VOUS êtes devenus plus sensibles aux modes et arguments marketings... en particulier grâce aux forums et buzz...

On est surtout sensible aux tendances du marché, pour les profs c'est plus compliqué. Le temps qu'ils s'adaptent au marché à une date N, le marché a déjà changé. Ils sont donc toujours à la bourre (à part quelques-uns que j'ai eu la grande chance de connaître).

ça c'est ce qu'on vous met dans le crâne, mais C ou Fortran ou Cobol ne sont pas des langages bas niveaux....

Le C est un langage relativement bas niveau. Il a un fonctionnement encore proche de la machine.
Pour le COBOL, il a un fonctionnement proche de la machine de Turing, pas de mémoire dynamique (ou très peu), pas de mémoire partagée et une lecture série ou indexée.

Justement parce que c'est proche des maths (ça veut dire "FORmula TRANslator"), ça a un domaine d'application assez spécialisé : tout les calculs scientifiques... (physique, chimie, etc)

Le langage mathématique est un concept très large, tu le dis toi même ("tous les calculs scientifiques) alors que, par exemple, le calcul de structure est déjà un domaine plus spécialisé (mais qui reste encore vague).

Il y a depuis environ 15-17 ans une sensibilité extrêmement forte des managers, et des développeurs, à la mode, et un "jeunisme" appliqué, qui voudrait que forcément tout ce qui est vieux est obsolète et tout ce qui est nouveau est bon...

Tout ce qui est vieux ne l'est pas non plus J'ai encore en tête des conceptions/codes/architectures cauchemardesques. Ce qui a peut-être changé (je suis dans la place que depuis 4-5ans), c'est qu'on a moins de doutes à remettre en cause ce qui a été fait ?

Je pense qu'aujourd'hui nous avons des outils, des procédures, des technologies, etc. qui nous donnent des moyens de tests et de flexibilité qu'on avait pas avant et donc la possibilité de changer tout ou une partie d'un système avec une relative "sûreté".

Dans les faits, cela amène extrêmement souvent à au minimum des bilans mitigés, au pire des catastrophes....

J'ai connu de belles réussites si les choses étaient bien pensées. Mais cela n'a pas dû vraiment changer depuis 15ans.

(je vois que ta position évolue avec le temps, par rapport il me semble me souvenir à nos conversations d'il y a 3 ans ou à peu près )

Je me rends pas compte mais j'en ai pas l'impression. Ceci dit tu piques ma curiosité, j'aimerai bien avoir un oeil extérieur sur mon évolution ^^

[Logan Mauzaize]

Je ne connais pas l'aéronautique, par contre. Je ne me serais jamais douté qu'il y avait jadis du COBOL là-dedans. J'aurais plus vu de l'ADA. Hier comme aujourd'hui.

Pas de COBOL en vol je te rassure Ce sont des chaînes de calculs qui traitent des flots d'information et donc le besoin en "traitement par lot" est fort.

Et ce n'est pas avec les PCs qu'on pourra traiter des fichiers et des bases de données qui font plusieurs To.

(exemple ici ou Jeff Atwood fait un bouton en 2 lignes en C#, et en 8 en COBOL. Là ou il fait fausse route, c'est que tous les problèmes ne ressemblent pas à des boutons).

Le contre-exemple type c'est l'appareillage de données (BDD ou fichiers). Ca s'écrit très facilement, très proprement et très succinctement en COBOL alors que dans les autres langages c'est moins "simple", sans parler parfois des performances (ex: SQL ou PL/SQL).

Idem pour le stockage de données simples comme des paires clé-valeur. Les fichiers séquentiels indexés me manquent énormément. Même si, au moins en Java, le NoSQL a permis de remettre au gout du jour les "bases" orientées documents et clé-valeur.

[souviron34]

Il est devenu complexe dans le sens où le minimum à savoir à augmenter. Et que le marché tend à te rendre ultra flexible en terme de technologie, domaine et autres.
Il n'a jamais été utile à la base de savoir "coder" une impression. C'était le contexte à un instant T qui te le demandait. Tout ce qu'on te demandait c'est de connaître un OS et un langage.

Non, je ne pense pas...

D'une part on ne te demandait pas un OS... Simplement un langage... Car ces langages étaient sur toutes les platformes.

Mais c'était à toi de t'adapter aux plateformes et aux spécificités du langage sur cette plateforme..

Quand je dis que c'est pas plus complexe, c'est que le nombre de choses demandées a explosé, mais la réalité fait que on tourne toujours à 2 ou 3...

Le C est un langage relativement bas niveau. Il a un fonctionnement encore proche de la machine.
Pour le COBOL, il a un fonctionnement proche de la machine de Turing, pas de mémoire dynamique (ou très peu), pas de mémoire partagée et une lecture série ou indexée.

Le langage mathématique est un concept très large, tu le dis toi même ("tous les calculs scientifiques) alors que, par exemple, le calcul de structure est déjà un domaine plus spécialisé (mais qui reste encore vague).

Tu vois, c'est exactement sur ce point que notre appréciiation de ce qui est "bas niveau" diverge...

Lorsque j'étais jeune programmeur - et jusqu'à l'age de 35 ans - je ne me uis JAMAIS soucié - ni de "machine de turing", ni de quoi que ce soit de théorique sur les mémoires partagées, les lectures, etc..

On avait un concept, une analyse métieret une conception du soft en fonctionalité, et après on allait piocher dans les bouquins la bonne instruction. Point-barre..

C'est de là je pense que viens votre appellation "bas niveau", c'est parce que vous vous posez des quetions théoriques sur les éléments du langage et de ce que ça fait...

Quand en Fortran - ou en Pascal - on utilise des COMMON, on se fout pas mal de la théorie. On SAIT parce que on a lu que c'est un emplacement sur le disque qui est parta-gé/-geable ...

De même, suivant les fichiers qu'on veut lire ou écrire, on choisit la lecture/écriture à accès direct ou à accès séquentel : forcément une bande magnétique sera séquentielle, un fichier disque au choix l'un ou l'autre suivant les besoins.

Je crois que c'est ça la base : nous avons appris à raisonner et construire des programmes par fonctionalités, ce qui nous fait envisager des langages comme simplement "quelle est l'instruction qui permet de faire ça ?" alors que vous avez eu des cours théoriques, et que vous théorisez sur les niveaux d'abstraction du langage, et pas de la pensée qui utilise le langage..




Donc pour moi le C n'est pas plus bas niveau que Fortran ou Cobol, car, à part les allocations, en termes d'instructions on a pratiquement recouvrement à 100%... Pour quelqu'un comme moi, de la vielle école, je ne vois aucune différence : je ne sais pas calculer en hexa ou en octal, et je me suis toujours servi du C comme je me suis servi du Fortran... J'ai d'ailleurs basculé en 2 semaines de l'un à l'autre...

Tout ce qui est vieux ne l'est pas non plus J'ai encore en tête des conceptions/codes/architectures cauchemardesques. Ce qui a peut-être changé (je suis dans la place que depuis 4-5ans), c'est qu'on a moins de doutes à remettre en cause ce qui a été fait ?

Non, je pense que ce qui a changé c'est qu'on a l'illusion qu'il FAUT remttre en cause ce qui a été fait PARCE QUE ça a tel age...

J'ai connu de belles réussites si les choses étaient bien pensées. Mais cela n'a pas dû vraiment changer depuis 15ans.

Et de beaux échecs aussi...

Je me rends pas compte mais j'en ai pas l'impression. Ceci dit tu piques ma curiosité, j'aimerai bien avoir un oeil extérieur sur mon évolution ^^

Disons que, comme ManusDei, gangsoleil, etc, et c'est parfaitement normal, l'expérience pondère les élans noir & blanc et "persuadés de la Vérité" que l'on a en sortant des études...

La réalité est tout autre que les belles théories de la fac...

[el_slapper]

(.../...)Et de beaux échecs aussi...
(.../...)

C'est marrant, sur des projets ou je suis intervenu plus de 12 jours, je n'ai jamais connu l'echec. Bon, y'en a 1, c'était pas formidable(en même temps, je débutais en transactionnel, et je ne savais pas qu'il fallait tester TOUS les cas amenant au même écran. Une bonne leçon).

Par contre, les 2 dont j'ai pu sortir tout de suite se sont gauffrés(1 annulé, 1 avec 6 ans de retard, toujours pas terminé). Je n'avais aucune chance de les sauver(même Chuck Norris n'aurait pas sauvé ces projets. Et je suis loin d'être Chuck Norris). On va dire que j'ai été un gros lâche. Ou un réaliste, c'est selon.

[Ecva233]

Je ne connais pas l'aéronautique, par contre. Je ne me serais jamais douté qu'il y avait jadis du COBOL là-dedans. J'aurais plus vu de l'ADA. Hier comme aujourd'hui.

Alors dans la série "les sites incongrus ou on trouve encore du Cobol", dernièrement, en discutant avec un directeur d'une fabrique de beurre (14 employés) en Poitou Charentes, ses applications de gestion étaient écrites en cobol (tournant sur AS400) ...

Finalement j'ai repris 2 fois du beurre

[souviron34]

C'est marrant, sur des projets ou je suis intervenu plus de 12 jours, je n'ai jamais connu l'echec.

oui mais les projets en général ....

[Ecva233]

Non, je pense que ce qui a changé c'est qu'on a l'illusion qu'il FAUT remttre en cause ce qui a été fait PARCE QUE ça a tel age...

Cela n'a pas changé, cela a toujours été.

Depuis l'école d'info que j'ai suivi jusqu'à ces dernières années, on m'a toujours rabaché qu'une application informatique avait une durée de vie de 7 à 10 ans, et qu'après elle devrait être ré écrite pour pouvoir continuer à rendre le service voulu.
Alors qu'une architecture logicielle saine, simple et ouverte, permet l'évolutivité de l'application indépendamment du langage.

[souviron34]

Cela n'a pas changé, cela a toujours été.

Depuis l'école d'info que j'ai suivi jusqu'à ces dernières années, on m'a toujours rabaché qu'une application informatique avait une durée de vie de 7 à 10 ans, et qu'après elle devrait être ré écrite pour pouvoir continuer à rendre le service voulu.
Alors qu'une architecture logicielle saine, simple et ouverte, permet l'évolutivité de l'application indépendamment du langage.

Je peux pas dire, j'ai pas suivi d'école d'info..

Mais les gens que j'ai rencontré il y a 30 ans se souciaient de faire des applis qui durent...

Donc effectivement, ils pensaient "architecture" (ce qui aujourd'hui me mt hors de moi, c'est justement "architecte JEE, architecte .Net, etc... Soit on a une architecure du logiciel, soit on a un truc dépendant d'un langage... )

[gangsoleil]

Depuis l'école d'info que j'ai suivi jusqu'à ces dernières années, on m'a toujours rabaché qu'une application informatique avait une durée de vie de 7 à 10 ans, et qu'après elle devrait être ré écrite pour pouvoir continuer à rendre le service voulu.

Je ne sais pas qui est "On", mais tu devrais leur conseiller d'aller faire un tour du cote des applications bancaires, ou pourquoi pas voir le code qui est execute dans les centrales nucleaires -- deux exemples parmis tant d'autres de codes qui ont bien evidemment une duree de vie tres superieure a 7-10 ans.

Si une application tourne depuis 7 ans, c'est a priori qu'elle rend bien le service rendu non ? Ou c'est comme les yaourts, elle atteint une date de peremption et n'est plus valide ?

[GPPro]

Donc effectivement, ils pensaient "architecture" (ce qui aujourd'hui me mt hors de moi, c'est justement "architecte JEE, architecte .Net, etc... Soit on a une architecure du logiciel, soit on a un truc dépendant d'un langage... )

Mais ça, c'est l'architecte SSII. On prend un gars un peu senior sur une techno, on lui fait miroiter un titre ronflant et on vend le tout.

[Logan Mauzaize]

Donc effectivement, ils pensaient "architecture" (ce qui aujourd'hui me mt hors de moi, c'est justement "architecte JEE, architecte .Net, etc... Soit on a une architecure du logiciel, soit on a un truc dépendant d'un langage... )

Mais ça, c'est l'architecte SSII. On prend un gars un peu senior sur une techno, on lui fait miroiter un titre ronflant et on vend le tout.

Pas vraiment d'accord, mais peut-être parce que derrière le titre "Architecte XXX" vous attendez autre chose. On parle parfois aussi de "Architecte technique", "Responsable technique", "Développeur en chef" ou autre.
S'il y a des similitudes (et des activités communes) entre ces postes. Il y a également des subtilités propre à chaque.

Ils ne sont bien sûr pas à confondre avec un "Architecte SI" qui a une orientation plus matérielle (serveur, réseau, protocoles, sécurité) que logicielle (ex : découpage en modules/artefacts). L'architecte technique travaille selon les contraintes de l'Architecte SI. Et parfois les deux sont liés.

[Ecva233]

Mais les gens que j'ai rencontré il y a 30 ans se souciaient de faire des applis qui durent...

Attention, tu vas être catalogué dans le club des "C'était mieux avant"

[Ecva233]

Je ne sais pas qui est "On", ...

Prof/jeunes grands diplômés imbus de leur science, vendeur de progiciel, commerciaux soucieux de placer leurs ressources sur la dernière techno à la mode, managergeek ...

[souviron34]

Attention, tu vas être catalogué dans le club des "C'était mieux avant"

Pour certaines choses, je ne m'en cache absoulment pas..

Mais ce que je veux dire de fond, c'est que :

1) l'informatique n'est pas plus complexe qu'avant, il y a plus de softs et de langages que certains veulent utiliser, mais c'est tout.

2) ça a changé quand même, parce que dans ma carrière, entre 1983 et 1996, soit en 13 ans, je n'ai vu que : Fortran et C qui étaient là, la mode du Pascal, et l'arrivée massive de X11 , et du Web.. Et sur les PCs, VB et Delphi..

ça fait peu comparé à ce qui se passe aujourd'hui en 13 ans, mais même en 1 an...

En fait, tout s'est déclenché vers 96, lors de l'explosion du Web... Il y a eu d'abord Java, poussé par Sun, puis la pression commerciale de M$ (avec VC++), et puis l'explosion des différents flavours de Linux, et depuis 2002 environ une course effrénée dans laquelle participent les universités ( voir les Luan, et autres langages formels par exemple), les geeks (t'as pas vu le dernier truc de XX ? c'est troooooooop cool !!) , les marketeux et managers incompétents (on est agiles et ISO, et on utilise le cloud, parce que nous on est à la pointe) , et les SSII par "optimisation de marges" et inculture des RH et managers divers...

[Graffito]

il y a plus de softs et de langages que certains veulent utiliser

ou ils pensent faire de bon choix en diversifiant leur environnement de dévelopemment.

Personellement, j'ai toujours imposé dans notre entreprise un environnement unique (Turbo-pascal de 1983 à 1995, Delphi de 1995 à 2005, Visual studio C# depuis 2006) en créant à titre exceptionnel des "wrappers" dans d'autre langages pour interfacer nos développements.

L'inconvénient de cette strategie est qu'on est parfois amené à refuser des affaires. L'avantage est qu'on sait mieux évaluer les temps/coûts de développement dans des environnements bien maitrisés et qu'on peut capitaliser sur l'expérience acquise. Résultat : cela fait plus de 20 ans que personne chez nous n'a travaillé le week-end.

[gihambi]

slt bah si tous ces emprise ferme leur pour moi je laisse tous et je devient paysan

[ManusDei]

"Rewrites considered Harmful"....

C'est quelque chose de très très très longue haleine, quand tu possèdes des dizaines de millions de lignes de code avec des implications critiques et plus de 40 ans de debugs et ajustements...

Justement, vu que le COBOL n'est plus vraiment enseigné nulle part, le nombre de dev COBOL va baisser. Je suppose (et c'est peut-être là que je me plante) que les devs COBOL vont devenir plus chers tout en étant pas forcément aussi bons ni aussi expérimentés.

Bref, est-ce qu'il ne serait pas intéressant pour une banque de prévoir un projet de "recherche" financé en partie par du CIR pour passer à un langage plus répandu, éventuellement avec quelques morceaux dans un DSL adapté aux calculs pour avoir plus d'experts compétents sous la main ?

Vu que le COBOL fonctionne bien, qu'il y a encore des devs compétents et expérimentés, ils peuvent tranquillement se donner 10-20 ans pour recoder un nouvel environnement en parallèle et le tester à fond.