Cafés LoOPS

Le prochain café LoOPS parlera de notebooks C++ avec xeus et cling. Mais sur la page de LoOPS, ce n’est pas très clair qui va présenter. On peut juste soupçonner que sera Loïc Gouarin, qui travaille pas mal sur ce genre de sujets.

Le café LoOPS précédent parlait de l’outil d’intégration continue TeamCity de JetBrains. Pour l’instant, ce dernier n’est pas open-source, il offre juste des versions closed-source gratuites et payantes. A ce niveau, la politique de JetBrains n’est pas forcément très claire: certains de leurs projets sont open-source (les « community editions » de IDEA et PyCharm et le plugin Rust), mais la plupart ne le sont pas…

Le café LoOPS du 6 mars sera probablement organisé en collaboration avec le LLR, sur le thème « coder pour le jeu ». On y invitera des développeurs du LLR qui travaillent sur des jeux scientifiques.

Certains se demandaient si on ne devrait pas y inviter nos anciens collaborateurs de l’école Cnam-ENJMIN (Angoulême), avec qui on avait précédemment travaillé sur « Quark Clash », un jeu vidéo qui aurait dû être la version numérique du jeu de cartes « Quark Poker », mais qui a finalement été quelque chose d’assez différent. Un des regrets de cette expérience est en effet qu’on n’ait jamais réussi à en faire un séminaire technique.

Les méthodes de travail des développeurs du jeu étaient intéressantes, car différentes de ce qu’on observe habituellement dans les labos, avec notamment diverses spécialisations inhabituelles (graphisme, son…). Les locaux de l’école eux-même, une ancienne usine papier à cigarette, ont une esthétique assez unique: murs à base de palettes, rails d’éclairage d’usine au plafond…

Les EDIs / IDEs

Il y a eu une longue discussion sur les environnements de développements intégrés (EDIs, plus connus sous l’abbréviation anglaise IDEs), avec des points de vue allant de la révolutions de productivité à l’usine à gaz insupportable.

Un point qui a été mentionné est que les IDEs sont particulièrement utiles quand on ne connaît pas très bien le langage de programmation qu’on utilise ou le projet logiciel sur lequel on travaille, l’avantage sur d’autres environnements étant moins prononcé quand on est déjà un expert des deux.

Un autre point qui a été soulevé par les participants de l’école de fonctionnel et de Spark, c’est que dans des langages utilisant l’inférence de type comme Scala, un bon IDE aide beaucoup à comprendre ce qui se passe dans du code touffu. Et quand dans des codes complexe, il aide à naviguer rapidement d’un module à l’autre, ou à comprendre l’architecture et trouver la documentation.

Antoine mentionne aussi que l’intégration des outils d’analyse statique et des linters dans les IDEs est particulièrement plaisante, puisque ces derniers sont capable de signaler les erreurs détectées directement dans le code, sans indirection. En Python, l’intégration des lints PEP8 est particulièrement plaisante. Une autre fonction classique de IDEs est l’application automatique d’un style de code.

Un inconvénient des IDEs est qu’ils sont souvent, au moins pour partie, spécifiques à un langage. Cela complique la vie des programmeurs qui travaillent dans plusieurs langages, et tend à encourager à l’inverse une certaine hyper-spécialisation. A ce niveau, on peut saluer l’effort de Jetbrains pour fournir des IDEs d’interface relativement uniforme pour de nombreux langages. Ils ont réussi à en cela à détrôner Eclipse, qui avait tenté la stratégie de l’IDE qui fait tout, mais qui s’avérait finalement moyen hors de son domaine d’expertise du Java.

Serge en profite pour mentionner que les développements web du labo se font beaucoup avec Eclipse, et qu’il s’interroge sur la pertinence de passer à PHPStorm, l’IDE PHP de Jetbrains. Cet IDE ayant une version gratuite, il a été proposé qu’on fasse des tests avec et achète quelques licence au LAL si l’essai est concluant.

Comme souvent, il faut de tout pour faire un monde: certaines personnes se sentent beaucoup plus confiantes et plus productives avec un IDE, tandis qu’à l’autre extrême certains développeurs du LAL ont du mal avec la coloration syntaxique. Et bien sûr, il ne faut pas oublier que quoi qu’il arrive, l’outil ne remplace pas la compétence.

Formation Fonctionnel/Spark

La réunion développeurs s’est tenue entre les deux parties de la formation de programmation fonctionnelle et Apache Spark, donc après la partie « programmation fonctionnelle en Scala ».

A ce stade, l’impression était que c’était un très bon début, avec toutefois quelques regrets sur l’équilibrage du troisième jour, où Olivier avait passé un peu trop de temps sur la gestion des erreurs, et trop peu sur la concurrence et le parallélisme.

Un autre sujet peut-être trop développé était la question du lien entre Java et Scala. C’est certes un point important pour comprendre certains points malheureux de la conception de Scala, mais dans notre communauté globalement peu portée sur le Java, ça tournait assez rapidement à la discussion d’expert opaque.

On pourrait sans doute faire mieux sur ce point la prochaine fois en faisant circuler un petit questionnaire lors de l’inscription à la formation pour se faire une meilleure idée du public cible.

Un exemple de point où l’héritage Java a influencé Scala, c’est la taille maximale des tableaux (et des collections), qui est fixée à 2 milliards d’éléments (2³¹ – 1 pour être précis). L’origine de ça, c’est que Java stocke les indices et tailles de tableaux dans des entiers signés 32-bit. A l’époque où le langage a été conçu, sur du matériel nettement moins performant qu’aujourd’hui, et avec une audience beaucoup plus faible, ça avait dû paraître suffisant, mais aujourd’hui on est gêné par cette limitation dans des projets comme LSST où on a bien plus que deux milliarde de données à traiter.

Dans le cas de LSST, Christian a contourné le problème en utilisant des tableaux de tableaux, dont l’organisation interne est cachée au programmeur par l’API de Spark qui n’expose que des pipelines et des itérateurs. C’est une solution globalement satisfaisante, mais qui a quelques inconvénients, notamment quand on manipule des éléments voisins dans le tableau global (qui ne sont pas forcément voisins dans le tableau de tableau qui le simule) ou quand on modifie le tableau.

Le modèle de programmation fonctionnel où les données sont immutables nous sauve cependant ici, car il élimine la question de la modification du tableau, et simplifie la gestion du voisinage par mise en cache des voisins.

Un autre aspect qui est remarquablement facile à aborder en Spark, c’est la non-commutativité de certaines opérations sur les données du point de vue de la performance. Pour donner un exemple, il est généralement préférable de filtrer les données avant de les transformer, pour ne pas effectuer des transformations inutiles. C’est un problème connu des utilisateurs de SQL, où l’ordre des conditions dans une clause WHERE a aussi son importance. Or, avec un modèle de programmation à base d’itérateurs comme celui de Spark, il est nettement plus facile de raisonner sur ce type de considération, car l’ordre des opérations effectuées sur les données apparaît assez naturellement dans la chaîne d’itérateurs.

Autres événements

Une visite de l’IgleX avait préalablement été proposée par Antoine, qui trouve que c’est important de voir l’évolution de l’igloo avant l’installation de ThomX. Le groupe contrôle-commande a donné un accord de principe, il n’y a donc maintenant plus qu’à programmer la chose. La mise en service de ThomX est actuellement prévue pour cet été (mais sera potentiellement retardée par des problèmes avec les électro-aimants), et Antoine propose une visite en février.

C’est aussi le moment pour proposer des sujets de stages pour le Google Summer of Code. PSPA n’y participera pas cette année en raison du refactoring en cours, par contre on a une proposition d’astrophysique par Julien et Christian et deux propositions de tracking pour la physique des particules par Hadrien et David.

Les inscriptions sont ouvertes pour CHEP 2018, la grande « conférence-usine » (8 sessions parallèles avec une présentation intéressante par demi-journée dans chacune…) sur l’informatique pour la physique des particules. Elle se tiendra à Sofia, en Bulgarie, entre le 9 et le 13 juillet. Le conflit avec les stages GSoC est regrettable, mais on s’en tirera probablement par des mails rapides entre deux sessions. HSF organise également un workshop appelé PyHEP sur le Python en physique des particules le week-end d’avant. Hadrien devrait y présenter une étude des caractéristiques de stabilité numérique d’ACTS avec l’outil Verrou.

Pour ce qui concerne la formation Symfony 3 préalablement proposée sur Devlog, Serge et Justine sont malheureusement sans nouvelles. Pour rappel, l’idée serait de discuter des nouveautés de cette version du framework PHP, que l’on utilise beaucoup au LAL pour des applications de gestion du personnel.

Une réunion de fonctionnement du SI se tiendra le 25 janvier à 14h30. L’une des questions auxquelles elle devra répondre est la pertinence de poursuivre cette série de réunions. En effet, elles ont déjà eu un impact positif net (comme la création de la salle relax), mais on va peut-être vouloir passer à un autre format pour la suite.