Entretien avec Philippe Paternotte

Équipe Pascal : Bonjour Philippe, nous vous remercions de nous accorder un peu de votre temps.

Philippe Paternotte : Bonjour. Je ne pense pas que mon avis pèse beaucoup dans ce monde, mais c'est avec plaisir que je réponds à vos questions.

Par ailleurs, c'est l'occasion de vous remercier pour tout le travail que vous effectuez sur Developpez.com, que je suis régulièrement.

Équipe Pascal : Pour commencer, pourriez-vous vous présenter à nos lecteurs ?

Philippe Paternotte : J'ai un parcours un peu particulier. Électronicien de formation, suite à la restructuration de mon entreprise, j'ai commencé la programmation en 1978, sur mini et en assembleur 32 bits, pour des centraux téléphoniques publics (très fortes notions de temps réel…) ; à la même époque, les micro-ordinateurs « grand public » ont pointé leur nez et j'ai naturellement pris le train en marche avec un NASCOM 1 (en kit !) puis avec une version 2 en CP/M, au début comme un hobby accessoire.

En quittant le milieu « Téléphonie » pour le milieu « Automatismes Industriels », j'ai essayé PL/M puis rapidement j'ai adopté le Pascal à titre professionnel avec MT+(1) vers le début des années 1980 (CP/M et MP/M) ; enfin, je suis passé à TP(2) quand il est sorti.

J'ai aussi fait du Basic comme tout le monde. Sur PC, mais aussi en milieu industriel (automates programmables), il y a eu des cartes « add-on » programmables en Basic…

Je fais aussi du Basic VB / VBA depuis VB3 et maintenant VB.NET sous VS, car beaucoup de clients le demandent.

Je n'ai jamais vraiment essayé le C, bien que j'ai traduit quelques bibliothèques en Pascal.

Mes derniers développements ont tous été faits en Delphi XE.

J'ai été chef de projet et développé des solutions logicielles au sein de grandes sociétés dont des SSII orientées Informatique Industrielle/Automation, avec des équipes de travail généralement réduites (2-3 personnes) ; depuis 2009, je suis devenu un consultant indépendant « freelance ».

Équipe Pascal : Avez-vous, au cours du temps, développé des méthodes de travail particulières ?

Philippe Paternotte : Les méthodes de travail sont forcément assez différentes, mais j'ai gardé les méthodologies qualité acquises pendant mes anciens postes, notamment concernant la qualité des commentaires dans le code source, le suivi de versions et la GED(3) avec des moyens développés en interne.

J'ai travaillé avec toutes les versions de TP et Delphi jusqu'à ce jour, mais je me suis cantonné aux OS Windows jusqu'à aujourd'hui.

Côté Delphi, j'utilise beaucoup JCL/JVCL, dont la communauté est très active, et arrive assez bien à suivre la cadence Embarcadero (malgré le manque crucial de documentation : on se lance parfois dans une exploration à la Star Trek) ; divers produits TMS(4) ; un peu d'autres open-source aussi. Par ailleurs, j'ai bien sûr un volume important d'outils maison construits au fil des années.

Équipe Pascal : Qu'est-ce qui vous a amené à développer PIC Micro Pascal et quels sont vos projets ?

Philippe Paternotte : Bien qu'ayant commencé avec les µP dès le 8080, j'ai commencé avec les µC assez tard et uniquement à titre personnel au début des années 2000, au début en assembleur.

Le Basic et surtout le C sont omniprésents dans ce domaine et pour moi ce n'était pas envisageable ; j'ai essayé tout ce qui était disponible sur le net (c'est-à-dire pas grand-chose) pour finir avec le Pascal de chez MikroElektronika - un très bon produit commercial au demeurant - mais leurs bibliothèques fermées m'ont fortement déplu.

Comme j'avais déjà créé des compilateurs de métalangages spécifiques dans le milieu industriel, en 2006 je me suis lancé le défi.

Au début, c'était en D6(5) et c'était plutôt spartiate : pas d'EDI et côté compilateur pas de type checking par exemple, puis tout a évolué et continue d'évoluer…

Le premier EDI était basé sur SynEdit puis, depuis la V2, il a été complètement refondu pour Scintilla.

Pour le développement du compilateur et de l'EDI, je suis seul. Les bibliothèques ont été améliorées ou créées grâce à divers contributeurs. Ils sont cités dans la documentation, avec un peu d'historique.

PMP avait été mis en stand-by quelques temps, principalement du fait de mon manque de temps, mais je m'y suis remis depuis le début de l'année 2016 et une nouvelle version vient de sortir comme cadeau de Noël. Elle voit son EDI amélioré avec de nouveaux outils, des bulles d'aide généralisées et la gestion de la documentation pseudoXML à la Delphi (///) ; le langage intègre un type checking amélioré plus proche des standards Pascal, un micronoyau multitâches simplifié est prévu…

Je ne vois toujours pas de raison de m'arrêter !

Le Pascal de PMP reste un sous-ensemble du standard Pascal habituel, mais les différences et lacunes - parfois déroutantes, j'en conviens - sont résorbées petit à petit.

Beaucoup me demandent un portage vers Linux, très utilisé dans le milieu des µC, mais je ne suis pas encore prêt pour l'aventure. J'ai tenté d'utiliser Lazarus, mais j'ai trouvé un peu trop de problèmes de portage de bibliothèques.

Équipe Pascal : La communauté autour de PMP semble assez active.

Philippe Paternotte : La communauté n'est pas vraiment nombreuse, mais elle croît doucement. Je pense que la rareté des releases y est pour beaucoup. Des participations sous forme de bibliothèques sont de plus en plus régulières.

En dehors de mes besoins personnels, mon objectif principal a toujours été d'apporter le Pascal aux µC 8 bits Microchip aux hobbyistes ayant généralement peu de moyens ; je ne vise pas au-dessus des 8 bits et ce n'est pas un produit commercial avec tout ce que cela implique.

À ma connaissance, MikroElektronika est la seule société commerciale à fournir un produit Pascal de belle qualité (jusqu'au 32 bits), à prix pas trop élevé (200 €, version gratuite bridée), pour les µC Microchip (et pas seulement).

Équipe Pascal : Que pensez-vous de l'évolution du développement en général ? Comment voyez-vous évoluer tout cela, dans un avenir proche ou plus lointain ?

Philippe Paternotte : Le plus grand apport a été le volume croissant d'informations disponibles rapidement via le net, en parallèle avec les concepts de RAD et des EDI performants où l'on a tout « sous la main ».

La roue est réinventée un peu moins souvent et les cycles en V ont été considérablement accélérés. Quelques fois au détriment de la compréhension fine des processus mis en œuvre (c'est d'ailleurs ce que j'ai toujours reproché au .net par exemple).

L'arrivée de nouveaux concepts et supports, notamment le logiciel libre participatif qui permet la diffusion rapide de nouvelles idées, mais - à mon humble avis - la vitesse des changements est quelques fois un peu trop rapide à suivre et la documentation trop souvent oubliée.

J'ai bien entendu suivi le mouvement, mais à ma moindre mesure : je n'ai jamais ressenti le besoin de m'impliquer dans les nouveaux langages. Je ne développe pas d'applications web où se concentrent majoritairement les « nouveaux » besoins.

Comment cela va-t-il évoluer dans le futur ? La grande question ! Honnêtement, je ne pense pas avoir assez de recul pour effectuer un tour complet de la question. Voici quelques idées qui me viennent : je pense que la maîtrise des concepts de la programmation massivement parallèle à tolérance de pannes (modifications « on line » à la volée) et les processus répartis au sein d'un domaine maîtrisé feront la prochaine révolution. L'IOT(6) est intéressant ; toutefois, je vois d'un œil plutôt inquiet l'engouement plus ou moins rapide et aveugle pour le concept de « Cloud » : je vois des dangers non négligeables au niveau sécurité et disponibilité (c'est caricatural, mais ça me fait penser au film « Roller Ball », où le responsable informatique de la bibliothèque mondiale avait perdu « tout le 18e siècle » quelque part sur son « Cloud mondial »…).

Équipe Pascal : Parlons un peu du langage Pascal…

Philippe Paternotte : Hélas, l'utilisation du Pascal a diminué progressivement et son usage a souvent été dénigré au fil du temps, même si les générateurs de code optimisé sont souvent les mêmes et rendent le code tout aussi efficace que dans n'importe quel autre langage compilé.

Quelques fois on a le sentiment de faire partie du « dernier village gaulois » à résister.

Pour moi, le Pascal a toujours sa place - je gagne ma vie avec Delphi sans problème (plus de 40% du CA) - et son élégance, mais également ses lacunes, m'ont toujours convenu.

Je suis toutefois plutôt pessimiste à long terme…

Équipe Pascal : Pourrions-nous avoir votre avis sur les lacunes en question ?

Philippe Paternotte : Ouch, vaste sujet… Pour prendre un exemple simple : la pauvreté de ce que l'on peut appeler le « précompilateur », l'impossibilité de définir des paramètres dans le programme principal, répercutée dans les unités, que l'on pourrait qualifier de « namespace » global des conditional defines…

Prenons un exemple tel que je l'ai implémenté dans PMP.

Dans le programme principal :

Program xxx;
{$DEFINE BAUDRATE 19200}
...
uses uSerial;
...

Dans uSerial :

unit uSerial;
...
{$IFNDEF BAUDRATE}
{$DEFINE BAUDRATE 38400} // Default
{$ELSE}
{$IF DEFINED_VALUE(BAUDRATE) > 38400}
{$UERROR 'BAUDRATE is too high for this processor'}
{$ENDIF}
{$ENDIF}
const
DEFAULT_BAUDRATE = DEFINED_VAUE(BAUDRATE);

En PMP la règle est : tous les $DEFINE sont locaux au module, sauf ceux définis dans le « program » avant sa clause « uses », qui sont globaux et en lecture seule pour les unités.

Ici, l'unité « uSerial » est reconnue comme dépendante de « BAUDRATE », elle est donc recompilée si la définition (ou sa valeur) change.

Quand on écrit son compilateur, on se prend pour un dieu tout puissant…

Comment contourner ceci en Delphi ? Il y a toutes sortes de façons, la plus courante étant de recréer le .h du C en mettant tout dans un .inc et on fait un $I au début de chaque unité ; ou alors une unité dédiée incluse en « uses », etc., mais ça devient fastidieux.

À noter que je ne suis pas particulièrement friand des $DEFINE ailleurs que dans les déclarations ; je préfère en général des constantes Pascal et je les utilise dans des conditions, comme ça :

1. Le compilateur supprime les blocs « toujours faux » ;
2. Le compilateur analyse ces blocs malgré tout (ce qui n'est pas le cas avec les compilations conditionnelles) ;
3. L'EDI trouve les références dans ces blocs alors que les blocs de compilation conditionnelle faux sont ignorés.

Ensuite, plus technique : l'héritage multiple. Souvent, ça aiderait bien… On contourne avec des sous-objets qu'il faut initialiser, lier entre eux d'une manière ou d'une autre…

Notons que bien des choses ont été créées au fil du temps pour contourner certaines frustrations, comme les « helper » qu'officiellement on ne devrait pas utiliser sur la RTL.

Pour conclure : rien n'est impossible avec un peu de méthode. C'est ce que je veux dire par « ses lacunes m'ont toujours convenu », ça ne veut pas dire que je n'aimerais pas que ces lacunes soient comblées…

Équipe Pascal : Quelques considérations et conseils pour terminer ?

Philippe Paternotte : Pour le Pascal : il faut écouter son cœur et minimiser le bruit de fond. L'élégance n'est pas obligatoire, mais améliore le bien-être.

Plus généralement, créer ses propres outils est souvent un bon moyen pour maîtriser son environnement. Voyez comment vos prédécesseurs ont utilisé le Pascal (qui sait que Skype fut écrit en Pascal ?).

Dans la mesure du possible, il ne faut pas réinventer la roue ; utiliser et participer au logiciel libre. Mais c'est valable pour tous les langages.

Équipe Pascal : Nous vous remercions infiniment.

Philippe Paternotte : Merci à votre équipe, c'est avec plaisir que j'ai pu exprimer mes opinions.

Merci à ced pour sa relecture.