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 :oops: - on n'a rien à faire dans une équipe de fabrication d'un logiciel...
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 :
(ou à peu près, je fais de mémoire... :roll:)Code:
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
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 :P)
PS: j'ai voté "quand ça arrive en fin de vie"