L'évolution de la puissance de calcul couplée à la baisse du prix des équipements informatique et sa généralisation n'a que peu changé une constatation faite il y a plus de 30 ans : il y a une difficulté intrinsèque à estimer correctement l’effort requis et la fiabilité du résultat de l’activité de production de logiciel, les développeurs et utilisateurs sont sans cesse confrontés aux erreurs graves de sous-estimation des coûts et des délais, ainsi que des risques, des projets de développement logiciel.

Outre les problèmes de spécifications et de gestion des équipes, les technologies utilisées sont à mon humble avis un frein important : programmer est une "métaphorisation" d'une spécification, d'un besoin dans un langage très lié à l'outil qu'on utilise : l'ordinateur. Métaphorisation, au sens où programmer consiste à transformer la représentation humaine d'un traitement de données (dans les logiciels orientés gestion), de comportements d'agents (dans le jeux)

On constate, en caricaturant un peu, qu'il existe deux types de langage :

• les langages de haut niveau permettant un développement rapide car la métaphorisation à effectuer est moins spécifique à la machine : elle est plus proche (ou moins lointaine, comme on préfère) d'une façon humaine de se représenter les choses.
  La notion de pointeur y est généralement absente, ils gèrent leur mémoire eux-même, ils sont concis. Ces langages sont généralement assez lents.


• les langages bas niveau permettent de produire du code cible rapide, mais ils restent complexes à maîtriser (gestion semi-automatique de la mémoire, pointeurs, volubilité [4]) et nécessitent de bien connaître le fonctionnement de la machine. Leur complexité et leur volubilité est génératrice de bugs.[4]

Peut-on considérer, qu'outre les habitudes et les coûts de migration, le fait que les langages haut niveau soient lents[5, 6 ?], reste des freins à leurs développement dans de nombreux cas (pour des applications serveurs par exemple) ? Ou peut-on considérer qu'étant donné que l'on dispose d'une puissance de calcul très confortable, des langages produisant du code relativement lent sont suffisants ?

À l'heure où les processeurs deviennent nativement multi-thread et/ou multi-core, les langages bas-niveau ne vont-ils pas devenir prohibitifs en coûts de développement, car devant gérer la programmation parallèle "à la main" ? [1,2,3]
Ou doit-on compter sur des compilateurs permettant de cacher cette complexité de la programmation parallèle (ADA95) ?

Il est à parier que ces paramètres seront très importants dans les choix technologiques futurs et dans l'évolution de la réussite des projets informatiques.


Problématiques du multi-core :
[1]http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)

Faut-il adapter l'enseignement à la programmation parallèle ?
[2]http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
[3]http://www.onversity.net/cgi-bin/progcafe/cafetted.cgi?Eudo=bgteob&(...)


On constate qu'avec le temps, le nombre de projets informatiques réussis augmente :

1995 : Succès 16% ; Mitigés 53% ; Échec 31%
2000 : Succès 28% ; Mitigés 49% ; Échec 23%
2004 : Succès 29% ; Mitigés 53% ; Échec 18%
(source : http://www.agentsolo.com/membre/llconseils/capsules/9322.jsp(...) )

La part de succès mitigé (dépassement du budget, du temps imparti, cahier des charges insuffisament respecté) reste à peu près inchangée.

Je n'aborde pas les problématiques et technologies de spécifications qui sont pourtant très importantes, c'est un tout autre débat. Je m'intéresse à l'outil final permettant la métaphorisation de l'expression du besoin, le langage.

La distinction haut niveau / bas niveau s'effectue principalement sur la gestion automatique de la mémoire, car comme le dit Joel Spolsky "The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically. It can be with reference counting or garbage collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of scripting languages. "
[4]http://www.joelonsoftware.com/articles/APIWar.html(...)
Par extension, on peut mettre dans cette catégorie les langages permettant une plus grande productivité, par exemple de par une plus grande abstraction.

Globalement, les langages de très haut niveau sont assez lent parce que les techniques de compilation ne permettent pas d'optimiser le code de façon à être plus proche de la machine, bien que cette tendance ait l'air de s'infirmer lentement :

[5]http://linuxfr.org/2005/05/19/18959.html(...)
[6]http://shootout.alioth.debian.org/benchmark.php?test=all〈=all(...)


Néanmoins, Java et C# qui s'imposeront de force dans l'industrie restent des langages dont le compilateur produit du code assez lent. Je ne saurais dire si c'est un choix des éditeurs ou si cela est intrinsèque aux technologies utilisées par les compilateurs.

En effet, les langages objets s'imposent, mais à part SmartEiffel et Lisaac, aucun ne résoud la liaison dynamique coûteuse en performance (par vidage du cache du processeurs et impossibilité d'inliner le code). SmartEiffel n'a pas l'air d'être prêt à s'imposer malgré une maturité grandissante. Il reste un langage universitaire.

On peut entendre de tout : "Non, la lenteur du code produit par les compilateurs est secondaire car nos machines sont maintenant très puissantes" ou au contraire "Oui, de nombreux logiciels gâchent les performances disponibles, quand d'autres (logiciels serveurs, jeux, logiciels graphique exigeants) nécessitent des temps de réponse très courts".

Peut-on considérer que ce iatus est central en informatique, ou tend-il à disparaître ?

Pour s'enfoncer plus loin dans le débat, il faut le contextualiser avec l'évolution du matériel où l'on se trouve dans une situation où les fabriquants de processeurs "ne savent plus quoi faire" du nombre de transistors sans cesse en augmentation exponentielle. Résultat, on se tourne vers le multi-core et le multi-thread.
Des questions fusent alors :

• doit-on adapter l'enseignement afin d'apprendre la programmation concurrente ?


• doit-on compter sur des compilateurs capable de masquer la concurrence par le haut niveau (un peu comme ADA) ?

( http://ada.developpez.com/cours/enseigner/(...) section "Deux exemples de programmation concurrente")
Reste qu'on peut espérer de nouveaux paradigmes de développement ainsi que nous y invitent Jaron Lanier :

http://java.sun.com/features/2003/01/lanier_qa1.html(...)
http://java.sun.com/features/2003/02/lanier_qa2.html(...)

A suivre...

> Lire le journal (57 commentaires, moyenne: 4,8).