Depuis que je m’intéresse à l’informatique, j’entends parler de « la fin de la programmation ».
Plusieurs mythes se cachent derrière « ce fantasme » :
- « La programmation est une tâche répétitive, finalement sans grande valeur ajoutée, et donc facile à automatiser » ;
- « L’informatique fait des progrès, et on va arriver à une situation ou il suffira de décrire le problème, l’ordinateur se chargera de le résoudre » ;
- « On va remplacer la programmation par des outils graphiques : plus besoin de programmer, on assemble des composants, et hop, le problème est résolu ».
Mes réponses :
- Si la programmation est parfois répétitive, c’est une activité à haute valeur ajoutée : c’est bien la qualité d’un programme qui fera la qualité du service. Aujourd’hui, rien ne remplace la qualité d’un bon programmeur ;
- Aucun ordinateur n’est aujourd’hui capable de résoudre automatiquement un problème, et rien de permet de dire qu’on pourra faire ça dans les prochaines années ;
- La programmation graphique est un leurre : cela donne l’impression que c’est plus facile, mais il n’en est rien. Ce qui est important, c’est la concision de la programmation : un programme court, bien écrit, est facile à lire, aussi facile à lire qu’un graphique.
Bien sûr, les outils informatiques font de vrais progrès, qui permettent de gagner en productivité. Ainsi, par exemple, dans la plupart des langages modernes, le programmeur ne gère pas directement la mémoire (libération automatique des objets inutilisés).
Quelques facteurs permettant de gagner en productivité :
- L’environnement de développement : certains environnement sont de pures merveilles pour programmer vite et bien (je pense à Visual Studio par exemple : Jérémy sera content ce coup ci 😉 ).
- Les librairies : plus personne ne programme « à partir de zero ». Pour n’importe quel problème, on trouve des composants, permettant de gagner du temps : soit dans du code « open source », soit en achetant des bibliothèques. Les communautés de programmeurs sont très bien organisées, et Internet est une place d’échange très vivante.
Comment cela peut évoluer ?
A mon sens, beaucoup de choses peuvent évoluer…
Ainsi, la séparation entre la logique applicative et la présentation n’est pas encore parfaite. C’est pourtant une séparation tout à fait fondamentale.
Autre exemple, on parle beaucoup de services Web 2.0 : et bien la programmation de tels services, avec une intelligence applicative répartie, entre le client et le serveur, est très délicate, avec des outils très manuels. Je suis convaincu que des outils beaucoup plus puissants vont émerger, permettant une programmation « Web 2.0 » plus propre et plus facile.
Mais un autre axe, a mon sens fondamental, c’est la sortie de la programmation « stateless » (difficile à expliquer simplement !) : un programme stateless est un programme qui s’arrête à chaque page web envoyée. Le serveur gère des centaines ou des milliers d’utilisateurs simultannés. Pour ne pas surcharger ce serveur, le programme s’arrête après avoir renvoyé une page. Avantage : le serveur peut gérer beaucoup plus d’utilisateurs simultannés, car il ne s’occupe que de ceux qui font une requête (un utilisateur qui regarde sa page ne consomme donc plus aucune ressource sur le serveur). Mais cela rend les programmes difficile à lire, car découpés, écran par écran. A mon sens, cette programmation est de trop bas niveau, ce découpage devrait être automatisé.
Dans le terme se trouve le jeu de mot.
Quand un simple open-office permet de créer la page htm comme nous créons le fichier texte, nous pouvons dire que la machine a remplacée le programmeur.
Quand d’un savant assemblage, nous créons la fonction spécifique à l’aide de méta-langages somme nous encore des programmeurs, ou de savants assembleurs ?
Est-ce que le pilote de la voiture de course connait la dimension de la visse au bout du vilebrequin ?
Cordialement
Salut François
Je pense qu’il reste encore une petit place pour des développements « en partant de zéro ». Tu as raison, on peut tout faire a base de « mashup » de librairies, mais au final on se retrouve avec des programmes souvent lourds, embarquant un tas de fonctions inutiles.
Les moteurs qui demandent de la vitesse fonctionnent beaucoup plus vite en C par exemple. Bien sur c’est un peu plus délicat à programmer et la gestion de la mémoire est un point difficile (malgré des années d’expérience).
@Franck> Hello ! Bien vu, ce billet est parti des mashups (puis j’ai dérivé…). Je voulais effectivement dire que l’idée d’un assemblage de service avec des mashups, et des outils graphiques pour « faire la glue » est à mon sens plus marketing qu’autre chose : pour faire des services, il faut des programmeurs.
Sinon, je suis également d’accord avec ton point, pour certains services, il peut être adapté de partir « d’en bas ».
Ceci dit, on a avait discuté, à ta place, je ferais plutôt du C++ que du C : la perte de perf est réellement minime (on peut faire du C avec du C++) et le gain en qualité, en lisibilité est important.
François
@ François > Il faudrait organiser un grand duel, en développant un gros moteur d’AI dans les deux langages et en regardant les performances 😉
Je ne sais pas si de tel benchmark existent déjà ?
Bon week end
@Franck> Faudrait d’abord définir ce qu’on mesure. Performance, évolutivité, modularité, fiabilité, … Si on est « perf pure », alors le C va bien.
Quand j’étais à la R&D d’Orange, j’avais fait moi même des bench, entre le C, le C++ et Java.
Si tu t’appliques, il n’y a pratiquement pas de différence de perf entre le C et le C++ (il faut mettre en place des paterns permettant de ne pas avoir à gérer la mémoire dynamique dans les boucles les plus sensibles du programme.
Bon WE à tous !