Java = 4×4 (la suite)

Philip Greenspun affirme que Java est le 4×4 des langages de programmation : surpuissant et trop gourmand en ressources pour un usage quotidien. Sur Slashdot, les commentaires sont allés bon train. Il a été précisé que l’observation de Greenspun se limite au contexte du développement Web classique. Je retiens de cette discussion les points suivants. :

  • Java, en soi : Dire que Java est un 4×4 ne signifie pas que Java n’est jamais un bon choix. Pour certains usages, rien ne vaut un 4×4. Mais pas pour aller déposer les enfants à l’école. Java permet aussi bien de développer des applications qui sont executées dans les téléphones portables que des systèmes d’intégration d’applications d’entreprises de grande échelle. C’est pourquoi Java serait surchargé de sophistication inutile (« bloatware ») pour chacun de ces usages. Java fournit une solution homogène à presque tous les types de problèmes applicatifs rencontrés dans l’entreprise mais au prix d’une complexité et d’un coût accrus.
  • Java et Python : Comparer Java à Perl ou à Lisp est une erreur, le langage le plus comparable est plutôt Python (ou C#). Pour faire un site web simple, Python serait préférable à Java. De même pour des activités plus expérimentales.
  • Java et PHP : Un avis récurrent est : « PHP pour le Web, Java pour les applications requérant des traitements logiques très complexes côté serveurs ».
  • Java et VB : L’avantage principal de Java (par rapport au langage C# ou VB.Net de Microsoft) est la portabilité. Visual Basic est préférable à Java dans tous les cas où l’on a besoin d’une riche interface graphique pour l’utilisateur (en client-serveur) et où l’application à développer ne doit pas tourner ailleurs que dans Windows. VB (pas forcément VB.Net) manque cruellement de certaines fonctionnalités ce qui oblige trop souvent le développeur à réinventer la roue.
  • Perl : Perl est extraordinairement puissant (permet de faire des choses très sophistiquées en un nombre de lignes de code très réduit) mais les développements sont difficiles à maintenir car le code est peu lisible lorsque toute la puissance de Perl est mise en oeuvre.
  • JSP : la manière dont le code Java est mélangé au code HTML de présentation dans la technologie JSP rend le tout difficile à maintenir. Le système de modélisation de pages (templates) de JSP comporte le risque intrinsèque de laisser les développeurs créer des applications immaintenables. Une grande rigueur de développement est donc nécessaire. On rencontre le même type de risque avec les technologies de scripting similaires (PHP, ASP, DTML) mais la manière de faire avec JSP ajouterait à cela des défauts dus au fait que Java n’a pas été conçu spécifiquement pour ce type d’usages : plus de lignes à coder et à maintenir, complexité accrue, adéquation moindre aux besoins Web classiques…

Un article critique au sujet de Java : Java’s Cover.

2 réflexions au sujet de « Java = 4×4 (la suite) »

  1. Ping : AkaSig :: EJB : ce qu’il ne faut pas faire avec

  2. Ping : AkaSig :: Stratégie architecturale

Les commentaires sont fermés.