Informatique

https://youtu.be/fLXDRQBbh3E?t=705

Bordel, je sais pas si on se rend bien compte de l'usine à gaz que sont devenus les frameworks PHP

Maintenant, leur nouveau délire, c'est de mettre du typage partout dans les API

Qu'est-ce que ça va faire ? Et ben ça veut dire que chaque fois que vous appelerez une fonction de framework, l'interpréteur PHP va vérifier en runtime que vous avez bien passé les bons types

En quoi c'est mal ? Et ben ça va ralentir encore plus votre code, puisque PHP devra vérifier chacun de vos paramètres vu qu'on est dans un langage interprété et pas compilé

Et tout ça pour générer du HTML

Et je parle même pas de ce que ça donne quand on ajoute sur ce backend PHP du frontend JS genre React

Ce monde est fou

Olala, les sites vont être 0.0000001% plus lent, c'est une catastrophe !!!¡!!¡$$

T'as des benchmarks qui prouvent que ça un réel impact ?

Une categorie de bug les plus difficile a trouver dans les langages non type sont les erreurs de types. Et ce sont souvent les types de bugs qui ont les pires consequences si ils sont deploye parcequ'ils peuvent polluer les donnees qui restent stocke a long terme. Donc en terme d'ingenerie, le cout de la verification vaut probablement les cycles rajoute.
Personnelement, j'attend impatiament que python face la meme chose pour que le langage devienne moins fatiguant a ecrire et maintenir.

En terme de surcharge de calcul, l'impact devrait etre faible. Tu as un benchmark qui montre que c'est un probleme? En principe un interpreteur peut eviter de faire la verification de type si l'execution vient d'une source qui a ete verifier completement. (Est ce que l'interpreteru PHP standard fait ca, je ne sais pas.) Du fait si sympfony a ete ecrit enteirement avec des types specifie, tu ne payes pas la verification de type dans symphony, mais seulement a l'interface avec symphony.
Et si le code appelant a ete ecrit avec des types, alors tu ne paye pas ce cout a l'appel non plus.

Donc perso, ca m'a l'air d'etre plutot une bonne chose!

Pour rappel l'auteur n'est pas en capacité mentale de comprendre l'étendue du spectre du dev web

Il comprend pas qu'un site web ça peut être infiniment plus complexe que muh muh landing page

Le 21 mai 2022 à 16:11:35 :
Pour rappel l'auteur n'est pas en capacité mentale de comprendre l'étendue du spectre du dev web

Il comprend pas qu'un site web ça peut être infiniment plus complexe que muh muh landing page

Et donc, Rougepile, tu travailles sur quel "spectre du dev web" toi ?

Quel est donc ce projet "infiniment plus complexe" qui t'oblige à utiliser React ?

No troll, j'essaie de comprendre sur quoi tu travailles

Le 21 mai 2022 à 16:09:44 :
Une categorie de bug les plus difficile a trouver dans les langages non type sont les erreurs de types. Et ce sont souvent les types de bugs qui ont les pires consequences si ils sont deploye parcequ'ils peuvent polluer les donnees qui restent stocke a long terme. Donc en terme d'ingenerie, le cout de la verification vaut probablement les cycles rajoute.
Personnelement, j'attend impatiament que python face la meme chose pour que le langage devienne moins fatiguant a ecrire et maintenir.

En terme de surcharge de calcul, l'impact devrait etre faible. Tu as un benchmark qui montre que c'est un probleme? En principe un interpreteur peut eviter de faire la verification de type si l'execution vient d'une source qui a ete verifier completement. (Est ce que l'interpreteru PHP standard fait ca, je ne sais pas.) Du fait si sympfony a ete ecrit enteirement avec des types specifie, tu ne payes pas la verification de type dans symphony, mais seulement a l'interface avec symphony.
Et si le code appelant a ete ecrit avec des types, alors tu ne paye pas ce cout a l'appel non plus.

Donc perso, ca m'a l'air d'etre plutot une bonne chose!

Oui, il faudrait des benchmarks, surtout les gros frameworks comme Symfony, ceci dit Rasmus Ledorf lui-même dit que ça impacte les performances et que c'est pour ça d'ailleurs qu'on ne pourra jamais typer les variables en PHP, parce que l'interpréteur passerait tout son temps à vérifier des types.

Scénario cauchemar :

for (int $i = 0; $i < 1000; $i++) {
    // ...
}

La boucle va vérifier à chaque itération que le type de la variable $i est correct.

J'ecris pas de PHP au quotidien. (Et j'en ait probablement pas ecrit dans les 10 dernieres annees.) Pourquoi l'interpreteur doit reverifier le type de i a chaque tour de boucle?

si i est un int alors apres i++ c'est toujours un int. Pourquoi est ce que l'interpreteur a besoin de verifier a nouveau? Si tu connais tous les types a une etape, tu peux inferer tous les types a l'etape d'apres. C'est comme ca que tous les langages type sont ecrit (c'est comme ca qu'ils font la verification de type a la compilation par exemple.)
Y a t'il quelque chose dans la construction du langage PHP qui fait que ce n'est pas possible?

Le 21 mai 2022 à 16:52:39 :
J'ecris pas de PHP au quotidien. (Et j'en ait probablement pas ecrit dans les 10 dernieres annees.) Pourquoi l'interpreteur doit reverifier le type de i a chaque tour de boucle?

si i est un int alors apres i++ c'est toujours un int. Pourquoi est ce que l'interpreteur a besoin de verifier a nouveau? Si tu connais tous les types a une etape, tu peux inferer tous les types a l'etape d'apres. C'est comme ca que tous les langages type sont ecrit (c'est comme ca qu'ils font la verification de type a la compilation par exemple.)
Y a t'il quelque chose dans la construction du langage PHP qui fait que ce n'est pas possible?

Tu codes en quoi toi godrik ? Tu aimes quel langage ? Je te lis souvent sur le forum Linux au passage.

Sinon, parce que $i pourrait être réassigné avec un autre type au milieu de la boucle. PHP vérifie les types pendant le runtime.

Donc si tu fais :

function myFunction(int $myNumber) {
    $myNumber = "my string"; // correct
}

$myNumber = 42;

$myNumber = "my string"; // correct

myFunction($myNumber); // error

Le code va planter au moment de l'exécution. PHP ne fait pas d'analyses statiques de code. C'est plus des contraintes de types au moment de l'exécution (pendant les appels et les retours de fonctions). Et si on ajoutait le typage sur les variables, on devrait vérifier à chaque fois qu'une variable est réassignée que le type est correcte, et ça tuerait les performances.

C'est compliqué à expliquer.

Le 21 mai 2022 à 17:23:28 :

Le 21 mai 2022 à 16:52:39 :
J'ecris pas de PHP au quotidien. (Et j'en ait probablement pas ecrit dans les 10 dernieres annees.) Pourquoi l'interpreteur doit reverifier le type de i a chaque tour de boucle?

si i est un int alors apres i++ c'est toujours un int. Pourquoi est ce que l'interpreteur a besoin de verifier a nouveau? Si tu connais tous les types a une etape, tu peux inferer tous les types a l'etape d'apres. C'est comme ca que tous les langages type sont ecrit (c'est comme ca qu'ils font la verification de type a la compilation par exemple.)
Y a t'il quelque chose dans la construction du langage PHP qui fait que ce n'est pas possible?

Tu codes en quoi toi godrik ? Tu aimes quel langage ? Je te lis souvent sur le forum Linux au passage.

Je programme principalement du C++. Occasionellement en Java et en Python. Rarement en Javascript.

Sinon, parce que $i pourrait être réassigné avec un autre type au milieu de la boucle. PHP vérifie les types pendant le runtime.

Non, ca ne devrait pas etre possible ca. Parceque ca devrait faire une erreur au moment ou la variable est alloue un type inconnue.

Reprenons ton code. Je vais annote le comportement que tu voudrais avoir. Note que je ne sais pas si PHP a ete specifie comme ca

function myFunction(int $myNumber) {
     $myNumber = "my string"; // correct
}
 
$myNumber = 42; //myNumber n'est pas type par le langage donc c'est correct
 
$myNumber = "my string"; // myNumber n'est pas type par le langage donc c'est correct
 
myFunction($myNumber); // error au runtime, le type de myNumber etant inconnu, le langage doit verifier que c'est un int pour pouvoir le passe comme parametre

Mais ce que tu veux comme comportement est:

function myFunction(int $myNumber) {
     $myNumber = "my string"; // correct
}
 
int $myNumber = 42; //myNumber a un type force par le programmeur
 
$myNumber = "my string"; // Ici on a une erreur de de l'interpreteur qui n'est pas une erreur de runtime.
 
myFunction($myNumber); //Cette ligne ne causerai pas de verification de type parceque l'on sait que myNumber est un int. Naturellment, cette ligne n'est jamais execute

PHP pourrait faire de l'analyse statique du code. Il n'y a absolument rien dans la specification du langage qui empeche l'analyse statique. D'ailleurs il y a des compilateurs PHP qui certainement analyse le code statiquement. Apres c'est possible que l'interpreteur standard PHP ne fasse pas ca.

Dans l'interpreteur php 7.4.25, on peut faire:

function f (int $something) {

	 $something = "bla";

	 print ($something);
	 print ("\n");

}

$foo = 12;

f($foo);

Ce qui m'a l'air d'etre juste une mauvaise specification du langage.

Cool pour le C++

Je suis d'accord avec ton cheminement, mais PHP ne fonctionne pas comme ça hélas. C'est du typage faible/dynamique en gros, avec des contraintes de types (optionnelles) seulement sur les entrées et sorties des fonctions.

Oui, il faudrait faire de l'analyse statique du code, mais le problème c'est que PHP est un langage sans état, comme un script bash, c'est à dire que quand tu charges ta page PHP, le script est exécuté chaque fois depuis le début, donc imagine l'impact sur les performance, si à chaque fois que tu vas sur une page web écrite en PHP, il doit faire de l'analyse statique du code avant de renvoyer la page (même si il y a déjà des solutions de caches d'op-codes).

La solution effectivement ce serait de faire les vérifications de types seulement dans un build step avant de mettre les fichiers sur le serveur, mais alors on perdrait la côté scripté de PHP où tu écris ton fichier PHP et tu le mets sur ton serveur. Je pense néanmoins qu'on ira vers ça dans le futur.

Le langage part de loin, mais il évolue très vite. Ce qui est intéressant, c'est que ce langage a été tellement moqué, que maintenant on est dans une sorte de surcompensation où la team PHP essaie de l'améliorer à chaque version (contrairement à Python qui stagne un peu par exemple). PHP est beaucoup plus rapide que Ruby et Python, ce qui est assez incroyable, même si on est loin des performances des langages compilés.

Oui, il faudrait faire de l'analyse statique du code, mais le problème c'est que PHP est un langage sans état, comme un script bash, c'est à dire que quand tu charges ta page PHP, le script est exécuté chaque fois depuis le début, donc imagine l'impact sur les performance, si à chaque fois que tu vas sur une page web écrite en PHP, il doit faire de l'analyse statique du code avant de renvoyer la page (même si il y a déjà des solutions de caches d'op-codes).

Ca c'est un probleme d'implementation et pas de specification du langage je pense. Tu pourrais compiler le langage ou faire du JIT. D'ailleurs il y a des implementations qui font exactement ca.

La solution effectivement ce serait de faire les vérifications de types seulement dans un build step avant de mettre les fichiers sur le serveur, mais alors on perdrait la côté scripté de PHP où tu écris ton fichier PHP et tu le mets sur ton serveur. Je pense néanmoins qu'on ira vers ça dans le futur.

Tu pourrais faire cette etape de "build step" dans le serveur directement au premier chargement du fichier. C'est ce que font les machine virtuelle java et c#.

Le langage part de loin, mais il évolue très vite. Ce qui est intéressant, c'est que ce langage a été tellement moqué, que maintenant on est dans une sorte de surcompensation où la team PHP essaie de l'améliorer à chaque version (contrairement à Python qui stagne un peu par exemple). PHP est beaucoup plus rapide que Ruby et Python, ce qui est assez incroyable, même si on est loin des performances des langages compilés.

Les gens commencent a regarde Julia. A peu de chose pres, c'est "python, mais fait correctement". Le systeme de type en Julia est relativement bien foutu. Basiquement si tu declares une variable avec un type alors le type est verifier strictement. Et si tu declare une variable sans type alors le type est variant. Tu n'a de la verification de type que quand tu passe d'une variable variant a une variable type strictement.
Ca permet d'executer du code Julia dans LLVM avec des performances decente.

Le 21 mai 2022 à 18:28:05 :
Les gens commencent a regarde Julia. A peu de chose pres, c'est "python, mais fait correctement". Le systeme de type en Julia est relativement bien foutu. Basiquement si tu declares une variable avec un type alors le type est verifier strictement. Et si tu declare une variable sans type alors le type est variant. Tu n'a de la verification de type que quand tu passe d'une variable variant a une variable type strictement.
Ca permet d'executer du code Julia dans LLVM avec des performances decente.

J'ai regardé rapidement la documentation, oui le langage, la synthaxe, c'est très joli esthétiquement.

C'est un langage plutôt orienté mathématiques si je comprends bien ?

Il y a plein de langage typé qui font ça au pire tu fais le check à la compilation pas au runtime, c'est ce que fait typescript par exemple (si on peut parler de compilation).
Je tombe rarement sur des personnes contre ce genre d'initiative, certes ton codes doit être un peu plus verbeux, mais ça aide à l'autocomplétions et éviter de faire des erreurs, au finale tu gagnes du temps de dev.

Julia c'est sympa pour faire des tâches CPU bound, mais j'ai du mal à voir une API REST faites en Julia. Ça a pas encore l'air hyper mature de ce côté là d'ailleurs.

Sinon pour Godrick : au taf on utilise python avec des linters (pylint, flake8) + des vérificateurs de types. La pipeline CICD passe pas tant que ces outils raisent des warnings. Ça évite pas mal la surcharge cognitive du développement en python, la vérification statique des types via MyPy marche plutôt bien.