mercredi 4 mars 2009

Développement durable

Lors d'une entrevue, un interviewer m'a dit que le stagiaire embauché pour l'été allait faire l'analyse et, si le temps le permet, l'implémentation d'un renouvellement d'un système qui avait été en production pendant une vingtaine d'années. Il est à la recherche d'un langage de programmation qui va permettre au nouveau système d'avoir une durée de vie aussi longue que l'ancien système. Ceci m'a amené à me poser la question suivante : quels langages de programmation actuels permettraient de créer un système d'une assez grande amplitude pour une aussi longue durée de vie? Essayons de trouver une technologie qui permettrait cela.

Python
J'ai été surpris que Python ait été abordé par la personne avec qui j'ai eu l'entretien ce matin. Malgré sa popularité croissante, je crois que Python n'a pas encore fait ses preuves comme langage pouvant résister au temps. Un autre point contre l'utilisation de Python comme langage durable est sa grande volatilité. En effet, la version 3 de Python qui est parue récemment n'est pas rétrocompatible avec les anciennes versions. On ne peut pas savoir si ceci va se reproduire à l'avenir. Aussi, puisque le bassin de programmeurs Python actuel est assez limité, les programmeurs Python seront d'autant plus rares dans le futur si le langage est encore fonctionnel, mais moins populaire. D'un autre côté, Python supporte plusieurs plates-formes (possibilité de changer de plate-forme durant la vie du système) et simple à apprendre.

.Net
Avec une nouvelle version tous les deux ans qui assurent une rétrocompatibilité *presque* complète est-ce que les produits créés avec la technologie de Microsoft vont vieillir avec grâce? Laissez-moi en douter. Premièrement, les logiciels vont être confinés sur des ordinateurs qui ont un système d'exploitation Windows. Le support de Microsoft pour Windows n'est pas éternel, mais il tout de même possible de continuer à l'utiliser sans support malgré les risques potentiels. Aussi, dans une vingtaine d'années, est-ce que le framework .Net 3.5 va être encore supporté ou encore utilisable alors qu'une version proche de 10.5 du framework va être sortie? Est-ce que le langage va être aussi éphémère que d'autres en provenance de Microsoft comme VB6 ou le BASIC?

C++
Ce langage de programmation est celui que je crois être en mesure de répondre aux besoins d'un environnement de production pendant une vingtaine d'années. Premièrement, C++ a déjà fait ses preuves et le standard change rarement et les changements apportés ne sont pas majeurs. Cependant, il arrive que le code source doit être modifié afin d'être compilé par un compilateur plus récent (par exemple, la transition entre GCC 3 et GCC 4). Le bassin de programmeur C++ est de grande taille.

Java
Je crois que Java est au même niveau que C++ pour la création d'applications durables : les changements de version passent souvent sans embûches et le nombre de développeurs Java est assez grand pour suffire à la demande pour les futures maintenances. De plus, contrairement aux programmes C++, les applications Java ont moins de dépendances envers des librairies externes qui peuvent être rendues obsolètes pendant la durée de vie du système.

Conclusion
Il se peut que les analystes en poste il y a vingt ans se posaient la même question et qu'ils trouvaient eux aussi que les langages de programmation de leur époque ne semblaient pas être appropriés pour un projet axé sur le long terme. Ils ont toutefois réussi à créer des systèmes qui ont su résister au temps. Peut-être que dans vingt ans, les programmeurs Java vont être une denrée rare et prisée comme le sont les programmeurs Cobol actuels. Finalement, il y a une possibilité que la qualité de l'analyse du système importe plus que le langage de programmation choisi lors de la création d'un système ayant une longue durée de vie.

2 commentaires:

  1. vous oubliez le Cobol qui depuis 1950 est le language qui supporte la plupart des applications bancaires, de gestion ou même Internet voir son utilisation dans le cadre d'une architectrure SOA.
    cordialerment.

    RépondreSupprimer
  2. Le but de ce billet consiste à chercher un successeur au Cobol. Je ne crois pas que de nos jours on peut partir un nouveau projet d'envergure en Cobol. Les programmeurs Cobol présents sur le marché sont rares et donc dispendieux. Ce problème ne devrait pas se corriger avec le temps.

    Désolé pour la lenteur de réponse.

    RépondreSupprimer