Après son best seller “Better, Faster, Lighter Java” (il est dans la liste) Bruce Tate fait beaucoup parler de lui. Son interview déchaîne les passions sur theserverside.
En tout cas cette interview contient pas mal de remarques qui m’ont paru très pertinentes et synthétiques.
The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases.
Si j’y réfléchi deux secondes c’est effectivement ce que je fais depuis que je travaille. Il poursuit en expliquant que java a résolu le problème d’une manière “slow & clean” alors que d’autre langage le font d’une manière “quick & dirty”, je pense à php, Tim Bray aussi.
Avec Ruby On Rails Bruce Tate pense avoir trouvé une manière “quick & clean” le meilleur des deux mondes. La preuve? Un projet java non fini au bout de 4 mois a été bouclé en une grosse semaine avec ROR. J’ai fait passer le “10 minutes test” à ROR. Les 10 minutes se sont transformée en 2 heures mais j’ai effectivement pu réaliser une appli toute bête avec un formulaire CRUD. Et l’appli et effectivement clean quelqu’un qui connaît ROR n’aura aucune difficulté à comprendre ce qu’elle fait et à la maintenir.
Ca ne veut pas dire que ROR est une solution miracle, sur certain point la plateforme java reste incomparablement meilleure. Il donne les exemples des problèmes de two-phase commit et d’intégration avec beaucoup de système legacy.
Il met ensuite le doigt sur une des faiblesses de java:
Java doesn’t express data very well. While Java can declare structures that hold data, it doesn’t express the data itself well. And, that’s a big reason we’re seeing a lot of XML being bolted on to Java frameworks
Et effectivement je code de plus en plus en xml… Mais depuis quand xml est-il un langage de programmation?? Est-ce que les annotations sont la réponse à ce problème?
Enfin il traite du problème du “design by committee”
Sometimes, the JCP seems to say ‘Find a problem. Build the standard. And, lastly, gather the experience.’ To me, that’s wrong.
C’est ce qui conduit a des specs comme EJB 1 et 2, WS-*… A l’opposé l’approche qui consiste à implémenter en premier puis à spécifier ce marche a produit par exemple Spring et Hibernate (ATTENTION on parle du processus pour créer un standard pas un application métier). C’est aussi l’approche que recommande l’IETF pour la définition des standards qui font tourner l’Internet, ça leur a plutôt réussi, non?
