Assistants vocaux et robotisation: mon point de vue

03 juillet 2018

Tags: google home alexa robotisation

Ce billet essaie de résumer une conversation que j’ai eu avec mon frère, concernant les craintes autour des assistants vocaux, et, plus généralement, la robotisation. Je partage une grande partie de son point de vue, mais j’ai aussi de larges différences que je voulais résumer ici. C’est parti !

"Ok Google, crée un malaise"

Le week-end dernier, à l’occasion d’un barbecue en famille à la maison, ma moitié a, au détour d’une conversation, lancé cette phrase par pur réflexe:

"Ok Google, <question anodine>"

Là, mon frère, Guillaume, a fait un malaise. Etendu sur le sol, pris de spasmes incontrôlables, en position foetale, il baffouillait des phrases pour la plupart inintelligibles, mais, par moments, j’arrivais à comprendre des bribes comme "pas eux", "GDPR", ou autres "Saint Qwant venez-vous en aide". Après quelques minutes, l’intervention d’un seau d’eau et rongé par la honte de se montrer ainsi devant junior, Guillaume repris ses esprits, et commença une discussion trop courte parce qu’interrompue par la nécessité autrement plus primaire de faire griller quelques saucisses.

Au final, la question se résume à celle-ci: pourquoi ? De mon côté, je suis assez ouvert sur l’utilisation des assistants, et je dois dire que c’est quelque chose que j’attendais véritablement depuis des années. De lonnngggues années. Guillaume n’avait probablement rien noté jusqu’ici parce que mon assistant prenait la forme d’une enceinte bluetooth classique, alors qu’il s’agit en fait une enceinte Sony intégrant la technologie de Google. J’avais choisi ce modèle principalement parce qu’une des utilisations que je fais de cet assistant, probablement la plus fréquente, est de lui demander de me diffuser de la musique (via Deezer), ou la radio. La domotique, c’est un peu un rêve de gosse pour moi, j’adore tout piloter, par une appli, ou par la voix. Donc parmi les autres utilisations que j’en fais, il y a:

  • contrôler mes lumières, mon thermostat

  • contrôler ma box domotique (et donc les appareils non directement "connectés")

  • demander des informations (météo, à quelle heure est le match de la France, …)

  • enclencher un minuteur pour la cuisine, ajouter des rappels

Le problème, qui choque Guillaume, est que pour avoir accès à toutes ces fonctions, je partage énormément de données avec El Diablo (Google). Oui, mais j’en suis conscient. Et, par ailleurs, mon compte est configuré avec une extrême précaution. Notamment, j’ai complètement désactivé la personnalisation des annonces. Je garde néanmoins certaines fonctionnalités comme le traçage de ma position géographique (qui, par une occasion, m’a permis de démontrer à des amis qu’on était bien allé les voir au mois d’Octobre :)). J’ai plus de mal, en revanche, sur l’historique des recherches. Mais le noeud du problème, c’est qui détient les données, ce qu’ils en font et en particulier avec qui ils les partagent. Pour ma part, la seule raison pour laquelle j’utilise les services de Google est qu’ils me permettent techniquement de faire ce que je veux. Si, demain, j’ai la possibilité d’avoir une box locale qui m’offre les mêmes capacités, y compris lorsqu’invoquée via IFTTT, je signe à quatre mains. En attendant que celà existe, et j’espère sincèrement que celà arrivera au plus vite, je fais des compromis, et il faut être conscient de ce que l’on a a la maison.

Là où je suis moins d’accord, c’est la diabolisation à l’extrême des assistants. Je reviendrais plus tard sur quelques raisons, mais en particulier un argument que j’entends souvent, c’est "oui mais là tu as un micro qui écoute tout le temps chez toi et qui envoie tes données à Google". Ah, nous y voilà. Quel est le problème ?

  1. ça écoute tout le temps ?

  2. ça envoie tes données ?

  3. ça les envoie à Google ?

  4. qui traite des infos ?

Intention malicieuse ou non ?

J’avoue que j’ai du mal à comprendre les réticences ici. Probablement parce que je suis un développeur naif, mais les bugs, les amis, je suis désolé de vous l’apprendre, il y en aura toujours. Donc, oui, il arrivera que votre Google Home, votre Amazon Alexa ou autre, se mette à enregistrer une conversation qu’il n’aurait pas du, et l’envoie sur les serveurs de Google. En règle générale, on le comprend assez vite, parce que la douce voix robotique vous répondra quelque chose du genre "désolé, je ne sais pas comment vous aider". Que s’est-il vraiment passé ? La box a cru entendre un mot clé. Souvent, on se demande parfois pourquoi Google n’offre pas la possibilité de changer ce mot clé ("Ok Google", "hey Google", …). Je pense qu’une des raisons est ce que l’interprétation de ce mot clé est forcément locale. La puissance nécessaire pour reconnaitre parfaitement l’expression, et son contexte de déclenchement avec le bruit, est restreinte. Donc, parfois, pas de bol, ça croit entendre "Ok Google", ou, pire, ça s’enclenche lorsque la pub passe à la télé. En règle générale, ça fait plutôt rire mes enfants, rien de dramatique. D’autant qu’on sait que ça s’enclenche grâce au signal sonore "attention, Google écoute". Donc, un bug, c’est un bug. Ca n’est pas parce que ça peut envoyer des données sans votre accord que l’intention derrière est malicieuse. Dois-je vous rappeler les histoires d’activation à distance des webcams des Mac Book par la NSA ? On n’est pas dans la même catégorie, là. Enfin, des micros qui écoutent tout le temps, vous en avez en poche depuis des années: vos téléphones mobiles. Ils font exactement la même chose, sont activables à distance, et probablement infectés de tonnes de malwares, parfois installées en usine, à des fins d’espionnage gouvernemental. Si je dois me méfier de quelque chose, personnelement, c’est plus de ça que de Google recevant ma discussion sur tata Simone.

Par ailleurs, une fois la conversation envoyée sur le "cloud" (ça fait peur, le cloud, on ne sait pas ce qui s’y passe), elle est analysée. Pensez-vous que ce sont des humains qui analysent votre question et renvoie la réponse en 2s ? Non, la puissance de calcul nécessaire pour interpréter correctement votre question et titanesque. Elle nécessite des techniques avancées (TALN, statistiques, oui, vous savez, la même chose que ce gros mot "big data"), et l’apprentissage pour l’amélioration de la qualité des réponses requiert le stockage de quantités monstrueuses d’information. Je ne suis pas convaincu que Google doive pour autant stocker toutes les conversations, mais je conçois parfaitement qu’en analysant les requêtes de millions d’utilisateurs, avec des voix différentes, des accents différents et des contextes culturels différents, on est capable de faire beaucoup mieux qu’en ne stockant rien et analysant localement. Le temps où il fallait patiemment passer des heures à répéter des tonnes de phrases à son logiciel de reconnaissance vocal n’est pas si loin…

Donc, oui, Google va recevoir ma voix. Oui, il va l’analyser et construire un profil, qu’il pourra partager. Je suis au courant. Et j’ai, dans la mesure du possible, restreint ces possibilités. Je serai d’autant plus heureux le jour où je n’aurai pas besoin de lui confier mes données. Mais l’intégration, la simpliciter d’utilisation, et le seul fait que ça marche, aujourd’hui, est la raison de son adoption. Enfin, on dit que ça marche, mais après des mois d’utilisation, il ne faut pas très longtemps pour comprendre que malgré les quantités énormes de données dont Google dispose, dans de très nombreux cas, l’assistant est complètement à la ramasse. Genre, on lui demande si un match passe sur TF1, il est incapable de répondre. On lui demande "quel temps va-t-il faire", il comprend "température". On apprend même à reformuler nos questions pour que l’assistant les comprenne. Bizarre, et frustrant. Mais, ça montre les limite de la technologie, et casse quelques mythes. En particulier, il faut se méfier des annonces autour de Google Duplex, l’assistant qui prend des rendez-vous à votre place: oui, ça marche, c’est bluffant, mais il est conçu pour cette tâche spécifique, et il est finalement assez simple, d’après les premiers retours, de lui faire perdre le fil.

La relation homme-machine

Néanmoins, la conversation a dévié vers l’intelligence artificielle en règle générale, et la relation qu’on a avec les machines. Sur ce sujet, je suis extrêmement ouvert. Je suis très introverti, et, personnellement, avoir une conversation avec une machine a un côté rassurant. Me demandez pas pourquoi, c’est un fait. Je narrais aussi cette anecdote à mon frère: un de mes enfants a des difficultés à parler aux adultes. Il marmonne, ne les regarde pas dans les yeux, et met beaucoup de temps à leur accorder sa confiance (mais une fois qu’elle est acquise, il n’y a plus de pb). Personnellement, ça ne m’a jamais inquiété, j'étais pareil enfant, et ça n’a (je pense) pas fait de moi un être associal (j’espère). Disposant de Google Home, mon fils s’est naturellement mis à l’utiliser lui aussi. Et ses premières expériences étaient frustrantes: n’articulant pas, la machine n'était pas capable de le comprendre. En quelques semaines seulement, il a progressé plus qu’en plusieurs années: désormais, il articule et parle fort, y compris aux adultes (à de rares exceptions près pour ceux qui l’impressionnent comme le médecin). Ce sujet en a apporté un autre: celui du fait de faire dire aux enfants "merci" ou "s’il te plait" aux machines.

Guillaume est, si j’ai bien compris, contre l’humanisation des machines. Pour ma part, j’y suis favorable, et je suis donc pour la "politesse envers les machines". Fondamentalement, je pense qu’une partie des craintes de Guillaume se fondent sur le fait de confier l’empathie aux machines et que des algorithmes s’en servent pour nous manipuler. L’autre aspect est l’aliénation de l’homme à la machine, c’est à dire apprendre à des enfants à obéir non plus à des hommes mais à des machines. Soit, c’est une crainte légitime. Je suis plus cynique que celà: je doute qu’une machine puisse faire pire qu’un être humain. En fait, j’ai plus d’espoir envers les machines que je n’en ai envers les êtres humains. L’histoire a montré a de trop nombreuses occasions que l’empathie n’est pas l’apparat de tout le monde, bien au contraire. L’utilisation des biais cognitifs à des fins de manipulation (vente, politique, abus de confiance), ça n’a rien de nouveau. Est-ce qu’il faut craindre que les algorithmes fassent de même ? Oui. Serait-ce pire qu’avec des humains ? J’en doute, bien au contraire. L’imagination perverse des hommes n’est plus à démontrer. Leur intolérance non plus.

Suis-je humain ?

J’ai grandi avec Star Trek.

Cette série est probablement celle qui a influencé une grande partie de ma pensée. Déja dans Star Trek TOS, l’ordinateur et la domotique étaient au coeur de la relation homme-machine. La machine était naturellement intégrée, un personnage "vivant" en quelque sorte. Puis, arriva Star Trek The Next Generation, avec des personnages encore plus humanistes, mais un personnage en particulier, Data, change la donne: un Androide dont la seule quête était de devenir humain. Un membre à part entière de l'équipage. Un épisode en particulier traite spécifiquement du sujet du droit des robots: Data devait-il être considéré comme une machine ou un humain ? Un scientifique a-t-il le droit de le démembrer pour l'étudier sur le seul prétexte qu’il s’agit d’une machine ?

J’adore cette série pour celà: son humanisme, sa capacité à rechercher ce qu’il y a de meilleur chez l’homme, et son ouverture en général. Subtilement mais sûrement, les sujets sensibles sur le racisme, le transhumanisme, l’homosexualité y sont traités.

Je fais donc partie de ceux qui préfèrent avoir une "conversation" avec une machine polie, lui répondre "merci", tout en sachant qu’il ne s’agit que d’une machine, plutôt de de causer à un con… raciste, homophobe, ou plus fréquemment un télécommercial essayant toutes les techniques possibles pour me vendre ses panneaux solaires sachant pertinnement que je veux terminer ma conversation avec lui. Je pense que la politesse, le "savoir vivre", procure une certaine satisfaction, une relaxation, qui est un concept totallement orthogonal avec le sujet (l’homme ou la machine). Il n’est pas surprenant pour moi que des autistes s’ouvrent plus facilement avec la présence d’un animal (chien, chat, peu importe), ou que certaines expériences montrent des enfants faisant des progrès en parlant à des robots. L’interaction, la socialisation est importante. Et si le robot est meilleur que l’homme sur ce sujet, on doit s’en réjouir ! L’homme a toujours cherché à créer des choses à son image (ça ne vous rapelle rien ?) et il se trouve que notre cerveau est conçu pour reconnaitre la douleur de l’autre (empathie) et y réagir. Je préfère donc 100 fois, que dis-je, 1000 fois un homme poli envers un robot, qu’un homme traitant une autre personne comme une machine. C’est peut-être naif, mais j’ai espoir qu’en apprenant à des enfants à être polis envers des machines, ils apprendront d’autant plus à l'être envers les autres, et qu’on effacera une partie de ce mal, qui est la disparition à l'échelle de la société de l’empathie. Et mon rêve de gosse, c’est de voir un Data émerger. Montrer qu’avec suffisamment de puissance, une machine puisse prendre son autonomie. On en est encore loin, mais, on réduit déja ce qui est "visible" entre homme et machine. Si je ne suis pas capable de faire la différence entre un homme et une machine dans une conversation, qu’est-ce que celà dit de moi ? Qu’est-ce que celà dit de la machine ? Et si, nous mêmes, n'étions finalement qu’une machine un peu sophistiquée, issue de l'évolution. Une machine douée de pensée et de sentiments, mais une machine quand même.

Comments

Parlons Gradle : Episode 1

30 octobre 2017

Tags: gradle meetup online

Suite à de nombreuses discussions via Twitter, j’ai souhaité organiser des discussions en ligne pour que nous puissions parler de Gradle. Le premier épisode aura lieu mercredi prochain, notez la date !

LE MERCREDI 6 DECEMBRE , à 17h GMT+1 (Paris)

La rencontre se fera via Google Hangouts. Si vous êtes intéressés, envoyez-moi un mail (cedric -at- gradle -point- com) ou un tweet avec votre email pour que je vous envoie une invitation. Pour des raisons pratiques, elle se fera en français uniquement !

De quoi va-t-on parler ?

L’objectif pour moi est de récolter votre ressenti sur Gradle, son utilisation, vos problèmes au quotidien, la documentation, les exemples, mais aussi ce que vous aimez, votre utilisation, … Bref, votre expérience utilisateur. Certains sont encore convaincus que Maven est supérieur, ce qui, de mon point de vue, reste un mystère, et j’ai donc besoin d’entendre votre feedback pour savoir comment corriger (si nous n’avons pas encore entrepris de démarche dans ce sens).

Bref, il s’agira d’une discussion ouverte, d’environ 1h. Bien entendu nous pourrons parler du futur de Gradle si nous avons le temps.

Au plaisir de vous voir !

Comments

Pourquoi je soutiens Benoît Hamon

01 mars 2017

Tags: politique ps hamon

Cette élection présidentielle est unique. A bien des égards. La première raison, qui m’est insupportable, est que pour la première fois, une candidate FN, Marine Le Pen, est en position de gagner cette élection: un mirroir de ce qui se passe à l'échelle mondiale, avec un repli sur soi et une montée inquiétante du populisme. La seconde, parce qu'évidemment jamais le rejet des politiques en place n’aura été aussi important. Pour autant, c’est aussi une opportunité, pour une fois, de changer radicalement de société. Les choix qui s’offrent à nous sont particulièrement clairs: une droite extrêmement dure avec Fillon et Le Pen, ou une gauche sans compromis avec Hamon ou Mélenchon. Sans oublier, bien sûr, l’outsider désormais favori Macron, dont je ne sais toujours pas s’il a des convictions ou s’il est simplement le reflet de la nature, qui a horreur du vide (je ne sais pas où voter, allons là où tout le monde semble se rallier).

Pour ma part, je vote par conviction. J’aurais bientôt 38 ans, et je dois dire que jamais, je n’ai été si proche des idées d’un candidat. Je le suis depuis plusieurs mois, bien avant la primaire, et mes amis proches savent que je leur en parlais et que je croyais en sa victoire. Dans ce billet, je veux vous donner quelques pistes pour lesquelles je soutiens Benoît Hamon, et pourquoi je vous invite à le rejoindre.

Note
A mes lecteurs habituels, ce billet n’a rien à voir avec mes interventions techniques. Libre à vous de l’ignorer. Par ailleurs, je souligne évidemment que ce qui est écrit ici n’engage que moi, et personne d’autre que moi.

Le revenu universel

Commençons par le revenu universel, parce qu’il est le plus clivant. Même pendant la primaire des gauches, j’ai entendu des absurdités incroyables à son sujet, ou des questions très orientées des journalites simplement destinées à décridibiliser cette proposition. Pourtant, c’est une idée neuve, défendue par de nombreux économistes, de droite comme de gauche, ainsi que d'éminents chefs d’entreprise, tels Elon Musk, le fondateur Tesla, Space X, devenu richissime avec la revente de PayPal, … Pas spécialement un exemple de ratage. Rappelons son principe de base: donner, à chaque citoyen, un revenu identique (dont le montant varie selon les propositions), universel, indépendemment de ses resources, à compter de sa majorité. A droite, on crie alors à l’assistanat. A gauche, on hurle qu’il ne faut pas donner aux riches qui ont déja bien assez.

Mais le monde change. Le travail change. Quiconque vous dit le contraire est soit aveuglé, soit vous ment. Je travaille dans l’informatique, et par mon activité professionnelle qui m’amène à rencontrer de nombreux développeurs du monde entier, je pense être assez bien placé pour voir que ce je développe, ce qui arrive, est une nouvelle révolution industrielle (mais pas seulement, les services sont aussi touchés).

En France, vous aurez déja remarqué que les caissières se font moins nombreuses, qu’il n’y a plus personne aux péages, que le métro n’a plus de conducteur, qu’on nous vend du pain frais dans un distributeur… Mais nous sommes très en retard.

Quoi qu’on en pense, à moyen terme, la révolution robotique est en marche, et c’est une bonne chose. Bien sûr, on ne parle pas d’un remplacement à court terme. Tout celà est progressif. Des métiers vont disparaître, d’autres se transformer, d’autres encore vont apparaître, mais il est indéniable que le volume de travail global disponible à l’humain fond comme neige : nous sommes toujours plus nombreux sur la planète, le PIB augmente, pour autant le volume d’heures travaillées évolue peu. L'étude la plus optimiste de l’OCDE indique que près de 10% des emplois sont menacés à court terme. Une autre étude parle elle de 50% des emplois remplaçables par des robots à l’horizon 2030. Lorsqu’on choisit une politique, il ne faut pas penser à court terme, mais à nos enfants. Même s’il est idiot d’affirmer que le travail va disparaitre (qui peut sérieusement le croire ?), il se transforme, et il faut embrasser cette transformation.

J’en suis convaincu, les politiques qui ignorent ces changements vivent dans un monde qui n’existe plus: ils achètent leur pain au chocolat à 10 centimes, font leurs courses chez Prisunic et rêvent de payer leurs assistants parlementaires européens en Francs. Ignorer les changements du travail, c’est ignorer l’avenir, s’aliéner à ceux qui embrassent ce changement, perdre notre souveraineté. Au lieu de combattre ce futur, il faut au contraire s’y préparer et repenser notre société autour de ces changements. L’automatisation, la robotisation, n’engendre pas de perte de valeur: celle-ci est toujours présente, les prix ne baissent en général pas: la productivité augmente et on réduit la pénibilité. Deux choix de société s’engagent alors: profiter de cette amélioration pour vivre mieux, ou une fuite en avant productiviste. A ce sujet, je conseille la lecture de ce billet à mes lecteurs anglophones: ou comment le temps de travail est fonction des évolutions de la société, pas une constante.

Ceci appelle à une révolution fiscale: là où aujourd’hui on taxe le travail, il faudra demain taxer les robots, comme le propose aussi Bill Gates. Si ce terme peut faire sourire, il cache en réalité de nombreuses ramifications: évasion fiscale en particulier. Quelle pire injustice que de voir nos petites entreprises crouler sous des 30% de taxes, lorsque les grandes entreprises étrangères qu’on utilise tous (smartphones, distribution), qui robotisent, automatisent et n’embauchent quasiment pas, placent "leur" argent dans des paradis fiscaux et ne paient pas d’impôts, grâce à des montages financiers complexes avec la complicité de nos cabinets comptables ? Ne marchons nous pas sur la tête ?

Alors, oui, on peut continuer à sourire, dire qu’il faut baisser les charges pour les entreprises et les salariés (ce qui serait une bonne chose), mais si on n’embrasse pas cette virtualisation de l'économie, on ne fait que réduire l’assiète des cotisations, et se ruiner un peu plus.

Alors que vient faire le revenu universel là dedans ? Il permet:

  • de mettre fin à la grande pauvreté, en particulier en remplaçant le RSA, belle idée mais tellement complexe que nombreux sont ceux qui y ont droit et ne le demandent pas. Par ailleurs, si le revenu est effectivement universel, l’argument de la fraude aux aides ne tient plus: tout le monde y a droit, point.

  • de favoriser le temps partiel. Dans certains Etats, comme les Pays-Bas, c’est déja la norme, y compris chez les hommes, réduisant ainsi les inégalités homme-femme. Le PIB de ce pays n’a pas chuté, les employés n’en sont que plus heureux.

  • de maintenir l’emploi. Des histoires d’agriculteurs qui travaillent comme des fous et ne s’en sortent plus, on en lit tous les jours. Avec 350€ par mois, franchement, vous resteriez? Je connais personnellement l’un d’entre eux qui a fini par abandonner. Avec le revenu universel, on permet à ces travailleurs pauvres de rester en poste.

  • de choisir de travailler plutôt que rester à la maison. Je ne sais pas pour vous, mais le nombre de fois où j’ai entendu quelqu’un me dire "avec mes frais de garde et de transport, ça me revient plus cher d’aller travailler que de rester chez moi". Pas franchement encourageant, non?

  • de valoriser des activités non commerciales mais importantes pour la société : travail associatif, aides à la personne, …

  • de partager le travail: à coût égal pour une entreprise, il sera possible de prendre 2 salariés au lieu d’un seul, et ainsi donc réduire les risques de TMS (pour les travaux manuels) ou burn-outs : il existe une limite physique à la productivité.

En revanche, le RU ne rend pas les riches plus riches. C’est un revenu. En conséquence, il est imposable. Il s’ajoute donc à votre salaire et suivant vos revenus, vous devrez payer ou non des impôts dessus. Il est donc incorrect de dire que ça coute 400 milliards (ou plus). En pratique, il coûte sensiblement moins, en particulier si son implémentation se fait via un crédit d’impôt. La justice fiscale est maintenue. Le soumettre à conditions de ressources, c’est augmenter son coût intrinsèque (gestion, contrôles) ou inciter à la fraude pour quelque chose qui ne change au final rien. Quant à l’argument de l’incitation à l’oisiveté, il me fait doucement sourire. A tous ceux qui me l’ont avancé, je leur ai posé une question simple: si on vous donnait 600€ par mois, est-ce que vous quitteriez votre boulot ? Est-ce que ça vous suffirait ? Je pense que je n’ai pas besoin de vous donner les réponses…

Alors, certains taxent cette proposition d’irréaliste, utopique, irréalisable et j’en passe. Ils doutent de sa crédibilité. Mais que proposent-ils ? Toujours les mêmes solutions ! Réduire les charges des entreprises (merci Fillon pour son exonération sur les bas salaires, effet d’aubaine pour n’augmenter personne, alors que la répartition de la valeur n’a jamais été aussi dévaforable aux pauvres et classes moyennes). Augmenter la TVA (belle justice fiscale !). Qui se souvient, à l’inverse, de la baisse de la TVA pour la restauration, en l'échange, soit disant, d’emplois et de baisses de prix ? Qui se souvient encore du badge 1 million d’emplois de Pierre Gattaz en l'échange du pacte de compétitivité ? Travailler plus, en défiscalisant les heures supplémentaires, encore une mesure populaire, mais qui ne crée pas d’emplois (la vraie injustice), et n’est qu’un pansement sur une jambe de bois: est-ce que cette politique a déja une seule fois marché ?

Autre question: qui peut encore croire que repousser l'âge de la retraite est une solution, alors même que les seniors sont "trop vieux pour travailler" dès 50 ans ? Je ne suis fondamentalement pas contre repousser l'âge de la retraite (qui finalemement va de pair avec l’augmentation de l’espérance de vie), mais faire ça alors même que nos seniors sont au chômage n’a aucun sens. Il faut d’abord revaloriser l’expérience, changer notre vision. Comment peut-on imaginer créer des emplois en faisant travailler plus ceux qui ont la chance d’en avoir un, quitte à les briser ?

60 milliards ont été engloutis dans le CICE, pour quel résultat ? Autre solution classique, se reposer sur une croissance, dont les prévisions sont systématiquement revues à la baisse, et donc les conséquences sur notre planète commencent sérieusement à se faire sentir ? Ou faciliter le licenciement, en croyant dogmatiquement que ça facilite l’embauche ? Ce dont ont besoin les entreprises, ce n’est pas de pouvoir licencier. Personne ne veut licencier par plaisir. Ce qu’il faut, c’est de la stabilité. Connaitre les règles du jeu à l’avance, et qu’elles ne changent pas tous les jours, ainsi qu’une juste concurrence : que les petites paient les mêmes impôts que les grosses, et que les différences de législation entre partenaires commerciaux ne soient pas un frein aux entreprises locales (donc, un protectionnisme raisonné). Alors, dites-moi, qui est irréaliste et utopique ?

Alors, on va nous parler de "valeur travail". Ou la réalisation par le travail. Est-ce là une valeur que je veux transmettre à mes enfants ? Non. Si le travail est important, il ne doit pas être le critère de réalisation, en particulier dans une société ou le travail se raréfie. C’en est de plus insultant pour tous ceux qui ne trouvent pas d’emploi, ou pour ceux qui s’investissent autrement (associations, sportifs, artistes) et contribuent à la grandeur de notre pays. Ce que j’enseigne à mes enfants, c’est qu’il faut se donner à fond et ne pas se fermer de portes. Je leur apprends la tolérance. Je leur apprends à apprécier la chance qu’ils ont par rapport à d’autres. Je leur apprends que l’effort est récompensé, mais que parfois, la vie est injuste. Travailler, oui, mais choisir. Le choix, la liberté sont la clé de la réalisation.

Et d’avenir, parlons-en.

La révolution écologique

Lorsqu’on parle de révolution industrielle, on ne peut ignorer la transition écologique à mener, et son potentiel énorme en termes d’emplois. La France a trop longtemps dirigé tous ses crédits vers le nucléaire, en en ignorant volontairement le coût réel (démantèlement, notamment) et son impact sur l’environnement (bien sûr, un accident n’arrive jamais). Mais le plus gros mensonge, c’est encore notre fameuse indépendence énergétique. Faut-il rappeler d’où vient le combustible si précieux dont nous avons besoin ? Pour autant, il ne faut pas être naif: sortir du nucléaire prend du temps, mais c’est aussi une énorme opportunité. En échelonnant dans le temps, comme le propose Benoît Hamon, on permet de maintenir notre capacité de production, tout en ouvrant de nouvelles voies de développement, créant des emplois. La catastrophe serait de faire comme en Allemagne, où toutes les centrales ont été remplacées par des centrales à charbon, dont le bilan carbone est redoutable… Cette carte interactive est plus que parlante…

Mais l'écologie ne se limite pas au nucléaire. L’opposition ferme de Benoît Hamon aux perturbateurs endocriniens est un autre exemple de ce que j’aime dans sa vision: il est temps d’en finir avec la dictature de la croissance, qui détruit notre environnement et provoque de graves maladies. Penser que je puisse être responsable du futur cancer de mes enfants m’est juste impossible: si je peux faire quelque chose aujourd’hui, quitte à sacrifier un peu de confort (je suis le premier à changer de smartphone tous les 3/4 ans, mais en ai-je vraiment besoin ?), faisons-le. Il existe des solutions: circuits courts, production raisonnée, retour à une agriculture prenant en compte les spécificités régionales, réduction de notre consommation de viande, … Nous devons aussi nous responsabiliser en tant que consommateurs: acheter toujours moins cher, c’est inciter à la baisse des salaires ou à la délocalisation.

La République

Un des derniers points que je souhaite discuter ici est ma vision de la République. Tout d’abord, je souhaite le retour au septennat. Je pense que le passage au quinquénat a été une catastrophe, contribuant à la peopolisation de la politique: on ne cherche plus à faire un projet, on parle tout de suite de la prochaine élection. Même si je n’ai pas d’idée précise de ce que doit être la prochaine République, il me semble clair que celle-ci est à bout de souffle. Conçue pour le Général de Gaulle, l’homme providentiel. Je pense qu’il faut revoir le rôle de Président, et qu’il ne soit plus qu’un garant de nos institutions. Pour celà, il nous faut une assemblée consistuante. Benoît Hamon n’en parle pas spécialemement, et c’est peut-être un des points où je suis plus en accord avec un Mélenchon que lui: il faut bien des points de désaccord. En particulier, je trouve l’idée du 49-3 citoyen avec seulement 1% du corps électoral potentiellement dangereuse : la Manif pour Tous aurait pu bloquer le mariage homosexuel (oui, je suis de ceux qui pensent que donner des droits égaux à tous les citoyens n’est pas supprimer vos propres droits), ou, du temps de Mitterand, je doute que la peine de mort aurait pu être abolie. En clair, je suis plutôt pour une proportionnelle intégrale, répondant à une crise de représentativité qu’entretient élégamment le FN. Mais je suis aussi surtout pour la stochocratie, où le fait de tirer au sort des représentants qui, eux, éliront ceux qui nous gouvernent.

Laïcité et peur de l’autre

Une de mes plus grandes désillusions de l'ère Hollande. C’est là que le Parti Socialiste m’a perdu. J’ai été affligé par la Loi Renseignement. Non seulement elle est liberticide, mais elle est aussi dangereuse pour nos entreprises, réduisant considérablement les sécurités et garanties qu’elles peuvent mettre en place pour leurs clients. Mais le plus grave, le divorce, ce fut la déchéance de nationalité. Sous prétexte de protéger nos concitoyens, nous créons deux catégories de personnes, ce qui est le contraire même des fondements de notre République. Plus encore, une trahison des valeurs de gauche. Aux élections qui ont suivi, pour la première fois de ma vie, je n’ai pas voté PS. Fort heureusement, cette mesure n’est jamais passé, j’aurais eu honte, franchement.

En ce qui concerne le débat sur la laïcité, là encore, je suis à 100% derrière la position de Benoît Hamon: la loi 1901 et rien que la loi 1901. En clair, il s’agit de respecter la liberté de culte. Et respecter toutes les religions. Point. Il faut être sacrément culotté (ou aigri), pour dire "Benoît Hamon est en résonance avec une frange islamo-gauchiste". Malek Boutih, je vous le dis sincèrement, cest propos sont une honte pour la gauche. Les simples sous-entendus de cette phrase me dégoutent. Pire, vous avez donné des arguments à l’extrème droite, que nous combattons de tout notre coeur. C’est indigne et tellement typique de cette gauche archaïque (un paradoxe quand vous vous qualifiez de progressiste) et loin de ses valeurs. Après de telles sorties, ne soyez plus surpris que les gens votent FN et vous bottent les fesses aux élections.

Non, je crois aux valeurs humaines. Le FN tente de nous faire croire que 2000 migrants sont responsables du chômage en France, par pitié, non. Pire encore, les migrants violent nos femmes et mangent nos enfants. Et ils n’avaient qu'à rester chez eux, ou apprendre à nager. Nom d’un chien, où est passé le coeur de la France ? Doit-on laisser mourrir tous ces gens, les suspecter des pires crimes, ou être à la hauteur de notre histoire, nous, le pays des Droits de l’Homme ? Se dire que l’allemagne accueille des millions de migrants dans le même temps où l’on fait des procès à Cédric Hérrou. Dois-je vous rappeler ce que la stigmatisation nous a apporté voici 80 ans ? Ce monde tourne sur la tête…

Les cas Macron / Mélenchon

Pour terminer, parlons rapidement d’Emmanuel Macron et Jean-Luc Mélenchon. A la lecture de ce billet, certains peuvent se dire que je pourrais choisir Mélenchon. C’est vrai, lui et Hamon partagent beaucoup d’idées, tout comme les Verts et à ce titre je suis dépité qu’un accord entre les 3 n’ait pas eu lieu. C'était, à mon humble avis, une opportunité unique pour la gauche compte-tenu de la conjecture actuelle. Je pense, pour ma part, que Benoît Hamon a véritablement compris la transition économique qui nous attend et a une personnalité moins clivante. Les solutions de repli sur soi ne fonctionneront pas. Pas plus que les solutions de Macron, qui reste une énigme. Ses discours sont d’une platitude déconcertante, ses solutions en matière d'économie sont peu ou prou les mêmes que celles de Fillon (libéralisation à outrance du marché du travail), et pourtant… il monte, il monte… Le ralliement de François Bayrou, celui là même qui disait, il y a quelques semaines, que Macron était piloté par les banquiers (ce qui est toujours possible puisqu’il refuse d’indiquer qui le finance)… Je peux me tromper, mais je ne crois pas non plus à la fin du clivage droite-gauche. Nos idées sont différentes. Nos visions de la société sont différentes. Progresser, c’est choisir une vision, et y aller. Faire cohabiter des idées si différentes au sein d’un même gouvernement ne peut conduire qu'à prendre de "petites" décisions ne frustrant personne. Soyez rassurés, cependant, je ne mets pas Emmanuel Macron au même niveau que François Fillon ou Marine Le Pen…

En conclusion, je ne suis pas crédule non plus, tout ceci n’est pas réalisable en un jour et c’est pour celà je j’aime l’approche de Benoît Hamon: jamais il ne s’est présenté comme le candidat providentiel, qui a la réponse à tout. Il faut laisser le temps à une politique de se mettre en place (d’où le septennat). Hamon est un homme qui a une vision, il a travaillé ses dossiers, mais c’est aussi un team player. Toutes ses mesures sont réfléchies, travaillées, et vont dans le sens d’un projet à long terme: un avenir désirable.

La société que l’on souhaite pour nos enfants. C’est à eux que je pense en le choisissant. Ce dont ils ont besoin, c’est d’espoir. Je ne veux pas qu’ils grandissent dans ce monde qu’on nous promet:

Et vous ?

Comments

Gradle and Kotlin, a personal perspective

22 mai 2016

Tags: jvm groovy gradle kotlin

Gradle embraces Kotlin, what about Groovy?

First of all, it’s been a long time since I last blogged, and I’d like to remind that everything written here are opinions of my own and not the views of my employer, which happens to be Gradle Inc as write those lines.

A few days ago, Gradle and Jetbrains announced a partnership to make Kotlin a first class language for Gradle builds, both for build scripts and plugins. Most likely, you know Gradle has been using Groovy since its inception. Lots of people think that Gradle is written in Groovy, which is actually wrong. Most of Gradle is written in Java. The builds scripts are written in Groovy, lots of plugins are written in Groovy, our test cases are written in Groovy (using the best testing framework out there, Spock), but Gradle itself is written in Java.

From my perspective, this is situation has been very disturbing and continues to be so. I have very good friends in the Groovy community, and this move has been seen by some of them as a betrayal. As an Apache Groovy committer, and someone who spent almost 4 years full time implementing new features of the language, most importantly its static compiler, seeing Kotlin promoted as the language of choice for Gradle’s future, it’s a little strange. One could legitimely say, WTF? I’ve been aware of this work for several months now, and my colleagues Rodrigo B. de Oliveira and Chris Beams have done an amazing job in a very short period of time. From a long time Groovy user and Groovy developer point of view, it’s hard not to make this move an emotional thing. However, business is not about emotions. In particular, what are we trying to acheive with Gradle? We’re trying to help developers build their applications. We’re trying to make this elegant, reproducible, scalable and fast. We’re language agnostic. We can build Java, Groovy, Scala, Kotlin, C++, Python, … Gradle has never been the tool to build Groovy applications: it’s been a tool to build software. It’s a tool about automation. And I’ve been complaining enough about communities that build their own tool for their very specific language to understand that this is super important: Gradle is (or aims at) the best tool for building any kind of software. In short, we must think in terms of what is best for our users, and sometimes, this means changing technogies. A product should not be bound to a technology, but a company should even less be bound to it. And given the response that we had after the announcement, supporting Kotlin seem to drive a lot of excitement around Gradle, and that’s a very good thing. So, let’s take that out, and think what it means for Groovy.

Groovy support is not abandoned

First of all, I already said it several times, but better continue to spread the message: support for Groovy in Gradle is not deprecated nor removed. You can still write your scripts in Groovy, you can write your plugins in Groovy, and you will still be able to do it. But Gradle will likely encourage users to migrate to Kotlin. To be clear, Kotlin support is incubating, and there’s a lot to do to make it as usable as the Groovy version. Second, there are tens of thousands of builds written using Groovy, hundreds of plugins written in Groovy, so it’s not tomorrow that Kotlin is going to replace Groovy. However, we care about the future, so we need to think about what it means in the long term. Should we be excited about supporting Kotlin? Yes we should, because Kotlin is an amazing language. Should we continue to be excited about Groovy? Of course we should, because it’s also an amazing language. But it’s old and as such brings a lot of legacy with it. As someone who implemented the static compiler for Groovy, I know it very well. There are things that are hard to change, because a large part of the Groovy community is very fond of its dynamic behavior.

So let’s focus on the two major aspects that led to embracing Kotlin in Gradle. The fist one, and principal, is IDE support. Let’s face it: even before I joined Gradle, when I was giving talks about it, people were complaining about IDE support. Compared to a tool like Maven, supporting Gradle build scripts is complicated. Supporting XML is easy (to some extent). Supporting a dynamic DSL is not. Some say it’s Groovy’s fault, and I want to correct this statement right now: it’s not Groovy’s fault. While Groovy let’s you design dynamic DSLs, the design of the DSL can be changed to make it easier for tools to "discover" things. But when Gradle was designed, there wasn’t any statically compiled Groovy. The idiomatic way to write DSLs in Groovy, at that time, was to heavily rely on runtime metaprogramming. While loving metaprogramming, I’ve always prefered compile time metaprogramming over runtime metaprogramming. For multiple reasons:

  • because in most cases, what you want to do at runtime can be done in a unique, setup phase. For example, create your metaclasses, enrich existing types, configure property missing, method missing, … If it’s setup, it’s better done at compile time, because you can report errors, and because it gives higher performance. This led the way I designed the static compiler, and more features of Groovy after that (traits, type checking extensions, …) : describe what you want to do at compile time.

  • because it makes the life of tools easier. While IntelliJ or Eclipse support DSL descriptors that help them provide completion, those are hard to implement, and often inaccurate. They can only approximate what is going to happen at runtime. And in the end, you’re doing the same job twice: you’re writing a runtime for your DSL, which is dynamic, then you need to write a DSL descriptor for the IDE to understand it. Wouldn’t it be better if all was done in a unique place? Something that both the compiler and the IDE can understand?

So while we know we can describe dynamic Groovy DSLs so that they are understood by IDEs, it’s effectively a lot of work. And if you want to support multiple IDEs, it’s even more work. But in the case of Gradle, it’s even worse: each plugin can provide it’s own "micro DSL". While there’s an "idiomatic" way to configure Gradle builds, it’s no single rule. One can implement it’s own Groovy DSL within the Gradle build. And no luck the IDE would ever understand it. Another pain point is that Gradle adds complexity to complexity in terms of DSL capabilities. For example, when you have a build script that has:

dependencies {
   compile libraries.groovy
}

greeter {
   message = 'hello'
}

sign {
   signature = top
}

often people do not realize that: - dependencies is found on a Project instance - libraries is a user declared variable, that can be found in a plugin, another build script, a project properties file, … (how does the IDE find about it?) - greeter is a convention object, defined by a plugin, to configure the default values of its task - sign is a task, which has a signature property, and top references an extension property from the project

So while this build script is simple to read, it’s hard to understand how it effectively works, because objects can be found at different places, can be provided by different providers (plugins, properties, extensions), but everything is accessed using a single notation. This is bad, because it makes it almost impossible for an IDE to understand what is going on.

The question is, is it Groovy’s fault? My answer is not totally. The fault is mostly on the DSL design, and Groovy made it too easy to do so. But again, that was designed at a time when dynamic Groovy was the rule. I gave a talk, recently, about building modern DSLs with Groovy, where I discourage such practices, and encourage the use of static DSLs instead.

That leads me to the second main reason of embracing Kotlin in Gradle: performance. When we talk about performance, lots of folks tend to think that Groovy is slow. This is not the case. Groovy is pretty fast. However, depending on the design of the DSL, you can easily fall into traps that can lead to catastrophic performance. Before I go further with it, I’m reading way to often that Gradle is slow because it’s written in Groovy and that Groovy is dynamic so it’s slow. F* no, those who tell you that just didn’t profile a build. As I said, Gradle is mostly written in Java. And I’ve spent the last 3 months optimizing the performance of Gradle, and I can tell you that of the dramatic performance improvements that one can see in Gradle 2.13 and 2.14, almost none was obtained by rewriting Groovy to Java, or rewriting Groovy code. None! Most of the hotspots were pure Java code. Period. However, as soon as you use plugins, which are today mostly written in dynamic Groovy, or that your build scripts imply a lot of nested closures, things start to become complicated for "Groovy". Let me explain that clearly. I think at some point, someone made a terrible design decision in Groovy. I don’t know who it was, but the idea was to rely on exceptions to control the flow of resolution of properties. This means that when a property is missing, typically in a closure, an exception is thrown. When a method is not found, an exception is thrown. When a property is not found, an exception is thrown. That seemed to be a good idea, because in the end, you want to provide the user with an error, but in practice, this is catastrophic, because Groovy can capture those exceptions. Typically, in a delegation chain (nested closures), a containing closure or class can actually have this property defined, or implement property missing/method missing. Now, re-think a second about the "simple" example of Gradle build above: how do you now where to look up for message, top, signature, …? Now you know: f* exceptions are thrown, stack traces are filled, and eventually captured because some composite dynamic object finally wants to answer the message… In practice, for some builds I have profiled, it was tens of thousands of exceptions being thrown and stack traces filled for nothing. And that has a terrible impact on performance. So even if we have implemented strategies in Gradle to try to avoid throwing those exceptions (which are responsible for part of the performance improvements in 2.14), this is very hard to do it, and we’re still throwing way too many of them. A static language doesn’t have this problem, because every single reference in source is resolved at compile time. So, if you’re writing a plugin in Groovy, for the sake of performance, please add @CompileStatic.

So there goes Kotlin. Kotlin has excellent static builders support, that make it practical both for IDE support, which will dramatically improve user experience in terms of understanding what do write, what is an error, having documentation, refactorings, … and is a very pleasant language to work with. Honestly, I don’t have anything bad to say about the language (apart from the fun keyword that I don’t like). To some degree, it’s not very surprising: Kotlin has heavily inspired by Groovy and another popular JVM language: Scala. And again, being the one behind the static compiler of Groovy, I can’t blame them for doing what I like about static languages. Their builder support is awesome, and very elegant. And it’s supported out of the box by IntelliJ of course, but also Eclipse.

A static DSL for Groovy?

Ok, so one might think at this point that I’m mad. I wrote a "competing" language, and I’m happy to see Kotlin being promoted in Gradle. I wrote the static compiler, that is capable of doing everything Kotlin can do (minus reified generics, plus superior scripting support, type checking extensions, …), so wtf? Ok, so let’s be very clear: I have absolutely no doubt that Groovy can do everything that we’ve done with the Kotlin support in Gradle. It can be statically compiled, provide an elegant DSL that is statically compiled, and it can be understood by the IDE. I had no doubt before the Kotlin work started, I have even less doubts now. And I can say I have no doubts because I tried it: I implemented experimental support for statically compiled Gradle scripts, written in Groovy. Here’s an example:

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'groovy'
apply plugin: GreetingPlugin

repositories {
    mavenCentral()
}

dependencies {
    compile 'commons-lang:commons-lang:2.5'
    compile "commons-httpclient:commons-httpclient:3.0"
    compile "commons-codec:commons-codec:1.2"
    compile "org.slf4j:jcl-over-slf4j:1.7.10"
    compile "org.codehaus.groovy:groovy:2.4.4"
    testCompile 'junit:junit:4.12'
    runtime 'com.googlecode:reflectasm:1.01'
}

tasks.configure('test', Test) {
    jvmArgs '-XX:MaxPermSize=512m', '-XX:+HeapDumpOnOutOfMemoryError'
}

dependencies {
    compile 'org.codehaus:groovy:groovy-all:2.4.4'
}

extension(GreetingPluginExtension) {
    message = 'Hi'
    greeter = findProperty('greeter')?:'static Gradle!'
}

tasks.create('dependencyReport', DependencyReportTask) {
    outputs.upToDateWhen { false }
    outputFile = new File( project.buildDir, "dependencies.txt")
}

class GreetingPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.extensions.create("greeting", GreetingPluginExtension)
        project.task('hello') << {
            println "${project.extension(GreetingPluginExtension).message} from ${project.extension(GreetingPluginExtension).greeter}"
        }
    }
}

class GreetingPluginExtension {
    String message
    String greeter
}

This is an example Gradle build that is compiled statically. It has none of the problems I described about the Groovy implementation in Gradle above. It uses all the techniques that static Groovy provides: extension methods, powerful scripting with implicit imports, type checking extensions, … All this works. And interestingly, the work that is done to enable support for Kotlin also benefits to statically compiled Groovy, and Java! Let’s not forget about the latter, which is years behind in terms of "modern" languages support. So if this works, why do we need Kotlin? To be honest, I asked it to myself many times. It was very difficult to me, because I knew Groovy could do it. Again, I had no doubt about the language capabilities, no doubt about the performance impact of doing this. However, I missed two critical points:

  1. IDE support. Even if support of Groovy in IntelliJ is by far the most advanced of all other IDEs, it still lacks behind when static compilation is on. But more importantly, it doesn’t know that my script is statically compiled, nor does it now about my custom extension methods. I tried to implement a GDSL descriptor to make it aware of them, and it somehow worked: I do have code completion, but errors are not marked as errors, and the IDE still doesn’t understand that it should only suggest to me what is relevant in the context. With Kotlin scripts which are natively static, there’s no such issue. The IDE understands everything natively, in IntelliJ and Eclipse. So, I have no doubt that Jetbrains can implement support for this, just like I had no doubt I could implement a static Groovy DSL, but who is going to write this? Me? Gradle? I don’t have the time to do it. And it’s not Gradle’s job to write IDE plugins. And what about Eclipse? One big issue that the Groovy community has, today, is that nobody is supporting Eclipse since Pivotal dropped sponsorship of Groovy. After more than one year, nobody took over the development of Groovy Eclipse. Nobody. While Groovy itself saw lots of new contributors, while we saw a lot of bugfixes, new contributors and that the download numbers where never as high as they are today, IDE support is critical. And nobody took over the development of it. I saw some people referring to what Jetbrains is doing as "blackmailing". Seriously? Jetbrains? Think of what they’ve done for Groovy. Groovy would never has been as popular as it is without them. They provided us with the best Groovy IDE possible. They are constantly supporting new features of the language, adding support for AST transformations, traits, … They even added the ability, in IDEA 14, to use Groovy (and not Kotlin, guys!) as the language to evaluate expressions in the debugger. And they would try to kill Groovy? Kill part of their business? Come on guys! So yes, they invested a lot in Kotlin and want to promote it, but how could it be otherwise? And it’s not like if the language sucked: it’s awesome!

  2. Does it make sense? Now that we made the decision to support Kotlin, that we proved it would provide the level of user friendliness we want and that it is statically compiled by default, does it make sense to put resources to support static Groovy in addition? I don’t have an answer to this. I thought yes, but now I’m not sure. Kotlin does the job. And honestly, they have great engineers working on the language. Even if it lacks behind in terms of scripting and compilation times compared to Groovy, I have no doubt they will fix it. How arrogant would we be if we thought other languages could not do what we’ve done with Groovy?

The future of Groovy

The last point I want to address is what it means for the future of Groovy, and what it means for my future in Groovy. First of all, I always thought that the future of Groovy was in the hands of its community. It’s not Gradle that has Groovy’s future in its hands. It’s you. The move to the Apache Software Foundation was also done for this very same reason: community first. If you want to continue to use Groovy, to improve it, to support it, all you have to do is f* do it! And I will continue! I love this language, I know too well how far it can go in terms of DSL support, AST transformations, now in 2.5 we have macros, that’s just a crazily powerful language that’s super fun to use. Should we fear competition? No, we shouldn’t. Competition is good. It should be inspiring. And if Gradle moving to Kotlin means the death of Groovy, maybe the problem is elsewhere. And even if lots of people get introduced to Groovy through Gradle, it’s not the only entry point. Grails is another. Jenkins (through Flow) is another. And many, many more. There was a tweet a few days ago which showed the 100 most popular dependencies in GitHub projects. Groovy was one of them. No Kotlin. No Scala. Groovy. It’s everywhere, and it’s going to be there for a long time.

Part of the fears of the community is, after the Pivotal demise, if Groovy is a dying language. It’s not. It has never been so widely used. The move to Apache Software Foundation drove a lot of attention and brought us many more contributors. But the community has to realize what the problems with Groovy are, and it has to face them: the introduction of the static compiler was too late. IDE support is important. Java 9 support is going to be super important. If you love your language, contribute. Help it. Help yourselves. The future of Groovy must be in your hands. I can’t recall how many times I told this, since I joined VMware, a few years ago, to develop Groovy. In every talk I give, I’m always telling how important it is that you contribute. Jetbrains is not going to write Groovy Eclipse for you.

And I would like to finish with one word: if people move from Groovy to Kotlin, is it really a problem? Isn’t any technology inspired by another? Aren’t we, developers, always rebuilding the same things, but improving them, learning lessons from the past? Is Kotlin a better Groovy? I don’t have the answer yet. Maybe it is. Maybe not. Today Groovy remains greatly superior in terms of scripting, DSL support, but it comes with a price that Gradle doesn’t want to pay. And let’s not forget the original community of Groovy: a dynamic language for the JVM. There are still lots of people who like this aspect of the language (and I do too, typically when I write Groovy scripts in place of bash scripts, I don’t care about types). It’s compile time metaprogramming features also make it incredibly powerful. Modern Groovy definitely doesn’t deserve its "bad press". Would you compare Java 8 with Java 1? No. So don’t compare Groovy 2.4 with Groovy 1 either. Reputation should change, and you can help there too.

This leads me to what I should do. And there, I’m a bit lost, to be honest. I work for a company that embraced Groovy, that is now embracing Kotlin. I love my job, I love working with Gradle, I love Groovy, and I quite enjoy Kotlin. I’m a passionate developer. I just want to continue having fun. But if you think that as such, I’m not a good representative of the Groovy community anymore, maybe I should step off from the Groovy project. I would hate that, but I’ve kind of been hurt by the bad comments we (Gradle) received from some members of the Groovy community. I don’t want to fall into a language war, I don’t care about this. I care about users. What I love to do is helping people, period.

I would like to finish this post with a thought about what I’m going to do, as a Gradle developer, for you, Groovy users. In particular, I am convinced that the success of Gradle is largely due to its Groovy DSL, despite its problems. The fact that it’s simple, easy to read, is super important. I joined the Groovy project because I was using Groovy as a DSL platform in a natural language processing context. Groovy is super powerful for this. And I learnt a lot in terms of DSL design. In particular, I will try to make sure that it doesn’t become a Kotlin API. What I mean by that is that I think we should elevate from a Groovy DSL to a Gradle language. And this language is meant at describing builds. And our users are not Kotlin developers. Most of them are not Groovy developers either. They are, as I described earlier, from different horizons. And I would hate if a user would have to understand concepts like generics or type inference to write a build script. That would be horribly wrong. A build author should understand how to model an application, not what is a type, what is an extension method, or generic return type inference. It’s different for plugin authors, but for a build author, it’s super important. So I will try to make sure that Kotlin scripting support improves, even if it means that it would go even closer to what Groovy supports. I would do this not because I want Groovy to die, I don’t (and it wouldn’t help my royalties for Groovy in Action 2 ;)), but it would help users or Gradle. That’s what I care most about, just like I care about what Groovy users want when I work on the Groovy project.

As for talking about Gradle, Groovy and its future, I’ll be a GR8Conf next week, I’d be happy to answer you in person there too!

Keep on Groovying!

Comments


Older posts are available in the archive.