Joshua Bloch : La conscience de la plateforme Java
« Le langage de programmation Java a épuisé son budget de complexité avec les changements introduits dans la version 5.0. » C'est une phrase surprenante, surtout venant de celui qui l'a prononcée. Joshua Bloch a passé des années chez Sun Microsystems à concevoir les ajouts en question, et la version JDK 5.0 qu'il a aidé à façonner fut l'expansion la plus ambitieuse que le langage ait jamais connue. Puis il a dit au monde que c'était suffisant. Cet instinct — de surveiller un système qu'il avait personnellement agrandi, et de penser en termes de budgets plutôt qu'en termes de fonctionnalités — résume tout le personnage en une seule ligne.
Southampton, Columbia, Pittsburgh
Bloch est né le 28 août 1961 à Southampton, dans l'État de New York. Il a obtenu une licence en informatique à la School of Engineering and Applied Science de l'Université Columbia, puis a rejoint Carnegie Mellon pour un doctorat, terminé en 1990. Sa thèse, « Une approche pratique de la réplication d'objets de données abstraits », a été nominée pour le prix ACM de la thèse de doctorat distinguée.
Le titre mérite d'être lu deux fois. Même en tant qu'étudiant diplômé, le mot clé dans le travail de Bloch était pratique. Il n'attaquait pas la réplication comme un problème théorique dans les systèmes distribués ; il cherchait une version que les ingénieurs pourraient réellement déployer contre des objets de données abstraits. Il a passé le reste de sa carrière dans ce même fossé étroit et peu à la mode entre ce qui est prouvablement correct et ce qu'un programmeur en activité peut utiliser en toute confiance.
Sun, et le Collections Framework
Après une période chez Transarc en tant que concepteur de systèmes senior, Bloch a rejoint Sun Microsystems, où il est devenu ingénieur distingué et a dirigé la conception et la mise en œuvre de plusieurs pièces qui rendent Java reconnaissable comme Java. Le Java Collections Framework est la plus importante d'entre elles : l'ensemble des interfaces et des implémentations — listes, ensembles, cartes et les algorithmes qui les manipulent — sur lesquels chaque programme Java a été construit depuis. Il a également dirigé le package java.math et le mécanisme d'assertion du langage, et a conduit des améliorations majeures dans le JDK 5.0.
C'est un type particulier d'écriture. Une bibliothèque de collections n'est pas une application ; c'est un vocabulaire. Des millions de programmeurs qui n'ont jamais entendu le nom de Bloch passent leur vie professionnelle à l'intérieur des noms et des verbes qu'il a choisis, et la forme de leur pensée est contrainte par la forme de ses interfaces. Se tromper n'aurait pas produit un mauvais programme ; cela aurait produit un mauvais langage pour écrire des programmes, de façon permanente.
Vingt questions, huit minutes au chronomètre et un centile mesuré face à tous ceux qui l’ont passé. Sans inscription.
Passer le test de QI →Effective Java
En 2001, il a publié Effective Java, et il a fait quelque chose que les livres sur les langages de programmation font rarement : il est devenu l'autorité morale d'une communauté. Structuré comme une série numérotée d'éléments indépendants, chacun énonçant une règle puis argumentant à partir de modes de défaillance réels, il a remporté le prix Jolt en 2001. La deuxième édition, en 2008, est passée de cinquante-sept à soixante-dix-huit éléments sans devenir plus difficile à lire ; une troisième est arrivée en 2017.
Il a écrit deux autres livres avec des collaborateurs. Java Puzzlers, avec Neal Gafter en 2005, est une anthologie des pièges du langage — du code qui se comporte correctement selon la spécification et de manière insensée selon l'intuition — présenté comme un exercice de diagnostic. Java Concurrency in Practice, en 2006, a été écrit avec cinq collaborateurs, dont Doug Lea, et est devenu la référence standard sur la chose la plus difficile que la plateforme demande à ses utilisateurs.
Google, et la conception d'API
Bloch a été l'architecte Java en chef de Google de juin 2004 à août 2012. C'est là que sa préoccupation centrale s'est cristallisée en un argument public. Son article de conférence de 2006, « Comment concevoir une bonne API et pourquoi c'est important », traite la conception d'interface comme une discipline avec des enjeux plutôt qu'une question de goût, au motif qu'une API est un contrat que l'on ne peut pas renégocier. Il a décrit la frustration concrètement : chez Google, il ne pouvait pas fournir d'implémentations alternatives pour certaines classes car elles avaient été déclarées comme des types concrets plutôt que comme des interfaces — une décision prise des années plus tôt par quelqu'un d'autre, ce qui, comme il l'a dit, est le genre de limitation que « les développeurs ordinaires ressentent chaque jour ».
Ses conseils ont une saveur constante : l'humilité quant à son propre jugement. Ne vous répétez pas ; tournez-vous vers une bibliothèque établie, en particulier pour la concurrence, plutôt que d'écrire la vôtre. Méfiez-vous du sentiment que les avertissements généraux sur l'optimisation prématurée ne s'appliquent pas aux autres — « il est facile de penser que les avertissements généraux sur l'optimisation prématurée ne s'appliquent pas à vous, parce que vous savez simplement quel code est critique en termes de temps ». Et lisez The Elements of Style, car « la bonne programmation et la bonne écriture sont toutes deux une question de clarté et d'économie d'expression ».
Pourquoi Joshua est qualifié de génie
La faculté en question n'est pas l'invention pure mais une chose plus rare : la capacité de voir un logiciel du point de vue de l'étranger qui devra l'utiliser, et de concevoir pour les erreurs probables de cet étranger plutôt que pour sa propre compétence. Une API, selon le cadre de Bloch, est un langage imposé à des personnes qui n'y ont jamais consenti et ne peuvent pas l'amender, ce qui fait de sa conception un exercice d'anticipation des abus à grande échelle, des décennies à l'avance. Le Collections Framework en est la preuve : un vocabulaire utilisé par une énorme fraction de tous les programmeurs en activité, assez juste pour avoir survécu en grande partie inchangé. La deuxième pièce est la codification : Effective Java a pris l'expertise tacite qui ne vivait auparavant que dans la tête de quelques ingénieurs de plateforme et l'a transformée en règles transférables et discutables.
Le contre-argument mérite d'être énoncé. Bloch n'a pas produit de nouvelle science informatique. Sa thèse a été nominée pour un prix de thèse distinguée, sans l'obtenir ; son travail le plus connu est un livre de bonnes pratiques, qui relève de la curation et du jugement plutôt que de la découverte. Les honneurs enregistrés sont un prix d'édition commerciale et une liste de magazine, pas les prix de recherche majeurs du domaine, et aucune source consultée ici ne rapporte que quelqu'un l'ait qualifié de génie. Le Collections Framework était un effort d'équipe important qu'il a dirigé, pas une composition en solo. Le verdict juste est que Bloch est un praticien et un enseignant suprême du jugement en ingénierie — une discipline qui compte plus que la nouveauté dans le logiciel et qui est beaucoup moins créditée.
Héritage
Il a continué à façonner le langage après avoir quitté Sun, co-proposant des blocs de gestion automatique des ressources et des expressions de création d'instances concises comme approches des fermetures ; les blocs ARM ont été intégrés au JDK 7. En décembre 2004, le Java Developer's Journal l'a nommé parmi les quarante personnes les plus importantes du monde du logiciel. Il est depuis retourné à Carnegie Mellon, où il est professeur de pratique au département des systèmes logiciels et sociétaux — un titre qui se lit comme un résumé de sa carrière, puisque la pratique a toujours été l'essentiel.
La mesure du travail est que son influence n'est pas attribuée. Quelque part aujourd'hui, un programmeur qui n'a jamais lu une ligne de la prose de Bloch cherchera une interface plutôt qu'une classe concrète, ou refusera de créer manuellement une primitive de concurrence, parce qu'un collègue lui a dit un jour de ne pas le faire, après l'avoir lu dans un élément numéroté d'un livre.
