Discussion :

[Wiink]

Pour l'anecdote, je me suis retrouvé face à un sélecteur de date à implémenter, et j'ai du imposer une fin fixe à ce calendrier (pour éviter de boucler des milliers d'années).

Des techniques évidentes de programmation permettent de passer ce problème sans bloquer le futur de l'application, mais la question réside :
combien de temps sera utilisée une bonne application faite en 2010 ?

On constate actuellement dans le milieu pro (la vente / l'industrie) l'utilisation d'applications qui datent des premières interfaces graphiques. Ces applications peuvent être maintenues, mais ne sont plus compatibles avec les techniques actuelles. Elles sont bloquées à leur époque, sur le seul OS compatible, mais ont survécu presque 20 ans. Dans 10 ans elles seront encore là ?

Et mes applications par exemple ? Montées avec le Framework .NET4, elles risquent d'être compatible avec les versions futures de Windows, la rétrocompatibilité devient fiable.
Dans 50ans, allez... dans 100ans, si le besoin du client n'a pas évolué, il l'utilisera encore ?

Ma réflexion de jeune développeur est surement naïve, mais quelle est la votre ?

Le débat doit rester centrer sur les applications "robustes" dans le secteur pro (ERP, besoin spécifique), et non sur de l'application grand public qui doit rester concurrentiel.

[sevyc64]

SI c'est des applications liées intimement à des process de fabrication ou des machines, la durée de vie peut effectivement être longue.

Si c'est de applications plus générale, ou plus "bureautique" par exemple comme des ERP, des GED ou autres, la durée de vie ne sera pas si longue.

Autre point à voir aussi, la durée de vie du matériel. Si on trouve encore facilement dans l'industrie des machines datent du début des années 80, je doute que l'on retrouve beaucoup de nos machines actuelles dans 30 ans, étant beaucoup plus complexe et performantes elles sont aussi plus sujette à pannes et à un vieillissement rapide.
Et sera-t-on capable de réparer dans 10 ans un PC d'aujourd'hui ????


Quant à la rétrocompatibilité, certes si elle devient fiable, je ne pense pas qu'il faille compter que le Framework Net 10.0 garde la compatibilité avec le 4.0.
Déjà le 3.5 et le 4.0, n'assure la compatibilité que jusqu'au 2.0. Si tu as un programme en 1.1 il te faudra réinstaller en plus le framework 1.1 pour le faire fonctionner.
D'ailleurs dans ce sens là, la compatibilité entre le 4.0 et le 2.0 n'est pas vraiment assurée puisque le framework .Net 2.0 est installé en parallèle du 4.0.

Quant au code, s'il est compatible, s'il nécessite quand même une recompilation, tu pourras à l'occasion changer la borne de ta date.


Il existe bien des systèmes tels que Java qui assure une vrai rétrocompatibilité, mais déjà des voix s'élèvent pour casser cette rétrocompatibilité qui est considérée de plus en plus comme contre productive pour les prochaines versions.
Et puis il suffit d'un simple rachat d'une société par une autre, pour qu'en quelques mois, une technologie que l'on croyait bien implantée et pour longtemps pose de nombreuses questions sur une éventuelle incertitude de son avenir.


De plus en plus, je pense que la durée de vie potentielle d'une application sera limitée à la durée de vie du matériel qui l'héberge.
Et quoiqu'il en soit les applications qui dépasse 30 ans sont quand même minoritaires et seront sans doute de plus en plus rare.

[Nebulix]

En tant que pro, dans un domaine "grand public", il serait de ton devoir de participer au mouvement général d'obsolescence programmée.
Sinon le "marché" le fera pour toi.
Mais peut-être que si tu utilises les technologies de " leur époque, sur le seul OS compatible, qui ont survécu presque 20 ans " tu as une chance que " Dans 10 ans elles seront encore là "

[Franck SORIANO]

Pour l'anecdote, je me suis retrouvé face à un sélecteur de date à implémenter, et j'ai du imposer une fin fixe à ce calendrier (pour éviter de boucler des milliers d'années).

En un mot, un futur bug de l'an 2000.

mais ont survécu presque 20 ans. Dans 10 ans elles seront encore là ?

20 ans, ce n'est rien. Le coeur de métier de mon employeur tourne avec des applis qui datent des années 70 !
Je travailles sur un "nouveau" projet qui vise à moderniser une partie du système. Le nouveau projet consiste en fait à modifier une appli qui avait déjà 10 ans d'existance... ça doit faire 4 ans qu'on la fait évoluer.
Les offres utilisant cette nouvelles appli (écrites avec des technos qui étaient déjà limites obsolètes en 2000) démarrent tout juste. Autant dire que l'appli en question restera en prod pendant encore au moins 15 ou 20 ans...

Lorsque tu as une grosse appli de gestion qui a nécessité plus de 50 années homme de dev, il faut du temps pour la rentabiliser.

Autre point à voir aussi, la durée de vie du matériel. Si on trouve encore facilement dans l'industrie des machines datent du début des années 80, je doute que l'on retrouve beaucoup de nos machines actuelles dans 30 ans, étant beaucoup plus complexe et performantes elles sont aussi plus sujette à pannes et à un vieillissement rapide.
Et sera-t-on capable de réparer dans 10 ans un PC d'aujourd'hui ????

J'ai déjà vu de vieilles appli écrites en COBOL pour des AS400 qui tournaient sur des PC dans des émulateurs.
De plus aujourd'hui, à l'heure de la virtualisation on peut très bien imaginer avoir une VM qui virtualise le matériel d'aujourd'hui et qui continuera à fonctionner dans 20 ans, avec le même matériel virtuel, mais dans une machine hôte complètement différente...

Et quoiqu'il en soit les applications qui dépasse 30 ans sont quand même minoritaires et seront sans doute de plus en plus rare.

Ca dépend de ce que tu entends par une "application" qui dépasse 30 ans". Si tu penses à une appli que tu écris un jour, et qui fonctionne encore tel quel 30 ans après, c'est sûr que ça ne court par les rues.
Mais une application que tu développes un jour. Puis que tu fais évoluer au fur et à mesure des besoins, en restant prisonier d'un coeur historique qui t'empêche de faire ce que tu veux à chaque évolution, il y en a beaucoup.

[FailMan]

Et puis il suffit d'un simple rachat d'une société par une autre, pour qu'en quelques mois, une technologie que l'on croyait bien implantée et pour longtemps pose de nombreuses questions sur une éventuelle incertitude de son avenir.

Comme Oracle avec Java non ? Le langage n'est pas menacé en tant que tel mais sa philosophie un peu, non ?

[el_slapper]

+1 avec Franck. J'ai eu à refondre des applis écrites en 72. Là, je code un appel à un accesseur écrit en 89, et que ne s'éteindra qu'en cas de rachat. Dans le domaine professionel hors-informatique, les applis sont là pour durer.

[sevyc64]

Comme Oracle avec Java non ? Le langage n'est pas menacé en tant que tel mais sa philosophie un peu, non ?

Apparemment avec Oracle tout semble possible

La rupture est entrain de se passer pour OpenOffice.org, ou un fork assurera (peut-être) la survie de la suite hors emprise d'Oracle

On peut se poser la question de l'avenir de MySQL qui rentre en concurrence avec OracleExppress. La aussi un fork essaye de prendre la relève mais arrivera-t-il à s'imposer

Mais quant à Java, il pourrait ne plus évoluer, ou bien devenir payant, sans compter les royalties que Oracle essaye de récupérer sur les versions déjà existantes, notamment une version qui aurait été modifiée par Google sans autorisation.
Là par contre, il semblerait qu'aucun fork soit possible sans rétribution d'Oracle
Cale annonce-t-il le déclin du langage qui est déjà à légère perte de vitesse régulière depuis quelques années selon Tiobe ?