Anders Hejlsberg a conçu des langages pendant plus de quatre décennies,
mais son influence ne vient pas seulement de leur syntaxe. De Turbo
Pascal à TypeScript, il travaille sur la
relation entre le langage, le compilateur, l’éditeur, les bibliothèques
et la plateforme d’exécution. Pour lui, la qualité de l’expérience de
programmation dépend de cet ensemble.
Cette continuité traverse pourtant des contextes très différents.
Turbo Pascal doit tenir sur les micro-ordinateurs des années 1980 et
compiler avec une rapidité inhabituelle. Delphi vise la création
visuelle d’applications Windows. C# accompagne la plateforme .NET et
doit rester cohérent à mesure qu’il gagne des fonctionnalités.
TypeScript, enfin, doit apporter de l’analyse statique à
JavaScript sans rompre avec son
immense écosystème.
Hejlsberg occupe un rôle d’architecte central dans ces projets, mais
aucun produit durable n’est l’œuvre d’une seule personne. Les équipes de
Borland, les co-concepteurs de C#, l’équipe TypeScript et leurs
communautés transforment les orientations initiales en langages utilisés
à grande échelle.
Programmer sur un micro-ordinateur avant les environnements modernes
Né en 1960 à Copenhague, Anders Hejlsberg étudie l’ingénierie à
l’université technique du Danemark. À la fin des années 1970 et au début
des années 1980, les micro-ordinateurs ouvrent la programmation à un
public plus large, mais leurs outils restent contraints par la mémoire,
la vitesse des processeurs et les supports de stockage.
Le cycle habituel — éditer un fichier, lancer séparément un
compilateur, corriger les erreurs puis exécuter — peut être lent et
fragmenté. Un langage pédagogique comme Pascal possède une structure
claire, mais son accessibilité dépend aussi de la disponibilité d’un
compilateur abordable et réactif.
Hejlsberg développe au Danemark un compilateur Pascal commercialisé sous
les noms Compass Pascal puis PolyPascal. Borland, jeune éditeur dirigé
par Philippe Kahn, en acquiert les droits et l’intègre à un produit
destiné aux micro-ordinateurs : Turbo Pascal.
Turbo Pascal : le compilateur comme expérience complète
Lancé en 1983, Turbo Pascal combine dans un même programme un
éditeur, un compilateur et les commandes nécessaires pour construire et
exécuter le code. Son prix relativement bas, sa distribution simple et
surtout sa compilation rapide contrastent avec de nombreux outils
professionnels plus lourds.
La performance ne constitue pas un détail secondaire. Une compilation
qui répond presque immédiatement modifie la manière de programmer :
l’utilisateur peut essayer une idée, observer le résultat et corriger
son code sans interrompre longuement son raisonnement. Cette boucle
courte annonce l’importance moderne du retour instantané dans les
éditeurs.
Le produit démontre aussi qu’un environnement intégré n’a pas besoin
d’être massif. Les contraintes matérielles poussent Hejlsberg et
l’équipe Borland à réduire les couches, organiser soigneusement la
mémoire et rapprocher les composants.
Turbo Pascal s’appuie sur le langage créé par Niklaus
Wirth, mais il ne se confond pas avec le
Pascal universitaire d’origine. Borland ajoute progressivement des
extensions, des bibliothèques et des capacités adaptées au développement
d’applications. Cette évolution augmente sa puissance tout en créant un
dialecte lié à son environnement.
Hejlsberg est l’auteur original du compilateur et l’un des premiers
employés de Borland. Le succès du produit dépend néanmoins de
l’entreprise entière : ingénierie, documentation, compatibilité avec les
machines et distribution transforment le compilateur initial en une
plateforme durable.
Delphi : unir langage, composants et interface visuelle
Au début des années 1990, le développement pour Windows exige de gérer
une interface graphique, des événements, des bibliothèques et de
nombreuses conventions de plateforme. Les outils visuels promettent
d’accélérer la construction, mais risquent de produire un code difficile
à comprendre ou de limiter le programmeur aux composants prévus par
l’éditeur.
Hejlsberg devient l’architecte principal de Delphi, lancé par
Borland en 1995. L’environnement associe Object Pascal, un concepteur
visuel de formulaires, une bibliothèque de composants et un compilateur
de code natif. Le développeur place des contrôles, configure leurs
propriétés puis écrit les gestionnaires d’événements nécessaires.
La force de Delphi vient de l’intégration entre ces couches. Les
composants visibles dans l’outil correspondent à des objets
programmables ; les propriétés modifiées graphiquement sont reliées au
modèle du langage ; l’application finale bénéficie d’une compilation
rapide.
Cette approche facilite les applications de gestion et les interfaces
Windows sans enfermer totalement le développeur dans un générateur
opaque. Elle possède néanmoins un coût : un projet dépend de la
bibliothèque de composants, des conventions de l’environnement et de la
continuité de la plateforme commerciale.
Delphi prolonge une idée déjà présente dans Turbo Pascal : un langage
obtient une partie de sa valeur du temps qui sépare l’intention du
programmeur d’un résultat visible.
Le passage chez Microsoft et le contexte de .NET
Hejlsberg quitte Borland et rejoint Microsoft en 1996. Il travaille
d’abord sur Visual J++ et les Windows Foundation Classes, dans une
période où Java propose une machine virtuelle, une mémoire gérée et une
portabilité qui attirent fortement l’industrie.
Microsoft prépare parallèlement une nouvelle plateforme d’exécution. Le
futur Common Language Runtime doit prendre en charge plusieurs langages,
gérer la mémoire, fournir une bibliothèque commune et permettre une
interopérabilité contrôlée. Un nouveau langage peut exploiter
directement ce modèle sans porter toutes les contraintes historiques des
outils Windows précédents.
Le projet qui deviendra C# commence dans ce contexte. Il doit offrir la
productivité d’un environnement géré tout en restant familier aux
développeurs de C, C++ et Java. Il doit aussi fonctionner comme une
pièce d’une plateforme multilangage, pas comme un système isolé.
Anders Hejlsberg est le concepteur principal de C#, mais la
spécification officielle cite également Scott Wiltamuth et Peter Golde
parmi ses principaux inventeurs. De nombreuses équipes participent au
compilateur, au Common Language Runtime, aux bibliothèques .NET et aux
outils Visual Studio.
La première version largement diffusée apparaît en 2000 avec
l’initiative .NET. C# reprend une syntaxe à accolades et un typage
statique familier, tout en intégrant dès l’origine une mémoire gérée,
des propriétés, des événements, des délégués, des métadonnées et un
modèle d’exceptions cohérent avec la plateforme.
Le langage cherche un équilibre entre sécurité et accès aux mécanismes
de bas niveau. La plupart du code utilise les garanties du runtime ; des
zones explicitement unsafe permettent certains usages de pointeurs
lorsque la performance ou l’interopérabilité l’exigent. Cette séparation
rend le risque visible au lieu de le laisser imprégner tout le
programme.
C# est standardisé par Ecma puis par l’ISO. Cette standardisation
distingue la définition du langage de l’implémentation particulière de
Microsoft, même si .NET reste son environnement principal.
Comparer C# à Java uniquement par leur syntaxe masque leurs
trajectoires. Les deux utilisent une exécution gérée et des idées
communes à de nombreux langages. C# évolue toutefois en dialogue étroit
avec le Common Language Runtime et adopte au fil du temps des mécanismes
propres, notamment LINQ, les propriétés avancées, les types valeur, les
délégués et une intégration croissante de styles fonctionnels.
Faire évoluer C# sans perdre sa cohérence
Un langage largement adopté ne peut plus être redessiné librement.
Chaque nouveauté doit cohabiter avec des millions de lignes existantes,
les outils, les bibliothèques et les habitudes de lecture. Le travail
d’architecte devient alors une gestion de contraintes contradictoires.
Les génériques de C# 2.0 évitent de nombreux transtypages tout en
bénéficiant d’un support du runtime. C# 3.0 introduit les expressions
lambda, les méthodes d’extension et LINQ, qui permet d’exprimer des
requêtes sur des collections, bases de données ou documents au moyen de
constructions intégrées au langage.
Les versions suivantes ajoutent notamment l’asynchronisme avec async
et await, la reconnaissance de motifs, les types enregistrement et des
améliorations de concision. Plusieurs de ces fonctions rapprochent C#
des langages fonctionnels sans abandonner son modèle orienté objet ni sa
compatibilité.
Cette accumulation comporte un risque réel : le langage devient plus
difficile à apprendre et plusieurs styles peuvent exprimer la même
opération. L’équipe doit donc arbitrer entre expressivité locale et
charge conceptuelle globale. La contribution de Hejlsberg tient moins à
l’ajout systématique de fonctions qu’à la recherche de mécanismes
capables de se composer avec l’existant.
JavaScript à grande échelle : le problème qui mène à TypeScript
Au tournant des années 2010, JavaScript ne sert plus seulement à ajouter
quelques interactions dans une page. Des équipes construisent de grandes
applications web avec des modules nombreux et des bibliothèques dont les
objets ne possèdent pas toujours une description formelle exploitable
par l’éditeur.
Le typage dynamique favorise l’expérimentation, mais il limite certaines
analyses avant l’exécution. Renommer une propriété, découvrir les
membres disponibles ou suivre la forme d’un objet à travers une base de
code devient difficile lorsque l’outil ne peut pas déduire suffisamment
d’informations.
Une solution entièrement séparée de JavaScript aurait cependant peu de
chances de reprendre son écosystème. Les applications dépendent du
navigateur, de Node.js, de paquets existants et de comportements parfois
très dynamiques. Le nouveau langage doit rencontrer ces programmes là où
ils se trouvent.
TypeScript : décrire JavaScript plutôt que le remplacer
Microsoft présente publiquement TypeScript en octobre 2012, avec
Hejlsberg comme architecte principal. Le langage ajoute des annotations
et un système de types à JavaScript, puis produit du JavaScript standard
destiné aux environnements existants.
Ses objectifs de conception sont révélateurs : préserver le comportement
d’exécution de JavaScript, ne pas imposer de coût lié aux types dans le
code produit, suivre les standards ECMAScript et conserver un système de
types effaçable. Après la compilation, les annotations n’existent plus ;
elles servent au contrôle, à la navigation et à l’éditeur.
TypeScript emploie principalement un typage structurel. Deux valeurs
sont compatibles selon les membres qu’elles possèdent, pas seulement
selon une déclaration nominale commune. Ce choix correspond aux
pratiques de JavaScript, où des objets créés par des bibliothèques
différentes peuvent partager la même forme sans hériter d’une classe
centrale.
Le langage doit également représenter des habitudes dynamiques :
propriétés optionnelles, unions, surcharge décrite par plusieurs
signatures, raffinement après un test, génériques et types
conditionnels. Ces fonctions ne cherchent pas à transformer JavaScript
en C#. Elles construisent un vocabulaire statique capable de décrire des
motifs déjà employés dans l’écosystème.
Les fichiers de déclaration et la valeur d’une communauté
Une bibliothèque JavaScript peut rester écrite sans TypeScript tout en
offrant une expérience typée grâce à un fichier de déclaration .d.ts.
Celui-ci décrit ses fonctions, objets et modules sans modifier son code
d’exécution.
Le projet communautaire DefinitelyTyped rassemble ces déclarations pour
un grand nombre de paquets. Il joue un rôle décisif dans l’adoption :
les développeurs peuvent intégrer progressivement TypeScript au lieu
d’attendre que toutes leurs dépendances soient réécrites.
Cette stratégie présente aussi des limites. Une déclaration peut être
incomplète ou ne plus correspondre à la bibliothèque qu’elle décrit. Le
système de types doit parfois accepter des compromis pour modéliser des
comportements JavaScript difficiles à vérifier statiquement. Une
compilation sans erreur ne prouve donc ni l’absence de défaut logique ni
la conformité des déclarations avec l’exécution réelle.
TypeScript privilégie délibérément l’utilité sur une sûreté absolue.
Certaines règles sont configurables, et le type any peut suspendre une
partie des contrôles. Ce compromis facilite la migration, mais oblige
les équipes à choisir un niveau de rigueur et à surveiller les
échappatoires.
Un projet ouvert qui doit suivre JavaScript
TypeScript est publié en logiciel libre et développé publiquement. Ce
choix ne relève pas seulement de la distribution : le langage doit
recevoir les exemples, désaccords et cas limites d’une communauté
beaucoup plus vaste que son équipe initiale.
L’équipe évite progressivement d’ajouter des fonctions d’exécution
propres lorsque celles-ci devraient appartenir à JavaScript. Elle
participe plutôt au processus de standardisation ECMAScript, puis ajoute
le support de la syntaxe standard. TypeScript reste ainsi une couche
d’analyse et d’outillage au-dessus d’un langage vivant.
Cette discipline explique sa capacité à coopérer avec différents
bundlers, frameworks, linters et environnements. Le compilateur ne
cherche pas à devenir toute la chaîne de construction. Ses services de
langage fournissent en revanche complétion, navigation, refactorisation
et diagnostics aux éditeurs.
Le résultat rejoint une préoccupation présente dès Turbo Pascal :
réduire la distance entre l’écriture et le retour de l’outil. Le
matériel et les écosystèmes ont changé ; l’attention portée à cette
boucle demeure.
Une œuvre d’architecte, pas une succession d’inventions solitaires
Présenter Hejlsberg comme l’unique auteur de quatre langages effacerait
les institutions et les équipes qui les ont rendus possibles. Turbo
Pascal transforme son compilateur initial grâce à Borland. Delphi
mobilise une équipe de plateforme et de composants. C# naît avec
Wiltamuth, Golde et les équipes .NET. TypeScript évolue sous l’action de
ses ingénieurs, contributeurs et utilisateurs.
Son rôle spécifique apparaît dans les décisions qui organisent ces
efforts : vitesse de la boucle de compilation, cohérence entre langage
et environnement, adoption progressive, compatibilité et capacité des
outils à comprendre le programme.
Il faut aussi résister à un récit où chaque projet corrigerait
simplement le précédent. Turbo Pascal, Delphi, C# et TypeScript
répondent à des problèmes différents. Leur parenté vient d’une méthode
de conception, non d’une ligne droite vers un langage supposé définitif.
Pourquoi Anders Hejlsberg compte encore
L’histoire des langages se concentre souvent sur la syntaxe ou les
paradigmes. Le parcours de Hejlsberg montre que l’expérience dépend tout
autant du temps de compilation, des messages d’erreur, de la complétion,
des bibliothèques, de la migration et de la compatibilité avec les
programmes existants.
TypeScript illustre particulièrement cette idée. Sa réussite ne vient
pas de l’abandon de JavaScript, mais de sa capacité à analyser des
pratiques réelles, préserver leur exécution et fournir des outils plus
riches. Cette stratégie accepte une sûreté imparfaite pour rendre
possible une adoption graduelle.
C# présente l’autre face du problème : lorsqu’un langage possède sa
propre plateforme, il peut coordonner types, runtime et bibliothèques
plus profondément, mais doit gérer le poids croissant de sa
compatibilité.
Entre ces deux modèles, Hejlsberg a contribué à une question centrale de
la conception moderne : comment améliorer l’expression et les garanties
sans couper les développeurs de l’écosystème qu’ils utilisent déjà ?
Chronologie
- 1960 : naissance d’Anders Hejlsberg à Copenhague, au Danemark.
- Début des années 1980 : développement de Compass Pascal, ensuite
connu sous le nom de PolyPascal.
- 1983 : lancement de Turbo Pascal par Borland.
- Années 1980–1990 : évolution de Turbo Pascal et de son modèle
objet au sein de Borland.
- 1995 : lancement de Delphi, dont Hejlsberg est l’architecte
principal.
- 1996 : arrivée chez Microsoft et travail sur Visual J++ et les
Windows Foundation Classes.
- Fin des années 1990 : conception du langage qui deviendra C#
avec les équipes .NET.
- 2000 : première diffusion large de C# dans le cadre de
l’initiative .NET.
- 2002 : première version de C# standardisée par Ecma.
- 2007 : C# 3.0 introduit notamment LINQ et les expressions
lambda.
- 2012 : présentation publique de TypeScript ; C# 5 généralise le
modèle
async/await.
- 2014 : publication de TypeScript 1.0.
- Années 2010–2020 : évolution continue de C# et TypeScript avec
leurs équipes et communautés ouvertes.
Questions fréquentes
Anders Hejlsberg a-t-il créé Turbo Pascal ?
Il est l’auteur du compilateur Pascal initial acquis par Borland et
devient l’architecte central de Turbo Pascal. Le produit commercial, ses
nombreuses versions et son environnement résultent toutefois du travail
collectif des équipes Borland.
Anders Hejlsberg est-il l’unique créateur de C# ?
Non. Il en est le concepteur principal, mais la spécification cite Scott
Wiltamuth et Peter Golde parmi les principaux inventeurs. Le langage, le
runtime .NET, les bibliothèques et les outils ont été construits par de
nombreuses équipes.
TypeScript remplace-t-il JavaScript ?
Non. TypeScript analyse une extension typée de JavaScript puis produit
du JavaScript destiné aux navigateurs et autres moteurs existants. Son
objectif est de mieux outiller les bases de code JavaScript, pas de
créer un runtime concurrent.
Pourquoi les types TypeScript disparaissent-ils à l’exécution ?
Ils servent au contrôle statique et aux outils de développement. Leur
effacement préserve le comportement et le modèle d’exécution de
JavaScript, évite un coût runtime propre aux types et maintient la
compatibilité avec son écosystème.
Quel fil relie Turbo Pascal, C# et TypeScript ?
Ces projets cherchent tous à raccourcir la boucle entre intention,
diagnostic et résultat. Ils intègrent langage et outils, mais selon des
contraintes différentes : machine limitée pour Turbo Pascal, plateforme
gérée pour C#, écosystème JavaScript existant pour TypeScript.
