Interview de Johann Elsass

Johann Elsass est un développeur français de 33 ans actuellement établi à Londres.

Après des études en psychologie, il s'est réorienté vers le développement logiciel, retrouvant par là même sa passion de jeunesse. Il a travaillé comme développeur indépendant en Alsace de 2007 à 2012 avant de s'expatrier vers le Royaume-Uni.

Dans le monde de Pascal, il s'est notamment fait remarquer grâce à son logiciel de dessin LazPaint dont il a tiré la bibliothèque BGRABitmap qui permet de dessiner avec antialiasing, contrôler la transparence, fusionner des couches, ajouter des effets… Enfin, il a participé à l'élaboration de composants pour Lazarus avec BGRAControls.

Équipe Pascal  : Tout d'abord, nous serions intéressés de connaître un peu votre parcours personnel.

Quand et comment en êtes-vous venu à l'informatique ?

Johann Elsass : J'ai commencé à utiliser un ordinateur à l'âge de six ans avec un 8086 sans disque dur. C'était une idée de mon père, qui l'avait acheté et m'avait montré comment l'utiliser. Au début, je ne faisais que taper les commandes DOS pour lancer des jeux, changer de disquette, jouer à la chenille ou bien à un casse-brique. À l'époque, l'informatique était quelque chose d'assez solitaire, enfin, c'est mon expérience. C'était avant Internet et les réseaux sociaux en ligne.

Au développement en particulier ?

Plus tard, mon père m'a montré comment utiliser Turbo Pascal avec un programme simple, qui demande une note sur 20 et, avec un « case », donne un avis. Quand j'étais à l'école primaire, j'ai passé plus de temps à m'essayer à la programmation, tenter de comprendre des programmes existants. J'ai découvert le langage assembleur en regardant des programmes Pascal qui contenaient des bouts de code en assembleur intégré (avec l'instruction « asm »). Au début, ce que je faisais était assez modeste et essentiellement en mode texte.

Quelle est votre méthode de travail ?

Ma méthode est de déterminer quelles sont les structures de variables nécessaires. Pas nécessairement déterminer le type exact ou bien le schéma SQL, mais de comprendre quelles sont les informations, d'où elles viennent et où elles vont. Ensuite, je réfléchis à ce que le code propose en terme d'interface graphique ou de surface pour les autres portions de code (ce qui est « public »). Le reste est l'algorithmique et l'implémentation, qui viennent avec l'expérience.

Quels outils utilisez-vous ?

J'utilise peu d'outils, excepté l'environnement de développement. Un éditeur d'images est toujours pratique pour faire des icônes. Sinon, cela est au cas par cas. Parfois, je programme un outil pour l'occasion.

À propos de BGRABitmap…

Qu'est-ce qui vous a poussé à développer cette bibliothèque ?

Je viens du monde de Delphi, où l'on peut accéder directement aux pixels de l'objet TBitmap. Avec Lazarus, ce n'était pas possible. Alors j'ai fait en sorte que cela le soit. D'autre part, j'avais déjà programmé des bibliothèques graphiques quand je programmais sous DOS. J'étais donc déjà familiarisé avec certains algorithmes, comme celui de Bresenham ou bien le remplissage de polygones. J'ai donc rapidement ajouté des fonctions de dessin de base, et après, je me suis dit : pourquoi ne pas ajouter d'autres fonctions ?

Avec qui l'avez-vous développée ?

Essentiellement tout seul ; cela dit, j'ai pris un peu d'inspiration de bibliothèques existantes comme LazRGBGraphics, pour laquelle l'auteur avait déjà trouvé comment afficher une image à partir de son contenu RGB sur différentes plates-formes. D'autre part, j'ai eu de l'aide de la communauté Lazarus pour le développement du logiciel de dessin LazPaint et les composants du paquet BGRAControls, qui se basent sur la bibliothèque.

Quels sont vos projets pour ces produits, à court ou à long terme ?

Ces projets ont des mises à jour de temps en temps. J'en suis satisfait pour le moment. J'attends les retours utilisateurs et j'implémente ce qui me semble le plus essentiel ou bien ce qui me motive. Tout dépend de mon temps disponible et de la quantité de requêtes des utilisateurs.

Comment voyez-vous leur avenir ?

Il y a différents développements possibles de BGRABitmap. Les dernières versions permettent d'utiliser BGRABitmap avec OpenGL, ce qui assure un rendu très rapide, pour peu que l'on utilise des images constantes (stockées en tant que textures). Pour le moment, le rendu 3D est seulement logiciel, alors une amélioration possible serait de connecter les capacités 3D de BGRABitmap avec OpenGL.

Il y a également des améliorations possibles concernant la gestion des fichiers SVG. Les dernières versions permettent d'utiliser les chemins vectoriels. Il serait possible de continuer dans la voie vectorielle.

Concernant les formats de fichier, certains formats ne peuvent pas être écrits pour le moment, notamment le format Paint.NET et le format Photoshop.

Et il y a sans doute d'autres voies possibles.

La communauté autour de ces produits est-elle active ? Nombreuse ?

Il y a un certain nombre d'utilisateurs qui écrivent des messages sur le forum de BGRABitmap de Lazarus, pour demander de l'aide, signaler un problème, etc. Une petite centaine de personnes par semaine téléchargent le code source de la bibliothèque BGRABitmap ou du logiciel de dessin LazPaint, cela peut varier bien entendu en fonction de la publication de nouvelles versions.

Quel est votre public cible ? Qui est l'utilisateur type de BGRABitmap ?

Concernant ma bibliothèque, mes utilisateurs sont les gens qui veulent réaliser des graphismes jolis, tout en écrivant du code qui soit relativement court et assez compréhensible, pour eux-mêmes ou pour les autres.

Aussi, je limite le nombre d'unités qu'il faut mentionner dans la clause « uses ». Cela peut paraître anodin, mais cela facilite grandement l'utilisation, et même, je trouve que cela est presque impossible de retenir les longues listes d'unités. L'inconvénient est que BGRABitmap est un peu plus dodu qu'AggPas, par exemple, mais je pense que cela est raisonnable. On n'est plus à 500 Ko près de nos jours.

Je fais le maximum pour que les fonctions aient des noms explicites, proposent le maximum de potentiel, tout en restant relativement simples. J'attache de l'importance aussi à la concision, préférant rajouter un paramètre ou bien un nom alternatif pour permettre d'être très spécifique, tout en évitant d'avoir trop de propriétés dont on ne sait pas très bien à quoi elles servent.

Qu'est-ce qui constitue votre principale concurrence ?

Libre aux gens de choisir ce qui leur correspond le mieux. Il y a par exemple des concurrents comme AggPas ou bien Graphics32. Je ne les considère pas vraiment comme des concurrents, parce que je pense que leur approche est différente. AggPas ne permet pas vraiment l'accès aux pixels de l'objet Tbitmap ; cela dit, pour certaines choses, AggPas est plus rapide que BGRABitmap. Certaines fonctionnalités, par contre, n'y sont pas disponibles. J'étais tout à fait conscient de l'existence d'AggPas quand j'ai commencé BGRABitmap, et j'ai essayé d'inclure ses fonctionnalités, à ma façon. L'intérêt premier de BGRABitmap est sa facilité d'utilisation et sa connexion avec TBitmap et maintenant avec OpenGL.

Au sujet de Graphics32, cette bibliothèque vient plutôt du monde de Delphi. Elle est intéressante, et selon le cas, il est préférable de l'utiliser. Cela dépend ce que l'on veut faire.

À propos du développement logiciel en général…

Comment, selon vous, le développement a-t-il évolué, depuis ces deux dernières décennies puis plus récemment ?

Et avez-vous personnellement suivi ce mouvement ?

Oui, la programmation objet, le développement en couches et en composants sont devenus incontournables. J'ai effectivement suivi le mouvement. Pour le reste, comme WPF ou bien les environnements pour téléphone portable, j'ai l'impression que le monde du développement est en recherche sans avoir vraiment trouvé.

Comment voyez-vous évoluer tout cela, dans un avenir proche ou plus lointain ?

Il y a des petites évolutions des langages de programmation, par exemple pour inclure toujours plus de design patterns et faciliter l'écriture. Il me semble donc qu'on va vers une syntaxe plus simple.

Il y a aussi bien entendu l'évolution vers les smartphones, qui selon moi, prendra vraiment son envol avec la fin des problèmes de recharge (avec des batteries qui peuvent contenir plus d'énergie ou bien des portables qui se rechargent avec la lumière ambiante). Si cela devient réalité, cela aura une influence supplémentaire sur la structure des programmes en général.

En aparté, j'imagine que les grands écrans deviendront des dispositifs passifs sur lesquels on pourra facilement brancher n'importe quel appareil portable que l'on n'aura que rarement besoin de charger.

Le développement sur téléphone portable est pour le moment encore assez fragmenté. Je n'ai pas assez de connaissances dans ce domaine pour dire ce qui va se passer, mais cela a une influence certaine sur le développement en général.

À propos du langage Pascal…

Où situez-vous le Pascal dans le monde du développement logiciel ?

Pour être honnête, Pascal n'est pas très bien placé d'un point de vue du marché pour différentes raisons. Il reste que Free Pascal et Lazarus sont prometteurs puisqu'ils permettent a priori de compiler pour toutes les plates-formes et éventuellement pour les téléphones. Il y a cependant des concurrents importants comme Corona SDK par exemple.

Pensez-vous qu'investir actuellement dans un langage comme le Pascal ait un sens ?

L'environnement de développement gratuit est a priori un bon investissement presque par définition. Sinon Delphi est toujours là. Alors, tant qu'à choisir un langage qu'on apprécie, pourquoi pas le Pascal.

Pour le Pascal.NET, je suis plus mitigé. Il me semble que VB.NET est une alternative ayant plus d'avenir tout en proposant un langage verbeux.

Merci infiniment d'avoir pris de votre précieux temps pour nous répondre !

L'équipe Pascal remercie FRANOUCH pour sa relecture.