L'ironie du typage statique dans les langages dynamiques

Vous pouvez également lire cet article sur Medium.

C'est toujours drôle quand on voit comment les langages de programmation évoluent au fil du temps.

Il était une fois, lorsque j'ai commencé mon parcours dans le monde du développement logiciel, les langages dynamiques tels que Python, PHP et JavaScript étaient appréciés pour leur flexibilité et leur syntaxe concise adaptée à un développement rapide.

Cependant, à mesure que ces langages faiblement typés évoluent, ils intègrent des fonctionnalités de langages fortement typés, ce qui les rend très similaires au C et à Java :

• Python : capacités d'indication de type introduites depuis la version 3.5 en 2015 et améliorées dans la version 3.12 en 2022.
• PHP : Types déclarés introduits dans la version 7 en 2015.
• JavaScript : étendu par la sortie de TypeScript en 2012 défini comme "JavaScript avec syntaxe pour les types".

Pourquoi ce changement ?

Dans les langages à typage strict, nous définissons explicitement les types de variables dans notre code. Le but est de détecter les erreurs lors de la phase de développement avant d'exécuter le programme, et de fournir une indication au compilateur sur la taille mémoire à allouer à ces variables.

// C++ example: 'y' will be an integer
float x = 3.14;
int y = x;  //  y = 3 (ignored the decimal part of the number)

D'un autre côté, les langages typés dynamiquement tels que Python, PHP et JavaScript nous permettent de créer des variables et de laisser l'interpréteur impliquer leur type pendant l'exécution :

# In python and PHP: 'y' will take the same type as 'x'
x = 3.14
y = x  // y = 3.14 (float)

Comment le typage explicite est-il introduit dans les langages dynamiques ?

Dans l'exemple suivant, nous déclarons la même fonction en utilisant le typage dynamique et statique.

Python :

# using the classic syntax:
def add(x, y):
    return x + y
# using explicit typing:
def add(x: int, y:int) -> int:
    return x + y

JavaScript/TypeScript :

// using the classic syntax
function add(x, y) {
    return x + y;
}
// using explicit typing
function add(x: number, y: number): number {
    return x + y;
}

PHP :

// using the classic syntax:
function add($x, $y) {
    return $x + $y;
}
// using explicit typing:
function add(int $x, int $y): int {
    return $x + $y;
}

PHP 8.2 (publié en décembre 2022) va plus loin en introduisant la prise en charge de null, true et false en tant que types autonomes :

public null $nil = null;
public false $false = false;`

Où est l'ironie ?

Ne prenez pas cet article comme une objection à ces nouvelles fonctionnalités, je reconnais les avantages de l’utilisation de langages strictement typés. Cependant, utiliser des annotations de type en Python, par exemple, ne vous empêche pas de changer les types de vos variables :

x: int = 0
x = "John" 
print(type(x))   # <class>
</class>

Idem pour PHP, il n'imprimera qu'un avertissement obsolète sur la console.

On pourrait alors se demander pourquoi l'interpréteur nous permet d'exécuter ce code ?
C’est parce que ces langages sont construits de cette façon : ils sont typés dynamiquement par définition. Si on supprime cette caractéristique, ils ne seront plus dynamiques ; ils deviendront des langages strictement typés comme C , mais plus lents.

J'espère que vous pourrez demander à votre interprète d'être plus rigide en définissant strict_types sur true dans votre fichier PHP :

declare(strict_types=1);

En python, vous pouvez utiliser le package 'mypy' pour analyser votre code et détecter les bugs :

// C++ example: 'y' will be an integer
float x = 3.14;
int y = x;  //  y = 3 (ignored the decimal part of the number)

Vous pouvez voir 'mypy' comme un conseiller vous indiquant ce que vous avez fait de mal, mais cela ne vous empêche pas d'exécuter votre code à vos risques.

Même si vous n'êtes pas sûr du type de votre variable, vous pouvez toujours utiliser l'opérateur union pour réduire la liste des types acceptés :

Les exemples suivants de PHP et Python montrent comment procéder :

# In python and PHP: 'y' will take the same type as 'x'
x = 3.14
y = x  // y = 3.14 (float)

Sommes-nous en train de sacrifier la lisibilité du code ?

Il y a dix ans, j'ai décidé d'utiliser Python pour mon doctorat en raison de sa simplicité et de sa capacité à prototyper rapidement de nouvelles idées. Puis j'ai commencé à l'utiliser également pour mes autres projets.

Maintenant, je me retrouve à lire des PEP bizarres et à me demander si ça vaut vraiment le coup de compliquer ma base de code en incluant ces nouvelles fonctionnalités.

Regardons un exemple de fonction qui imprime les éléments d'un dictionnaire. Voici la version initiale :

# using the classic syntax:
def add(x, y):
    return x + y
# using explicit typing:
def add(x: int, y:int) -> int:
    return x + y

En utilisant les recommandations de la PEP 692 introduites dans Python 3.12, le code devient :

// using the classic syntax
function add(x, y) {
    return x + y;
}
// using explicit typing
function add(x: number, y: number): number {
    return x + y;
}

En résumé : nous avons créé une classe qui hérite de TypedDict, spécifié le nom et le type de chaque élément et utilisé l'opérateur Unpack pour indiquer à « mypy » que l'objet reçu est un TypedDict.

En conséquence, notre code a doublé de taille. Cela deviendrait encore plus long si notre objet contenait plus d'éléments.

Heureusement, nous pouvons utiliser le typage statique pour certaines parties de notre code et laisser le reste dynamique. Ou nous pouvons choisir de ne pas l'utiliser du tout si nous préférons.

Quand doit-on l'utiliser ?

Ne vous sentez pas obligé de réécrire l'intégralité de votre base de code simplement parce que vous avez appris une nouvelle fonctionnalité brillante.

Ces nouvelles fonctionnalités sont comme des outils. Mon conseil est de les utiliser à bon escient :

Utilisez la saisie statique dans les scénarios suivants :

• Lors de la récupération de données à partir de sources externes, telles que des bases de données, des bibliothèques et des API.
• Dans les parties critiques de votre code où l'échec n'est pas autorisé.
• Lorsque votre base de code est sujette à des bugs fréquents.

Évitez d'utiliser la saisie statique lorsque vous :

• Concevoir un prototype pour tester rapidement votre idée.
• Implémentation d'une logique interne où la vérification de type n'entraînera qu'un code détaillé avec et aucun avantage.
• Il suffit d'afficher des données sur l'écran (par exemple, tracer des graphiques, des images, des chiffres…).
• Écrire un script de ligne de commande sans intervention de l'utilisateur.

Gardez à l'esprit qu'en matière de codage, la règle d'or est toujours de rechercher la simplicité, sauf si vous avez une bonne raison de compliquer les choses.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!