Le typage fort

En supposant que les types soient raisonnables, leur complexité ne fera que représenter la complexité des règles métier, qui est inévitable. Que ce soit en POO, en fonctionnel, en typé, en non typé, …, il faut de toute manière gérer la complexité augmentant non-linéairement à un moment ou à un autre. La question est de savoir par quel moyen, et les types « riches » en est un parmi d’autres

Je pense qu’il faut tempérer un peu; les systèmes de types font des compromis entre simplicité et flexibilité, ne peuvent pas représenter des contraintes arbitraires en gardant la même simplicité d’utilisation que quand on s’en sert pour représenter des contraintes simples.

En général chaque système de type a ses zones de confort, les choses qui vont être faciles à représenter sans perte d’utilisabilité, sa zone d’inconfort, les choses qu’il est possible de représenter mais on souffre, et des zones où on ne peut plus faire (par exemple tous les systèmes de types ne sont pas capables de bien gérer les unités de mesure comme mentionné par Javier).

Du coup quand on choisit de coller à la structure du domaine, il y a parfois des arbitrages à faire en tant que programmeur. Je pourrais mieux représenter telle contrainte, mais à quel coût en complexité dans le code ? Il faut décider où placer le curseur entre sûreté statique et confort de programmation, sachant qu’un langage avec un meilleur système de type va permet de le placer beaucoup plus haut.

Si tu veux du typage fort en PHP, il faut attendre P++.

Source : https://php.developpez.com/actu/274088/Un-developpeur-de-PHP-propose-un-langage-fortement-type-le-Pplusplus-avec-des-fonctionnalites-plus-avancees

Salut,

Ok, autant pour moi, dans ce cas nous ne sommes juste pas d’accord.

J’ai voulu citer chaque idées pour faire une réponse propre mais je pense que la réponse va être surchargé et ça me demande vraiment du temps. Je ne m’attendais pas à tant de réponses en fait. Je vous remercie pour toutes ces réponses !

En fait, je suis au mieux les lignes directrices d’un langage. Que ça soit au niveau du style d’indentation que du nommage des variables pour ne citer que ces deux points. J’en suis venu à me poser la question de quoi faire concernant le PHP 7 car les deux étaient autorisés. Or, je ne sais pas du tout vers quoi m’orienter. J’ai aussi entendu l’arrivée de P++ mais je pense que ce langage pointera le bout de son nez dans un certains temps. Par la suite, je me suis donc posé du typage dans les langages informatiques.

Ce que je vois en premier lieu, c’est l’éloge du typage fort. Le seul avantages du typage faible que je retrouve souvent est la facilité d’écriture du code. Je n’avais par ailleurs pas pensé à une communauté d’utilisateurs ayant pour habitude de ne pas typer (en PHP pour rester dans le sujet) et qui du jour au lendemain doit changer ses habitudes. Vraiment, je n’ai lu que très peu de véritables avantages au typage faible. Quand j’ai commencé la programmation, je me suis dit que c’était génial de ne pas typer et que ça serait de plus en plus présent en programmation. Je voyais ça comme une automatisation d’une tâche ingrate. J’ai rapidement fait le parallèle avec le prince de ramasse-miettes.

Par ailleurs, je n’ai pas trop compris les faiblesses du typage en Java. Aussi, je viens d’apprendre que la JVM gardait une rétrocompatibilité. Je comprends mieux aussi l’existence d’une pléthore de langages avec chacun leurs particularités.

Concernant mon utilisation du PHP, comme je l’ai dit, je ne sais vraiment pas si je dois me mettre à utiliser le typage fort. Niveau performance, je ne sais pas ce que ça donne mais je pense que vu le gain de PHP 7 par rapport à PHP 5, ça ne se verra pas. Concernant le choix du langage pour un projet, je me rends compte que le typage peut en fait être un critère.

Pour répondre à la question du linter, je n’en utilise pas mais il faudrait peut être. J’utilise ce qui est intégré. Je crois qu’il s’agit de Xdebug.

Je pense que je manque de culture concernant la programmation. Je n’ai utilisé que des langages ayant un gros héritage du C (hormis un peu de COBOL, d’assembleur et de Lua). Je ne sais pas si ça entre en ligne de compte concernant le sujet du typage.

L’argument "PHP n’a pas été conçu comme ça au départ" est complètement bidon.

Rappelez-vous : PHP n’a absolument pas été conçu pour la programmation objet au départ. C’est un bricolage qui a été ajouté au dessus des tableaux associatifs en PHP3, puis rebidouillés en PHP5, etc. Il faudrait donc se passer ce que la programmation OO a apporté ???

La vraie question, c’est

• dans quel état est un langage à un moment donné
• quels problèmes sont les plus embêtants
• comment on peut faire évoluer le langage pour arranger ça, en évitant de tout casser.

En PHP, dans le code existant, trop de bugs dûs à des erreurs stupides, qui auraient été détectés par contrôle de type, ou des programmeurs plus intelligents. Problème : on doit garder les programmeurs. Comment arranger ça ? Même problème avec JavaScript d’ailleurs.

• Solution 1 : un "sur-langage" avec annotations de type, qui est vérifié et traduit dans le langage de base (ex: TypeScript)
• Solution 2 : Evolution du langage

Entièrement d’accord. PHP aurait eu un typage fort, voire statique, ça m’aurait épargné de nombreuses erreurs à cause de fonctions comme iconv, qui retourne soit une chaîne de caractères, soit false.

Après, quand à savoir si c’est une mauvaise pratique de gérer les erreurs comme ça, c’est un autre débat.

Ce n’est pas une histoire d’habitude, c’est une histoire de compréhension. Tu m’aurais posée la question y’a 4 ans, j’aurai répondu "typage faible". Dans ma tête, c’était moins contraignant, ça me permettait de réutiliser certaines variables plutôt que d’en créer des nouvelles (optimisation manuel) et de pouvoir construire mes propres objets sur mesure.

Sauf qu’aujourd’hui je sais qu’un code typé est plus maintenable sur le long terme, on peut générer de la documentation à la volée, ce n’est pas à moi d’optimiser la création et de libérer des variables mais c’est bien le rôle du Garbage Collector et du système d’interprétation / compilation. Puis même avec un langage typé, j’ai toujours pu construire mes objets sans limite particulière (avec l’expérience de l’algorithmie). On réfléchit davantage aux choix des types de variables et à leur utilité. Ça améliore également la sécurité dès qu’on touche à une BDD ; ne pas typer des données en entrée avant de les ajouter à une table ou une collection, c’est du suicide…

Après j’aime pas le fonctionnement des décorateurs sur Typescript pour le coup je préfère le fonctionnement de C#. question de goût.

ce n’est pas à moi d’optimiser la création et de libérer des variables mais c’est bien le rôle du Garbage Collector et du système d’interprétation / compilation.

ça c’est faisable sans typage statique (python a un gc) et sans typage fort (php a un GC depuis PHP 4).

On réfléchit davantage aux choix des types de variables et à leur utilité.

pas forcément. Au pire tu auras une vraie réflexion dans les langages qui te donnent le choix entre un type "brut" et un type "référencé" comme Go ou C++ où les performances peuvent passer du simple au double juste en choisissant le bon type au bon moment (faire des fonction avec passage par copie c’est une très mauvaise idée par exemple).

Par contre dès que le langage n’introduit pas ces concept les deux seules choses qui sont vraiment importantes c’est "quel est la sémantique de ma variable", en gros "est-ce une constante, une variable temporaire, un accumulateur…?". Ici le "type" n’est pas forcément important, sauf si ton système de typage inclus ces notions.

De la même manière, bien que moins visible, on a vu de plus en plus de langage introduire dans leur système de typage le moyen de dire qu’un objet était nullable ou pas, voire d’encapsuler cette possibilité pour éviter les NullPointerException ou affilié.

En effet. C’était simplement pour dire que réutiliser des variables pour optimiser, c’est inutile avec des GC performants. Au contraire, il vaut mieux l’aider si le langage le permet. Bon en l’occurrence, ça change peut-être pas grand chose pour PHP & Python ; mais j’ai lu que pour d’autres langages comme C# y’avait des réels optimisations - grâce notamment au typage fort, puis-ce que le système connaît avant même d’exécuter le code, les types d’arguments qu’il va potentiellement rencontrer.

Oups, ma formulation portait beaucoup trop à confusion ; mea culpa. C’était plutôt au niveau de la signature d’une fonction, un langage typé facilite la compréhension.

Par exemple si je prends une fonction de ce style :

function ajouter (a, b) {
  // opération
}

Ça risque d’être compliqué de comprendre au premier abord de quels type d’objets ont traite. Des nombres, des tableaux, des chaînes de caractères ?

Alors que si je code :

public int ajouter (int a, int b) {
  // potentiellement ça retourne a + b
}

On comprend tout de suite ! personne n’aura l’idée de transmettre des flottants.

Par contre dès que le langage n’introduit pas ces concept les deux seules choses qui sont vraiment importantes c’est "quel est la sémantique de ma variable", en gros "est-ce une constante, une variable temporaire, un accumulateur…?". Ici le "type" n’est pas forcément important, sauf si ton système de typage inclus ces notions.

Avec un bon système de typage, tu peux surtout aller beaucoup plus loin que ça et justement ne plus avoir que la sémantique elle même d’apparente sans qu’un utilisateur de ta lib ait à se préocupper de la représentation interne des choses. Tu peux demander par exemple explicitement à ce qu’une entrée soit une IP, un nombre patates, ou encore un trademark, peu importe la façon dont ces choses sont stockées en terme de types "simples" qui ne deviennent alors plus qu’un détail d’implémentation.

Tiens, ça me fait penser à quelque chose qui m’a manqué aujourd’hui.

On cherche à modéliser les comportements d’un système.

Définir des types à la OCaml aurait été idéal :

type signal = Value of float | None | Error;;
type status = On | Off;;

pour ensuite décrire comportements par filtrage de motifs, comme l’attribution d’une valeur par défaut pour une entrée erronée ou absente :

let transform status input = match (status, input) with
| (On, Value v) -> v
| (On, None) -> 0. 
| (On, Error) -> 0.
| (Off, _) -> 1. ;;

Notre outil de modélisation a un système de typage qui s’apparente à du typage fort avec inférence de type et plein de casts implicites, mais qui est essentiellement limité à des types simples (booléens, flottants, entiers et des arrays de ces types).

On se retrouve à gérer l’implantation, qui se fait grosso modo sur un entier, et l’interprétation en termes de valeur numérique ou de valeur spéciale à différents endroits du modèle et tout le tintouin.

Ce qui nous intéresse le plus étant le quoi plutôt que le comment, ça nous fait une belle jambe de savoir implanter nos types à l’aide d’un entier… On s’en fiche de comment c’est fait. On est intéressé par les propriétés liant la sémantique de l’entrée et la sortie. On se retrouve malheureusement à devoir l’exprimer à un niveau plus bas que nécessaire avec tous les problèmes de lisibilité, concision, erreurs que ça peut causer.