Interview Smalltalk 4 : Bernard Pottier

Voila la quatrième interview Smalltalk de notre série sur #doesNotUnderstand:. Cette semaine, il s’agit de Bernard Pottier, enseignant-chercheur à l’Université de Bretagne Occidentale (UBO).

Peux tu nous en dire un peu plus sur toi ? Quel est ton métier, ton parcours ?

J’ai une formation initiale en mathématiques appliquées, je suis revenu à l’Université intéressé par l’éclosion de la micro-informatique. Ma culture initiale en informatique est celle de la mise en oeuvre des langages de programmation. J’ai ainsi touché à Lispkit, Simone (un langage de simulation proche de Pascal, et basé sur les moniteurs), Smalltalk-80.

Ensuite je me suis intéressé au parallélisme, puis à l’architecture, et à cette technologie un peu matérielle, un peu logicielle, que l’on nomme ‘reconfigurable’. L’essentiel de mes travaux se situe dans ce domaine.

Actuellement je suis responsable d’une équipe de recherche à l’UBO.

Quand et dans quelles circonstances as tu commencé à utiliser Smalltalk ? Quelles sont les raisons qui t’ont poussé vers ce langage de programmation plutôt qu’un autre ?

L’image virtuelle Smalltalk-80 a été rendue disponible en 1983 avec le ‘Blue Book’ Goldberg-Robson (publié chez Addison-Wesley, et on en trouve toujours des exemplaires d’occasion chez Amazon). Auparavant un numéro spécial de Byte avait assuré une publicité grand-public à ces travaux.

L’équipe où je travaillais avait obtenu un contrat de recherche (CNET) pour porter cet environnement sur une machine multi-processeur tournant sous Unix. Je me suis occupé de la mise en oeuvre d’une machine virtuelle (MV) à partir du Blue Book, en C et assembleur.

Ce travail a été à la fois passionnant et frustrant. A cette époque les machines graphiques commencaient à apparaitre. Nous n’avions jamais vu Smalltalk tourner avant de le voir booter sur notre propre machine (peut être 10 minutes pour charger et dessiner les fenêtres la première fois!). Notre MV avait des performances comparables à celles d’Apple (ancêtre de Squeak), un ton sous celle de Berkeley, lorsque nous avons arrêté le projet.

J’ai repris Smalltalk (ParcPlace) au début des années 90 pour enseigner la programmation et les méthodes objets. Puis un projet de recherche tourné vers la CAO du reconfigurable a débuté vers 1995. C’était un énorme boulot, il fallait être très efficace en vitesse de développement et en terme d’abstraction. J’ai choisi Smalltalk pour ces raisons. Noter que ce n’est pas original, la réfaction, ou la mise en oeuvre d’outils matériel est un fait courant aux Etats-Unis: Texas Instruments, AMD, Tektronix, Atmel … ont, ou ont eu des développements enfouis ou structurels effectués de cette manière.

On reparle aujourd’hui de ‘reboucler’ Smalltalk sur le matériel, en quelques dizaines de milliers de lignes selon Kay. Je trouve que cette intégration est une très bonne idée. Les outils usuels sont trop compartimentés et induisent quantité de contraintes inutiles.

Quelles versions de Smalltalk utilise tu le plus souvent et pourquoi ?

Visualworks dans ses différentes versions (depuis la 3.0), un peu de Squeak, mais plutôt pour investiguer les portages de machines virtuelles (MV).

Quels produits Smalltalk as tu développé ? Quels sont tes projets ?

Un laboratoire ne développe pas de produit. Tout au plus ce sont des démonstrateurs. Notre équipe a développé un ensemble d’outils que l’on appelle ‘Madeo’ pour les FPGAs et maintenant le reconfigurable utilisé dans les systèmes sur puces (SoC).

Madeo permet de décrire des organisations de circuits, en terme de motifs hiérarchisés, de ressources de routage et de ressources logiques transformant l’information.

Madeo permet aussi de transformer du code Smalltalk-80 combinatoire ou séquentiel en un circuit placé routé en passant par des arbres d’appels de méthodes que l’on transforme en tables pré-calculées, que l’on réduit avant d’en construire une représentation logique implantable dans le matériel.

Pour simplifier, on peut en rester à dire qu’une exécution est un réseau de tables précalculées dont les arcs sont des ensembles d’objets. C’est une vision à la fois applicative, et proche du matériel. Le matériel implante un comportement spécifique à un ensemble de définition.

Dans ce processus, on peut dire que la méthode Smalltalk est compilée pour un contexte particulier. Le langage va rester réflexif, le matériel indexant les objets résultants d’un jeu de données entrant (visiter http://as.univ-brest.fr/reports).

Peut-on tout faire avec ces réseaux ? Non. Mais aujourd’hui, on peut les contrôler via une surcouche ‘Hierarchical Control Data Flow Graph’ (HCDFG) qui permet de modéliser des systèmes de processus, par exemple pour décrire et synthétiser une instruction et bientôt un interpréteur en appui sur Madeo. Les HCDFG ont des API Smalltalk et Java grâce à un modèle commun géré par Platypus d’Alain Plantec (Squeak cette fois).

Ce qui se dessine à l’horizon est une description de MV généraliste distribuée sur un système sur puces complètement décrite en Smalltalk et intégrant la synthèse d’architecture et la synthèse logique. Cela permettra aussi de produire des accélérateurs spécifiques par spécialisation de la MV et reconditionnement des objets.

Quels sont les avantages et inconvénients de Smalltalk ? Que faudrait-il faire pour l’améliorer ? As tu envie parfois de changer de langage ?

La capacité à représenter et articuler des abstractions, donc à décrire des mécanismes réutilisables opérationnels. Il n’y a pas besoin de changer Smalltalk, peut être de savoir l’utiliser différemment en acceptant qu’à certain moments il faut typer, renoncer à l’exécution généraliste, pour gagner d’autres
propriétés. Le travail à faire aujoud’hui est la couverture des nouvelles technologies d’intégration. Le mono-processeur est dépassé, il faut s’intéresser au parallélisme et trouver comment un langage moderne peut aider à exploiter ces ressources.

Quant à changer de langages … Bien sûr on ne se contente pas de Smalltalk-80 et on pique des idées d’autres cotés (CSP, Occam, par exemple).

Quels projets Smalltalk te semblent pouvoir avoir le plus de retentissement dans le futur ?

Certainement un effort majeur sur les machines virtuelles. Il faut rattraper le retard accumulé, d’autant que les ressources matérielles sont là. Le style applicatif des collections associé à une architecture spéculative doivent permettre de bénéficier d’une vitesse d’exécution supérieure à celles des langages séquentiels en gardant un code très dense.

Smalltalk te semble-t-il suffisamment utilisé dans l’industrie ? Est-ce que c’est un marché de niche ? Est-il possible de vivre en étant développeur Smalltalk ?

Entre ce que les étudiants savent faire et des produits il n’y a qu’un pas qui peut être vite franchi. Effectivement pour certaines niches où il faut produire une solution rapidement, c’est probablement un des meilleurs outils. Il y a peut-être aussi plus d’opportunités que l’on pense à proximité des nouvelles technologies.

Comment reste-tu connecté avec la communauté Smalltalk ?

Je suis les forums, les publications et l’évolution des outils.

Quels conseils donnerais tu à un développeur qui voudrait commencer à apprendre Smalltalk ?

Faire plein de petits exercices de programmation en découvrant les collections et s’assurer que l’on sait régler des petits problèmes algorithmiques très vite. On peut par exemple traiter des questions relevant
des outils Linux en remplacant awk, sed, sort, uniq, (perl), par du code Smalltalk. Idem pour les streams et la programmation séquentielle. Faire quelques exercices d’IHM sur des modèles de donnée que l’on développe. Faire une vraie application, y compris son image de déploiement. (c’est de cette manière que l’on essaie de motiver les étudiants)

WordPress database error: [Table 'doesnotunderstand.wp_comments' doesn't exist]
SELECT * FROM wp_comments WHERE comment_post_ID = '363' AND comment_approved = '1' ORDER BY comment_date


Subscribe

Subscribe to my RSS Feeds