Sensibilité à la casse : 70 ans d’évolution de Fortran à Mojo

J’ai commencé mon parcours en programmation avec Pascal. Dans cet environnement, MyVariable et myvariable étaient exactement la même chose. Le compilateur ne faisait aucune différence de casse.

Puis je suis passé au C. myVariable et MyVariable sont devenus deux identifiants complètement différents : la casse avait de l’importance.

Des années plus tard, j’ai appris Go, et j’ai découvert que la casse avait pris une toute autre dimension. Dans Go, la casse de la première lettre contrôle la visibilité :

• ExportedFunction() → visible en dehors du package
• internalFunction() → privée au package

À ce moment-là, je me suis posé une question :

Les langages de programmation deviennent-ils de plus en plus sensibles à la casse avec le temps ?

Pour répondre à cette question, j’ai analysé plus de 50 langages majeurs créés entre 1957 et 2023, et j’ai cartographié la façon dont chacun traite les majuscules.

Le résultat est le graphique ci-dessous.

Avant d’aller plus loin, clarifions ce que signifie la sensibilité à la casse en programmation.

Un langage est sensible à la casse lorsque des identifiants qui ne diffèrent que par leur capitalisation sont considérés comme différents. Par exemple, print, Print et PRINT désignent trois identifiants distincts.

Un langage insensible à la casse considère ces variations comme un seul et même symbole.

​

Une séparation nette : analyse visuelle

Une fois les langages placés chronologiquement, plusieurs tendances apparaissent.

Les premiers langages étaient souvent insensibles à la casse, mais cette approche a progressivement disparu. Les langages modernes considèrent massivement la casse comme significative.

En parallèle, certains langages ont commencé à utiliser la casse non seulement pour distinguer, mais aussi pour encoder du sens directement dans le langage.

Pour comprendre le graphique, il est utile d’examiner les différents modèles utilisés.

​

Comprendre les différents modèles de sensibilité à la casse

En observant les langages du dataset, cinq approches distinctes apparaissent. Certains ignorent complètement la casse, tandis que d’autres en font un élément de syntaxe.

​

1. Langages totalement insensibles à la casse

Dans ces langages, les identifiants sont comparés sans tenir compte des majuscules. Variable, variable et VARIABLE désignent le même symbole.

Exemples : Fortran, COBOL, Pascal, Ada, Visual Basic, Delphi, PowerShell, Common Lisp.

1with Ada.Text_IO; use Ada.Text_IO;
2procedure Example is
3   myVariable : String := "Hello World";
4begin
5   Put_Line (MYVARIABLE);
6end EXAMPLE;

Cette approche était courante dans les premiers langages, où l’objectif était de réduire les erreurs triviales. Historiquement, certains systèmes et encodages sur cartes perforées ne distinguaient même pas les minuscules, ce qui simplifiait l’analyse.

Avec le temps, ce choix est devenu moins fréquent.

​

2. Langages strictement sensibles à la casse

Dans les langages sensibles à la casse, la capitalisation crée des identifiants distincts.

1int value = 5;
2int Value = 10;   // variable différente

Exemples : C, C++, Python, JavaScript, Rust, Swift, Zig, Kotlin, TypeScript, Julia

C’est aujourd’hui le choix dominant.

La sensibilité à la casse apporte :

• Des frontières de symboles plus claires
• Un nommage plus expressif
• Un comportement plus simple pour les compilateurs et les outils

Avec la croissance des systèmes logiciels, ces avantages ont pris le dessus sur les erreurs de casse.

​

3. Sensibilité partielle ou mixte

Certains langages traitent certains identifiants comme sensibles et d’autres comme insensibles.

L’exemple le plus connu est PHP :

• Variables → sensibles à la casse
• Fonctions et classes → insensibles

1$user = "Alice";
2
3echo $USER;      // Erreur (variables sensibles)
4
5myFunction();
6MYFUNCTION();    // Fonctionne (fonctions insensibles)

Ce modèle hybride reflète souvent une construction historique du langage.

​

4. Langages insensibles au style

Une catégorie rare ignore à la fois la casse et certains caractères de formatage.

L’exemple principal est Nim.

Dans Nim, les identifiants sont normalisés : la casse et les underscores n’ont pas d’importance.

1var my_variable = 10
2
3echo myVariable
4echo MYVARIABLE

Les trois identifiants pointent vers le même symbole.

Ce choix facilite l’intégration de bibliothèques utilisant différentes conventions comme camelCase, snake_case, PascalCase.

​

5. Langages sensibles à la casse avec signification sémantique

Certains langages vont plus loin : ils sont sensibles à la casse, mais celle-ci porte aussi du sens.

Dans ces langages, la casse ne sert pas seulement au style — elle encode une partie de la syntaxe.

Plusieurs patterns apparaissent.

​

Variables vs atomes / constantes

Certains langages utilisent la casse pour distinguer variables et constantes.

Exemples : Prolog, Erlang

1X = 10.        % variable
2value = 10.    % atome

Ici, les variables doivent commencer par une majuscule.

​

Types vs valeurs

Dans de nombreux langages fonctionnels, la casse distingue les types des valeurs.

Exemples : Haskell, Elm, OCaml, Gleam

1data Tree = Leaf Int | Node Tree Tree

• Tree, Leaf, Node → type et constructeurs
• minuscules → fonctions ou valeurs

​

Constantes vs variables

Certains langages utilisent la casse pour signaler les constantes.

Exemples : Ruby, Crystal.

1MAX_SIZE = 100

​

Visibilité ou frontières de modules

Dans certains langages, la casse contrôle la visibilité publique.

Exemples : Go.

1func ExportedFunction() {}   // public
2func privateFunction() {}    // interne au package

​

Règles de nommage structurantes

Certains langages récents imposent des conventions.

Exemples : V, C3.

• PascalCase → types
• UPPER_CASE → constantes
• snake_case → variables (V)

​

Une évolution historique claire

En observant l’ensemble du dataset, une évolution nette apparaît :

1. Langages anciens (années 1950–1980) : beaucoup étaient totalement insensibles à la casse.
2. À partir des années 1990 : les langages sensibles à la casse deviennent dominants.
3. Langages modernes : restent sensibles à la casse mais utilisent parfois la capitalisation pour encoder du sens supplémentaire.

Autrement dit, l’industrie est passée de l’ignorance de la casse à son utilisation comme signal structurel du langage lui-même.

Un autre schéma apparaît en distinguant les langages compilés natifs et les langages interprétés dans le graphique.

Les langages natifs convergent fortement vers une sensibilité stricte à la casse. Après les années 1990, presque tous les nouveaux langages natifs du dataset considèrent la casse comme significative.

Les langages interprétés restent plus variés. Si beaucoup sont sensibles à la casse (Python, JavaScript, Lua), d’autres conservent des modèles alternatifs comme la sensibilité partielle (PHP), la casse sémantique (Ruby), ou une insensibilité totale (PowerShell).

Cette différence reflète probablement leurs cas d’usage : les langages systèmes privilégient la précision et des identifiants sans ambiguïté, tandis que les environnements de scripting ont historiquement favorisé la simplicité et la flexibilité. Qu’en pensez-vous ? Faites moi savoir en commentaire.

​

Pourquoi les premiers langages ignoraient la casse

Les origines de l’insensibilité à la casse sont très concrètes.

Les premiers ordinateurs utilisaient des encodages limités. De nombreux systèmes reposaient sur des jeux de caractères sur 6 bits ou sur du matériel ne supportant pas les minuscules.

Les cartes perforées rendaient la situation encore plus contraignante.

En conséquence, des langages comme Fortran et COBOL traitaient majuscules et minuscules comme identiques.

Même après l’évolution du matériel, cette convention est restée.

Des langages comme Pascal et Ada ont volontairement conservé cette insensibilité pour éviter les erreurs de syntaxe triviales.

La philosophie était simple :

Le compilateur doit se concentrer sur le sens, pas sur la typographie.

Niklaus Wirth, créateur de Pascal, a conçu le langage avant tout pour l’enseignement, en cherchant à limiter les erreurs frustrantes.

​

Alors… les langages deviennent-ils sensibles à la casse ?

Sur 70 ans d’évolution, la réponse est globalement oui. Les langages modernes privilégient largement une sensibilité stricte à la casse. Pourquoi ?

Parce que les systèmes logiciels complexes bénéficient de : identifiants non ambigus, outils cohérents et frontières de noms claires.

Mais l’évolution n’est pas totalement linéaire. Certains langages expérimentent la casse sémantique, tandis que d’autres (comme Nim) cherchent à réduire les contraintes de style.

Ce qui était à l’origine une limitation matérielle est devenu un choix de conception, reflétant les compromis entre précision, lisibilité et ergonomie.

​

Tableau détaillé des langages

​

Ai-je oublié votre langage préféré ?

Avec des milliers de langages existants, il est probable que certains aient été oubliés.

Si vous remarquez un langage manquant ou souhaitez contester ma classification d’un cas “atypique”, dites-le-moi dans les commentaires ou contactez-moi via le formulaire de contact.