Discussion :

[souviron34]

Moi j'aurais mis "plateformes/runtimes plus supportés" et pas "langages plus supportés". Dire qu'un langage n'est plus supporté n'a pas grand sens.

../..

Tous ces mots ont un sens, ce n'est pas pour qu'on les utilise à tort et à travers.

Tout à fait...

Et je pense que, si j'étais méchant () je dirais "bien fait !!" par rapport au constat du PO..

Car dans le fond, on nous fait miroiter depuis presque 20 ans que c'est super, les biblios, les frameworks, etc etc... Les "nouveaux devs" ne jurent que par ça, tout comme leurs chefs...

Tant pis pour eux si ils "oublient" que les versions changent rapidement, et qu'ils se basent sur ces "features"...


En fait, comme tu le dis, du point de vue des langages les choses évoluent beaucoup plus lentement, sans parler de certains acceptant les délais mis en place lors des "anciens" langages (5 ans pour avertir d'une obsolescence prévue- 10 ans pour la mettre en place) comme Fortran, C, etc etc..


La règle de base que j'ai toujours eue est : ne JAMAIS utiliser les "features" spéciales , sauf pour les "flags/drapeaux" de compil' ... Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....

Et si on ne sait pas s'en servir, on n'est pas un "programmeur", donc - à mon avis - on n'a rien à faire dans une équipe de fabrication d'un logiciel...

Les programmeurs d'origine pensaient que leurs créations seraient tout simplement remplacées quelques années plus tard... Les remplacements ne se sont jamais produits. Les fonds disponibles allaient à la création de nouvelles applications et non au remplacement des applications existantes. On dirait que les leçons du passé sont trop vite oubliées

C'est surtout que c'est plutôt l'inverse : on faisait des programmes pour qu'ils durent.... Les langages utilisés - comme celui que tu cites - est toujours là 40 ans plus tard... Comme mes programmes en Fortran ou C...

En ce qui concerne le "bug de l'an 2000", c'est surtout qu'on n'y avait pas pensé... et qu'on n'avait pas les moyens techniques :

• d'une part 20 ans c'est long et personne en 1980 ne pensait que dans le monde entier tout serait connecté.... et que donc une "faille" pourrait créer un chaos à l'échelle planétaire.... (ce qui d'ailleurs n'a pas été le cas et a été une mine d'or pour toutes les SSII....)
  
  
• Mais d'autre part, la mémoire était "ridicule" par rapport à aujourd'hui .. J'ai fait des programmes de traitement d'images en 1986 avec 64K de mémoire "programme" et 64K de "data"... 3 lignes d'une image 512x512 8-bits, OU uniquement le "switch" des fonctionalités (un switch contenant juste "addition, soustraction, multiplication, zoom, déplacement, et sauvegarde, avec l'appel des fonctions" était tout ce que pouvait prendre la mémoire) .. Donc on fait ce qu'on peut avec les moyens qu'on a ...
  
  
  Exemple d'un programme en 1984-86 sur PDP 11/23 :
  
  

  Code FORTRAN :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  program toto()
  integer*8 icode
   
  READ (5, *) icode
   
  switch (icode) {
   case lire : 
       call readim()
       break
   case ecrire : 
       call writeim()
       break
   case add: 
       call add()
       break
   case sub : 
       call sub()
       break
   case mul : 
       call mul()
       break
   case zoom : 
       call zoom()
       break
   case shift : 
       call shift()
       break
  }
  END

  (ou à peu près, je fais de mémoire... )

Et actuellement, n'importe quel gestionnaire moindrement au courant de l'histoire du système Phénix doit avoir une peu bleue de tout remplacement radical d'un programme qui fonctionne même s'il est antédiluvien et mal foutu, par un nouveau programme. Cela n'aidera en rien au remplacement des antiquités.

Avec raison...

Quand quelque chose marche, pourquoi le remplacer ???

On proteste contre l'obsolescence programmée, mais les programmes non-obsolètes, pourquoi les changer si ce n'est parce que on ne trouve plus de programmeurs capables de comprendre/modifier ces programmes...

J'ai vu des échecs monumentaux, et j'ai participé à ce que je soupçonne être des échecs monumentaux (les retards de la SNCF qui augmentent dans les dernières années par exemple...)... lors de ré-écritures... D'une part parce que la connaissance accumulée est loin d'être entièrement documentée, et il faudrait aller la rechercher profondément dans le code, en comprenant absolument tout et en reconstruisant tous les arbres et le flux, mais aussi parce que fondamentalement tout nouveau code génère son lot de bugs... par définition....



(un bon lien que j'ai déjà donné à ce sujet est ici : Rewrites Considered Harmful?, et, bien qu'écrit en 2004, il ne vieillit pas )



PS: j'ai voté "quand ça arrive en fin de vie"

[el_slapper]

Car dans le fond, on nous fait miroiter depuis presque 20 ans que c'est super, les biblios, les frameworks, etc etc... Les "nouveaux devs" ne jurent que par ça, tout comme leurs chefs...

Tant pis pour eux si ils "oublient" que les versions changent rapidement, et qu'ils se basent sur ces "features".

un lien rigolo qui va avec ça : https://workplace.stackexchange.com/...-forced-on-the

quelques extraits avant que ça ne soit définitivement clos :

We recently implemented a mandate that everyone has to now use a Windows laptop with various security tools installed on it for auditing, backup, and legal purposes. A new software tool for how we write code (i.e. a Visual Studio) also now has to be used.(.../...) 5 particular senior engineers are objecting to this. They have some common setup where they do almost everything from the command-line and using some antiquated console text editors (vim and emux, I think). (.../...) After finally having their laptops seized and replaced, their productivity as a whole has dropped off a cliff. (.../...)

I refuse to believe that a command-line interface and antiquated text editor gives that much of a performance boost to these guys, as I've seen very productive Windows developers as well (though our product is Linux). They are senior level and smart, and I think this is just their way of pouting, but I need them to get back to business as usual.

La règle de base que j'ai toujours eue est : ne JAMAIS utiliser les "features" spéciales , sauf pour les "flags/drapeaux" de compil' ... Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionnalités dont on a besoin pour faire tout ce qu'on veut en programmation....

Tiens, ça me rappelle ce vieux blog de Joel Spolsky. Identifier les dépendances, et les éliminer.

Quand quelque chose marche, pourquoi le remplacer ???

On proteste contre l'obsolescence programmée, mais les programmes non-obsolètes, pourquoi les changer si ce n'est parce que on ne trouve plus de programmeurs capables de comprendre/modifier ces programmes...

Parceque ça fait bien sur le CV, une refonte réussie. D'ailleurs, j'ai plusieurs refonte réussies à mon actif, et ça fait très bien sur mon CV. Même que parfois, on m'a dit que j'en faisais trop à ce sujet(pourtant c'est vrai).....

J'ai vu des échecs monumentaux, et j'ai participé à ce que je soupçonne être des échecs monumentaux (les retards de la SNCF qui augmentent dans les dernières années par exemple...)... lors de ré-écritures... D'une part parce que la connaissance accumulée est loin d'être entièrement documentée, et il faudrait aller la rechercher profondément dans le code, en comprenant absolument tout et en reconstruisant tous les arbres et le flux, mais aussi parce que fondamentalement tout nouveau code génère son lot de bugs... par définition....

(un bon lien que j'ai déjà donné à ce sujet est ici : Rewrites Considered Harmful?, et, bien qu'écrit en 2004, il ne vieillit pas )[/QUOTE]

C'est pour ça qu'une bonne refonte repart directement du code existant(merde, deux joel Spolsky dans le même commentaire, je dépasse les quotas). Si j'étais parti d'une feuille blanche, je me serais planté dans les grandes largeurs.

Quand j'ai refondu les avis d'échéance d'un assureur, j'ai trouvé une bonne quinzaine de fois exactement le même code(je change juste le nom des données) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
IF CODE-ROUTAGE  "09" OR "59"
    MOVE "C" TO STYLE-ROUTAGE
END-IF.

Et personne dans la boite ne savait ce que ça voulait dire. Le code datait de 1972, et on était en 2008. après des mois, on a fini par trouver : en fait, il y avait un contrat spécial pour les courriers vers l'Alsace Lorraine(qui correspondait aux codes région 09 et 59, l'appellation code routage était trompeuse), et il fallait y associer une certaine tarification. Le truc, c'est que 36 ans de maintenance mal maitrisée avait dispersé ce code absolument partout, on le retrouvait dans chaque programme spécifique à un produit, parfois même plusieurs fois.

Cet exemple démontre à la fois l'importante d'une refonte(il n'en restait plus qu'un seul exemplaire après mon passage - ils on gagné plus d'un équivalent temps plein en maintenance sur l'appli après la refonte), mais aussi la nécessite de repartir du code - la seule documentation vraiment fiable. Jamais personne n'aurait deviné ça si je n'étais pas tombé dessus. Et on aurait eu des problèmes de facturation des envois courrier à répétition.

La doc c'est de la merde. Seul le code fait foi. Et plus il est ancien, plus il a accumulé de savoir-faire. Une bonne refonte valorise ce savoir faire. Une mauvaise refonte le méprise. Moi, j'ai toujours réussi mes refontes parceque j'ai toujours respecté les petits rustines et autres verrues mises en place par mes prédécesseurs. Elles avaient toutes une raison d'être. Elles pouvaient être mal faites, être refactorisables, mais elles devaient rester. Toutes.

[phlaffez2]

21 réponses: ce sondge n'est pas pertinent. 21 réponses ne peuvent refléter la réalité

[Mat.M]

Ne JAMAIS dépendre d'une bibliothèque externe sauf par un module facilement auto-débranchable et auto-détectable... Les langages ont normalement toutes les fonctionalités dont on a besoin pour faire tout ce qu'on veut en programmation....

ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
Et que faire du code maintenant dans un projet d'entreprise ça se réduit plus à faire du paramétrage qu'à faire du code encore faudrait-il faire la nuance entre ces deux notions certes.
D'ailleurs c'est pour ça que des géants comme IBM, Salesforces,Google commercialisent des systèmes d'API web sur le Cloud.
Sans compter des trucs comme la Blockchain..
Maintenant on est arrivé l'interconnectivité web via des API modulaires.
Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant

[souviron34]

ehhh monsieurs Souviron34 et El_slapper je crois qu'il faudrait régler vos montres, on n'est plus il y a 20 ou 30 ans à faire des programmes en langage C avec la philosophie de Kerningan et Richie !
Stricto sensu vous avez raison mais maintenant un projet informatique du fait de l'assemblage de technologies existantes ce que l'on appelle pompeusement "intégration logicielle" c'est du développement avec 50-70 % de dépendances et modules externes.
../..
Ce qui fait qu'une entreprise qui veut développer un projet informatique via une SSII ou non ,en fait va développer une partie très limitée du projet,tout le reste c'est des modules externes donc forcément payant

As-tu lu le post original ???????

[Mat.M]

As-tu lu le post original ???????

oui je l'ai lu ,errare humanum est perseverare diabolicum

Quand quelque chose marche, pourquoi le remplacer ???

je l'ai écris un milliard de fois sur ce forum ; l'économie de marché donc le marché des hautes technologies et des gros éditeurs de logiciel forcent les choses à se renouveler donc effectivement par le biais de l'obsolescence.

Ce qui leur permet de gagner de l'argent et de faire des montagnes de dollar$ .

Bref le projet informatique que la moindre entreprise a mis avec tant de peine à finaliser, une fois bien finalisé et fonctionnel, les gros éditeurs ( suivez mon regard ) vont vous dire que le projet est technologiquement obsolète et qu'il faut passer à une nouvelle voie technologique ( comme le Cloud ) alors que l'entreprise n'en a absolument pas besoin..

bref l'entreprise ou bien vous et moi vont devoir mettre la main à la poche pour de nouveaux investissements technologiques coûteux alors que oui ça tourne très bien et qu'il ne faut rien changer effectivement.

De toute façon les gros éditeurs ils s'en fichent royalement si le projet informatique échoue, ils sont là pour vendre leurs produits.
J'ai travaillé dans un paquet d'entreprises sur des projets logiciels notamment pour un éditeur de logiciel d'immobilier il faut acheter Ms-Office en même temps que le logiciel pour sortir des rapports

D'une part parce que la connaissance accumulée est loin d'être entièrement documentée

d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète

[Pyramidev]

La doc c'est de la merde. Seul le code fait foi.

d'un autre côté produire des tonnes de documentation est-ce bien utile ? La on est dans l'absolutisme bureaucratique qui consiste à décrire tout ce que l'on fait au lieu de produire des chose de manière concrète

Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.
Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".

[Mat.M]

Attention, sans une documentation à jour, seuls les développeurs peuvent vraiment savoir comment fonctionne le logiciel.

je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.

Or, quand des clients remontent des problèmes au centre d'assistance, moins le personnel du centre d'assistance connaît le fonctionnement du logiciel, plus il a tendance à relayer directement les problèmes aux développeurs, même les problèmes qui ne viennent pas de bogues du logiciel.
Les développeurs perdent alors du temps à faire du travail du centre d'assistance "au lieu de produire des choses de manière concrète".

ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.

[el_slapper]

je n'ai jamais affirmé le contraire ; cependant il faut savoir mettre le curseur comme il faut, faut pas en faire des tonnes comme il ne faut pas en faire de manière insuffisante.
Or faire trop de documentation c'est coûteux à mon sens ; cela va à l'encontre de l'intérêt de l'informatisation qui a pour but de simplifier les choses.

Le truc aussi, c'est qu'indépendamment de la problématique technique(origine de ce fil) ou du manque de ressources(que tu évoques après), un logiciel, ça change assez vite au niveau des fonctionnalités. Donc maintenir une doc à jour, c'est extrêmement couteux, et généralement faux...sauf si la doc est juste un point d'entrée. Plus elle est précise, et plus vite elle est fausse. Trouver le juste milieu est souvent un casse-tête.

ça c'est toute la problèmatique d'un projet logiciel...souvent les fonctionnalités du logiciel sont insuffisantes ou mal définies, par manque de ressources humaines et financières.
Cela rejoint quelque part ce qu'écrivent Souviron34 et El_slapper..
Et puis avec le turn-over des équipes techniques notamment de développeurs ça n'arrange vraiment pas les choses.

Et aussi par une vision projet : on a le projet d'ajouter des trucs, one ajoute des trucs, ça marche, on est contents..... Mais ça manque d'une vision globale de l'application. C'est la nouvelle marotte de Martin Fowler et de son ami Sriram Narayan. Narayan insiste en particulier sue le "you build it, you run it".

Et Narayan insiste aussi sur un point rigolo : l'avantage du mode projet est que le "succès" pour les managers est facile à mesurer. Sur un produit en travail continu, il est plus délicat(même si pas impossible) de mettre en œuvre des KPI pertinents. D'ou la tendance des managers à se ruer sur le mode projet pour faire briller leur carrière.