Si je devais refaire le monde…

Bon, on est vendredi, c’est bientôt le WE, on peut se lâcher un peu, non ?

(billet un brin technique, je m’en excuse auprès de mes lecteurs non programmeurs)

Maintenant, le sujet n’est pas si loin que ça des sujets habituels de ce blog, puisque mon idée, c’est de parler langage de programmation.

Donc, quand on veut programmer sur Internet, on a le choix, pour faire simple, entre deux options :

  • Soit vous utilisez PHP, ou un autre langage de script.
  • Soit vous utilisez Java, ou autre .NET

Il y a bien sûr tout un tas d’autres solutions, le propos de ce billet n’est surement pas de faire un dictionnaire des langages de programmations.

A mon avis, tout ça est loin d’être abouti.

Les langages de type script permettent de développer rapidement un service, mais l’idée même de ne pas être compilé et faiblement typé, fait que le risque de découvrir des erreurs « en ligne » est important.

De l’autre côté, les langages de type « java » débouchent bien souvent sur des systèmes lourds, complexes à mettre au point et à maintenir.

Tout cela n’est pas très satisfaisant.

Alors, si on devait refaire « ce monde là », on ferait quoi ?

Voici ma « shopping list » pour un langage idéal pour le web « de demain » :

De bons fondamentaux

A mon sens, un bon langage devra être :

  • Objet
  • Fortement typé
  • Compilé

Donc, à ce stade, c’est plus Java que PHP ;).

Gestion native des sessions

L’une des caractéristique du Web, c’est la double contrainte, entre la nécessité de gérer de véritables applications en ligne, et un protocole « state less » : le serveur répond à une requête, et ne fait pas nativement le lien entre deux appels d’un même client (affichages de deux pages successives d’un même service, deux étapes du processus achat par exemple).

Ce point, hyper basique, n’est pas traité nativement par les langages. On se « débrouille » avec des couches applicatives, qui permettent de mettre en oeuvre des notions de sessions.

Mais le résultat ne simplifie pas les choses. A chaque appel, pour chaque page, le programmeur doit aller chercher les éléments de contexte, pour servir les bonnes informations au client. C’est compliqué, et c’est bien dommage de devoir repartir de si bas…

A mon sens, ce problème devrait être complètement « encapsulé » dans le langage.

Gestion native de la persistance des données

Bon, puisqu’on refait le monde, on peut bien bousculer le paradigme de la base de données.

La séparation entre le langage de programmation et la base de données est, à mon sens, complètement artificiel.

Et cette séparation pose des problèmes, de modèle (les langages sont objets, et la base de données est relationnelle), et de performance : la communication entre le langage de programmation et la base passe par des interfaces textes :

On transmet des ordres SQL en format texte à la base, et on récupère des chaînes de caractères en sortie. Tout cela est très peu performant.

Donc, la vrai bonne solution serait d’intégrer les deux.

Orienté Web, pour de vrai de vrai

C’est bien ce qu’à fait le PHP, qui, à la base, permet juste d’insérer quelques éléments dynamique dans du HTML.

Mais là encore, je ne suis pas convaincu par cette approche, qui consiste à considérer que le Web, c’est du texte HTML.

Pour moi, le Web, c’est plutôt un arbre (DOM). De loin, ça peut sembler être la même chose, mais en fait, en prenant un peu plus de hauteur, cela permet de manipuler des choses beaucoup plus intelligentes. Puisqu’on est au niveau des concepts, on peut avoir une manipulation intelligente de ces concepts, alors que le texte, il n’y a aucune chance de faire quelque chose d’intelligent !

Le langage manipulerait donc des arbres, et bien sûr, au moment de sortir la page, on génèrerait bien le texte HTML.

Traitement des erreurs multi vues

Si vous avez déjà programmé, vous savez qu’un programme, c’est 10% pour traiter les cas normaux, et 90% pour traiter les erreurs.

Et en plus, les erreurs, il y en a de tous types.

Mon idée, que je n’ai réellement vue nul part, c’est de permettre de programmer « en couche » (qui a dit culotte ?).

Intuitivement, l’idée, c’est de programmer comme on faisait un dessin annimé : on dessine le fond, puis, sur chaque calque, on rajoute des informations. On rajouterait donc un calque par type de traitement d’erreurs.

Quelle avenir pour une telle idée ?

Probablement aucun…

Mais je trouve ça sympa, de remuer les concepts, ça permet de « sortir du cadre » et de se poser tout un tas de questions passionnantes !

12 commentaires

  1. Bonjour François,
    Interessant comme article, je me pose quelque peu des questions similaires, mais sur un angle autre.
    Il y a une notion qu’y n’apparaît pas dans ton article, c’est la question de la montée en charge.
    Avec le marketing à la performance qui s’impose, il est fréquent et relativement aisé de créer un trafic conséquent sur un site web à partir du moment où on a un minimum de moyens ( et à mon sens, quand on commence à se poser ce genre de questions d’optimisation de la programmation web, c’est que l’on est sérieux sur le sujet, et qu’on se donne les moyens).
    C’est là que je me pose la question de la validité de la programmation objet : conceptuellement, cette approche est plaisante ( c’est totalement platonicien, et reflète bien une de nos manières de penser le monde). Mais aboutit à de la mémoire partagée, et tous les problèmes liés…
    Je surveille de très près en ce moment l’évolution de la programmation fonctionnelle ( Erlang, notamment, commence à se structurer, avec des bases de données — dont une intégrée — des serveurs web, des frameworks et même quelques CMS très intéressants; Haskell devrait te plaire sur le typage et la compilation ). Cette approche fonctionnelle permet des applications réellement multitâches, gérant la totalité des coeurs des processeurs actuels, permettant de déployer une application sur plusieurs machines distantes de manière quasi transparente, etc… car il n’y a rien qui est partagé.
    Après, PHP et Java règnent du fait de « l’abondance » des profils connaissant ces langages….

  2. @Julien> Merci, intéressant.

    Tu as complètement raison, la scallabilité est clairement un critère clé qui devrait être nativement géré par un langage web de nouvelle génération.

  3. Hum, la monté en charge n’est pas un problème de langage mais d’architecture. Erlang est conçu pour faire de la programmation concurretielle, c’est à dire qu’il est théoriquement (je ne pratique pas) plus facile de bien exploiter des processeurs multi-coeur en erlang. Ce qui doit permettre d’améliorer la performance. Mais la perf != monté en charge.

    Sinon visiblement google se pose ces questions:
    http://code.google.com/p/noop/
    http://golang.org/

  4. Bonjour François,

    Gestion native des sessions : Les concepts actuels sont ainsi fait car à la base, il n’y a pas un problème technique mais un problème de sécurité : on doit revérifier l’identité à chaque appel, c’est lourd mais c’est fiable.
    S’il existait une connexion persistante cela poserait aussi des problèmes de sécurité, le pirate aurait tout le temps de se « greffer sur la ligne ». (je précise aux connaisseurs, avant de me prendre un sabre laser, qu’on parle ici d’accès grand public et pas d’https sur un port particulier avec des murs de feu dont seuls les initiés connaissent les adresses ip de connexion ou les clés WAPWEPWAPOUDOUWAP…)

    Bref, à ce niveau, c’est pas si mal actuellement 🙂

  5. En tout cas le monde de l’applicatif évolue (cf magento ou crowdfusion) en epuisant au maximum les possibles du PHP. Mais on sent bien que les limites commencent à être atteintes et que peut être une solution est de passer :
    1- a des langages plus performants (cf ci dessus)
    2- une distribution par images ( ami AWS ec2 , xen etc… ) afin de ne plus être limité par un marché du hosting orienté PHP et qui de plus permet des distrib configurées pour des performances optimales. Cela me semble d’autant plus cohérent que les VPS et autres virtualisations s’imposent comme solution viable.

  6. Excellent article.

    Développeur WEB moi même, on retrouve y retrouve les notions essentielles.

    Aujourd’hui, après avoir testé pas mal de langages (et j’en testerai encore sûrement beaucoup) je reste PHP pour plusieurs raisons :

    – rapidité de développement (c’est une notion très importante lorsqu’on doit être productif). En codant proprement le PHP ammène de très bons résultats.
    – architecture serveur. PHP est présent partout. Cette notion là est indispensable surtout lorsqu’on édite un CMS libre.
    – La documentation, les libraires disponibles
    – La maîtrise par de nombreux développeurs.

    Le langage n’est pas parfait, j’espère qu’il évoluera dans le bon sens. Quoi qu’il en soit c’est actuellement celui qui répond le mieux à mes besoins.

  7. Il y a quand même pas mal de solutions répondant à ta problématique.

    Pour le langage il y a java comme tu le précises. Pour la persistance tu peux utiliser un framework facile à mettre en place appelé Hibernate et qui te permet de mapper tes objets sur la base de données et de travailler tes données dans un langage objets plutôt que SQL. Ça va donc t’éviter du mapping table vers objets et inversement. Pour la problématique des session c’est vrai qu’en JAVA malgré tut ce que l’on pourra te dire aucun framework ne fait de miracle. Ça reste un point assez noir du dev web malgré les framework et api comme Spring MVC, JSF, JAVA FX, etc…
    Pour le côté montée en charge, tolérance au panne etc… Tu peux par exemple utiliser google apps qui depuis 1 an maintenant accepte le langage java. Certe il n’y a pas tout de dispo mais c’est déjà assez puissant pour héberger une partie de ton application.

  8. @Yoan> Yep, effectivement, le PHP est un très bon compromis aujourd’hui

    @Jérôme> Oui, comme souvent en informatique, la question n’est pas : « puis je faire ceci ou cela » parce qu’on trouve des solutions.
    La question est (plus compliqué) : « vais je pouvoir le faire simplement ? Est-ce que ça sera facile à maintenir ?… »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *