La version 8 de PHP est sortie le 26 novembre 2020, nous allons donc voir ensemble les nouvelles fonctionnalités qui ont été intégrées dans cette version.
Pour ne pas faire trop long, on se limitera aux choses nouvelles par rapport à PHP 7.4, et on regardera les nouvelles fonctionnalités principales, pour une liste exhaustive consultez le journal des modifications officiel.
Sommaire
Nouvelles fonctionnalités
Syntaxe
Les unions de types
PHP continue sa route vers un langage fortement typé, en ajoutant le support des unions de types dans les spécificateurs de type de paramètres, de variables ou de retour de fonction.
L’exemple de la RFC :
class Number {
private int|float $number;
public function setNumber(int|float $number): void {
$this->number = $number;
}
public function getNumber(): int|float {
return $this->number;
}
}Cela permet de mettre des informations de type à des endroits où l’on ne pouvait pas en mettre, lorsque plusieurs types différents sont acceptés ou retournés.
Type « mixed »
Toujours à propos des types, le type mixed a été ajouté (cf. RFC). Il indique qu’une variable peut être de n’importe quel type pris en charge par PHP.
Ça peut sembler idiot puisque ça revient au même que de ne pas mettre d’indication de type, mais ça permet au développeur de l’indiquer explicitement, et il existe de nombreux cas de figure où il est tout à fait normal d’accepter tous les types (pour une fonction de sérialisation, par exemple). Cela peut aussi servir à indiquer qu’une fonction doit retourner quelque chose, c’est donc le contraire de :void qui indique l’absence de retour.
Aussi le mot-clé mixed était déjà largement utilisé dans la documentation de PHP.
Type de retour « static »
Puisqu’on parle de typage, il est maintenant possible d’indiquer « static » comme type de retour pour une méthode. Cela signifie qu’elle renvoie une instance de la classe sur laquelle la méthode est appelée. À noter qu’il existait déjà le type de retour « self » pour indiquer qu’une méthode renvoie une instance de la classe à laquelle elle appartient, ce qui n’est pas la même chose. Voir la notion PHP de « late static binding » [RFC].
Exemple :
class Test {
public function create(): static {
return new static();
}
}Les attributs
Largement la plus grosse source de débats internes pour cette version, les attributs ont fait leur apparition.
Un attribut, parfois appelé annotation dans d’autres langages, est une métadonnée qui peut être ajoutée sur une fonction, une classe, un paramètre, une propriété… Cette métadonnée est ensuite disponible par réflexion.
Après être passée par <<Attribute>> et @@Attribute, c’est finalement la syntaxe #[Attribute] qui a été choisie au bout de quatre RFC, syntaxe déjà utilisée par Rust. La notation @Attribute utilisée dans beaucoup d’autres langages n’était pas disponible, puisque l’opérateur @ existe déjà en PHP et sert à ignorer les erreurs.
RFC :
Les paramètres nommés
Un autre gros morceau de cette version est la prise en charge des paramètres nommés, ce qui signifie qu’il est possible d’indiquer la valeur d’un paramètre de fonction par son nom plutôt que par sa position.
Exemples tirés de la RFC :
htmlspecialchars($string, double_encode: false);
// Au lieu de
htmlspecialchars($string, ENT_COMPAT | ENT_HTML401, 'UTF-8', false);
array_fill(start_index: 0, num: 100, value: 50);
// Au lieu de
array_fill(0, 100, 50);
// L’ordre n’est plus important, cette version est équivalente
array_fill(value: 50, num: 100, start_index: 0);Ce changement signifie que les noms des paramètres font maintenant partie de la signature des fonctions, et que renommer un paramètre de fonction peut casser du code qui utilise la fonction. Pour cette raison un gros travail d’amélioration et d’uniformisation des noms de paramètres a été fait pour PHP 8, et dans les versions suivantes un renommage sera considéré comme cassant la compatibilité descendante [RFC].
La promotion de paramètres constructeurs
Dans le but de simplifier l’écriture de classes simples servant simplement de schéma pour des objets contenant des données, et pour encourager leur utilisation plutôt que celle de tableaux, il est maintenant possible de déclarer les propriétés d’une classe directement dans les paramètres du constructeur, afin de ne pas avoir à les écrire deux fois [RFC].
Exemple :
// Avant
class Point {
public float $x;
public float $y;
public float $z;
public function __construct(
float $x = 0.0,
float $y = 0.0,
float $z = 0.0,
) {
$this->x = $x;
$this->y = $y;
$this->z = $z;
}
}
// En PHP>=8.0
class Point {
public function __construct(
public float $x = 0.0,
public float $y = 0.0,
public float $z = 0.0,
) {}
}À noter que cette nouveauté se marie particulièrement bien avec les paramètres nommés :
class Circle {
public function __construct(
public float $x = 0.0,
public float $y = 0.0,
public float $z = 0.0,
public float $r = 1.0,
public string $name = '',
public string $color = 'black',
) {}
}
$c1 = new Circle(x:12, y:13, r:5, name:'C1');Opérateur « nullsafe »
Un nouvel opérateur ?-> a été ajouté [RFC]. Il permet d’appeler une fonction ou de récupérer une propriété de l’objet contenu dans la variable sans déclencher d’erreur si la variable est nulle. Cela permet par exemple de chaîner les appels de fonctions en autorisant une valeur nulle à plusieurs endroits de la chaîne.
Exemple :
// Le code suivant
$country = null;
if ($session !== null) {
$user = $session->user;
if ($user !== null) {
$address = $user->getAddress();
if ($address !== null) {
$country = $address->country;
}
}
}
// Peut maintenant être écrit
$country = $session?->user?->getAddress()?->country;Mot‑clef « match »
Le mot‑clef match a été ajouté comme alternative au switch lorsque l’on cherche à retourner une valeur depuis chaque branche.
Exemple :
// Avec switch
switch ($mot) {
case 'un':
$nombre = 1;
break;
case 'deux':
$nombre = 2;
break;
case 'trois':
$nombre = 3;
break;
default:
throw new Exception ('Mot invalide');
break;
}
// Avec match
$nombre = match ($mot) {
'un' => 1,
'deux' => 2,
'trois' => 3,
default => throw new Exception ('Mot invalide'),
};Lisez attentivement la RFC pour la liste des subtiles différences avec switch.
Nouvelles classes et interfaces
La classe WeakMap a été ajoutée. Elle permet de gérer des correspondances avec des objets en clefs, qui n’empêchent pas ces objets d’être détruits par le ramasse‑miettes. Quand un objet est détruit, la valeur qui lui est associée est simplement retirée de la WeakMap [RFC].
Une nouvelle classe ValueError est lancée quand une méthode reçoit un paramètre du bon type mais avec une valeur inappropriée, pour différencier du cas des TypeError, qui apparaissent quand le paramètre n’a pas le bon type.
Une nouvelle interface Stringable permet de reconnaître les objets qui peuvent être transtypés en string.
Elle est automatiquement implémentée par les classes qui définissent la méthode magique __toString().
Cela permet, avec l’union des types, d’utiliser le groupe string|Stringable pour typer un paramètre qui accepte soit une chaîne de caractères, soit n’importe quel objet qui peut se transtyper en chaîne de caractères [RFC].
Autres nouveautés
- il est maintenant possible d’obtenir le nom de la classe d’un objet en utilisant
$object::class, le résultat est le même queget_class($object)[RFC] ; -
newetinstanceofpeuvent maintenant être utilisés avec des expressions arbitraires, sous la formenew (expression)(...$args)et$obj instanceof (expression)[RFC] ; - des changements ont été faits pour rendre la syntaxe des variables plus cohérentes, par exemple il est maintenant autorisé d’écrire
Foo::BAR::$baz[RFC] ; - les traits peuvent maintenant définir des méthodes privées [RFC] ;
-
throwpeut désormais être utilisé comme une expression [RFC] ; - une virgule supplémentaire est autorisée à la fin des listes de paramètres, pour faciliter les choses quand on écrit un paramètre par ligne (notamment pour mieux versionner dans ces cas‑là) [RFC] ;
- il est maintenant possible d’écrire
catch (Exception)pour capturer une exception sans la stocker dans une variable [RFC] ; - les méthodes privées déclarées sur une classe parente ne contraignent plus la signature des méthodes sur la classe fille (à l’exception des constructeurs finals privés) [RFC] ;
-
un nombre variable de paramètres de méthode peut maintenant être remplacé par un paramètre variadique lors de l’héritage, tant que les types sont compatibles ; ceci est par exemple possible :
class A { public function method(int $many, string $parameters, $here) {} } class B extends A { public function method(...$everything) {} }
Bibliothèque standard
printf()
Les fonctions de la famille printf() supportent maintenant les spécificateurs de format %h et %H. Ils font pareil que %g et %G mais utilisent toujours le point comme séparateur des décimales au lieu de se fier à la régionalisation (locale) configurée via LC_NUMERIC.
Il est également maintenant possible d’utiliser * comme largeur de champ ou précision de flottant, auquel cas la largeur/précision est passée comme argument à la fonction. Passer -1 comme précision pour %g, %G, %h et %H permet de reproduire le comportement par défaut de PHP pour les flottants :
printf("%.*H", (int) ini_get("precision"), $float);
printf("%.*H", (int) ini_get("serialize_precision"), $float);proc_open()
La fonction proc_open() gère maintenant des descripteurs de pseudo‑terminal (PTY) ; l’exemple suivant attache stdin, stdout et stderr au même PTY :
$proc = proc_open($command, [['pty'], ['pty'], ['pty']], $pipes);proc_open() gère maintenant les sockets. L’exemple suivant attache des sockets distincts pour stdin, stdout et stderr :
$proc = proc_open($command, [['socket'], ['socket'], ['socket']], $pipes);Contrairement aux tubes (pipes), les sockets n’ont pas de problèmes de blocage d’entrées‑sorties sous Windows. Cependant, tous les programmes ne fonctionnent pas forcément correctement avec des sockets.
Fonctions de tri
Les différentes fonctions de tri sont maintenant stables, ce qui signifie que les éléments qui sont égaux selon la fonction de comparaison conservent maintenant leur ordre relatif d’avant le tri. Il y a un léger coût en performances mais cela peut éviter les mauvaises surprises [RFC].
Nouvelles fonctions sur les chaînes de caractères
Les fonctions str_contains(), str_starts_with() et str_ends_with() ont été ajoutées, permettant de déterminer respectivement si une chaîne de caractères contient, commence par et finit par une autre chaîne. Ce sont des opérations très courantes, et s’il n’était pas difficile de les implémenter en PHP, le fait qu’il y ait plusieurs façons de faire pouvait perturber les développeurs.
RFC :
Opérations sur les tableaux
Les fonctions array_diff(), array_intersect() et leurs variations peuvent maintenant être utilisées avec un seul tableau en paramètre. Cela facilite leur utilisation avec l’opérateur ... :
// Fonctionne même si $excludes est vide
array_diff($array, ...$excludes);
// Fonctionne même si $arrays contient un seul tableau
array_intersect(...$arrays);Extensions
Hash
Les objets HashContext peuvent maintenant être sérialisés.
OpenSSL
Ajout du prise en charge de la RFC 5652, « Cryptographic Message Syntax (CMS) », avec des fonctions pour chiffrement, déchiffrement, signature, vérification et lecture. L’API est similaire à celle pour PKCS#7 avec l’ajout de nouvelles constantes : OPENSSL_ENCODING_DER, OPENSSL_ENCODING_SMIME et OPENSSL_ENCODING_PEM.
Performances
JIT
Un compilateur à la volée (JIT — Just In Time) a été ajouté dans PHP afin de permettre, dans certains cas, d’augmenter les performances. La fonctionnalité est désactivée par défaut et n’apporte pas grand’chose dans le cadre d’application Web classiques. En revanche, pour des usages plus gourmands en calcul, par exemple un calcul de fractal qui a été utilisé pour les démos, le compilateur à la volée apporte un gain de performance très important. L’idée est donc de rendre PHP plus viable pour des usages pour lesquels il était trop lent auparavant.
Aller plus loin
- Article anglophone plus complet sur les nouveautés (28 clics)
- Annonce officielle (13 clics)
- Journal des modifications détaillé (12 clics)
- Guide de migration (20 clics)
# Des bonnes idées
Posté par raphj . Évalué à 10. Dernière modification le 29 novembre 2020 à 00:03.
Finalement, j'ai l'impression qu'il y a une tendance un peu commune, en tout cas dans les langages de scripts répandus, notamment sur des notations de types de plus en plus utiles et puissantes, qui dépassent (enfin ?) ce que permet le C (pas tant de choses que ça finalement), et notamment en permettant les unions. Et c'est bien que ces langages de script répandus intègrent ça, parce que c'est rapidement inconfortable dans un gros projet de ne pas les avoir. Les gens qui s'occupent de ces langages en ont conscience et le montrent (enfin !).
Aussi, j'ai l'impression que PHP reprend des bonnes idées d'autres langages : les paramètres nommés de Python, le startsWith / endsWidth de Java / Javascript, le WeakMap et l'opérateur de chainage de Javascript, les notations de types de mypy / Typescript, le match venant des langages fonctionnels et récemment adopté par Python, bien plus lisible, adapté, clair, concis et moins casse gueule qu'un switch dans beaucoup de situations. Je salue aussi les paramètres constructeurs, je trouve les langages orientés objets tellement ennuyeux et lourdauds sans…
Une petite mention pour la possibilité d'utiliser
mixed, ça m'avait manqué quand j'avais essayé d'utiliser les annotations de types en PHP.Bref, ces petits changements qui améliorent la vie ces derniers temps dans les langages de programmations répandus, même si je n'utilise pas PHP tous les jours, m'enthousiasment pas mal, et franchement, je ne sais pas pour vous, mais chaque nouvelle version de PHP semble arriver avec son lot de bonnes surprises, de bons choix et le langage semble évoluer vite.
Finalement, PHP deviendrait presque plus sérieux et agréable que Javascript, pourtant il y avait du chemin : il a un match, des paramètres nommés, des notations de types (accessibles uniquement dans les projets qui ont décidés de passer à Typescript) !
C'est un langage qui continue à exceller dans son rôle original de moteur de templates HTML facile à déployer (quel bonheur de ne pas devoir configurer et démarrer un service par application et de pouvoir laisser le serveur HTTP gérer les URLs - que ce soit en tant que développeur ou utilisateur - un plaisir pour la maintenance d'un service), avec de plus en plus tous les outils qu'on trouve dans les langages de programmation modernes. Franchement, ça donne envie de s'y remettre.
Prochaine étape : la gestion de l'ownership / du borrowing dans les langages de scripts répandus !
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 2.
Oui et non car plein de concepts ont 10 à 20 ans dans d'autres langages.
Ces typages sur des langages interprétés ont tendance plus à m'agacer : ça encourage des boites à continuer à faire de l'interprété plutôt que du compilé alors que c'est de la poudre aux yeux : tout ce fait à l’exécution et non en amont et finalement si on veut vérifier du typage avant la mise en prod, on s'appuie sur l'IDE (c'est pas son rôle à mon sens) et des tests.
Perso, quand je m'oriente sur des petits projets, des POC ou des scripts en one shot, j'aime bien passé par de l’interprété car ça me permet de faire vite.
Rajouter des infos de typage, c'est justement contre-productif dans ce cadre.
Si en revanche, je pars sur des projets plus complexes, je choisi du compilé et du typage fort (PHP en est encore loin et Typescript est bien meilleur).
Je ne vois qu'un intérêt aux améliorations de PHP : améliorer la qualité de produits qui ne peuvent pas changer de techno rapidement.
J'épiloguerais pas sur les choix de rétro-compatibilité qui font plus de mal que de bien, la syntaxe juste imbuvable quand on a connu d'autres choses, l'incapacité de faire de l'asynchrone, de faire autre chose que du web etc.
PHP aurait du s'arrêter à la version 3 sans objets : ça restait un langage de template pour faire des petits sites amateurs sans prétention.
Bref, dans tous les autres cas, changez de langage.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 8.
Comment ça ? En Python par exemple, les annotations de types sont ignorées à l'exécution, et on peut lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?
J'ai connu d'autres choses et d'autres langages, et ce n'est pas mon sentiment. Mais ne nous arrêtons pas à des sentiments et constatons : tout porte à croire que Facebook, Wordpress, Wikipedia, Nextcloud, et plein d'autres projets continuent à bien évoluer malgré (grâce à ?) PHP. On est loin du site amateur ! Ces projets auraient-ils dû choisir un autre langage ?
Je ne comprends pas cette haine contre PHP. Malgré ses défauts (il en a plein), il permet de construire à la fois facilement des sites amateurs et de faire tourner certains des sites les plus visités du monde, ce n'est quand même pas rien.
Et si Wikipedia (2001) et Wordpress (2003) existent depuis longtemps et changer de langage pourrait être difficile pour ces projets, Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement et ownCloud, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).
Rejeter ce langage d'un revers de manche parait un peu réducteur.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 1.
De l'analyse statique c'est toujours réalisable, en effet mais je doute que beaucoup le face au final.
Dans un langage compilé, c'est juste imposé.
Pas de haine, un désintérêt abyssal.
De mon côté, je ne comprend pas pourquoi on ne laisse pas mourir une techno.
Le passage de PHP 5 à 7 a été très compliqué et je ne comprend pas cet acharnement de mobiliser des core dev à reproduire des choses qui existent depuis moultes dans d'autres technos et d'essayé d'être rétro-compatible.
(Python que tu cites à fait un choix plus sain à mon sens en dépréciant plein de choses avec Python 3)
Blague à part : vu que le PHP des début ne ressemble à presque plus rien de ce qu'il est actuellement… je serais au commande, je ferais évoluer PHP pour que ça soit 100% compatible Python3 à la version 10. Comme ça au moins, l'affaire serait bouclé.
Depuis que le web c'est orienté "framework", API, microservices et "app" plutôt que "site", je n'ai pas compris l'intérêt de poursuivre avec PHP : l'effort pour migrer un gros site/applicatif d'un PHP natif vers du Symphony/Laravel mobilise autant d'énergie que de changer de langage.
Les projets que tu mentionnes existent depuis longtemps et le choix de PHP a leur début était bien plus logique que maintenant. Une migration semble désormais délicate (mais pas impossible).
Wordpress et Facebook sont pour moi moribond (même si PHP est loin d'en être la cause) donc ils ont pas vraiment de poids dans la balance.
Autant pour du legacy je peux comprendre qu'on maintienne un langage, autant pour des nouveaux projets, je n'identifie pas l'engouement.
Ben, justement, il existe tant de langages avec des bases tellement plus en adéquation avec les problématiques de notre époque ou future.
C'est triste à dire mais rien autours de PHP ne m'évoque l'avenir.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 4.
Je n'espère pas, mon code PHP d'il y a 10 ans tourne sans modification sur les dernières versions de PHP, pour faire du Python, j'ai déjà… Python :-)
[^] # Re: Des bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Je n'ai quasiment rien modifié dans les applis PHP que je maintiens. Je ne vois pas en quoi le passage de PHP 5 à 7 a été compliqué.
Les améliorations qu'il y a eu dans PHP 7 et PHP 8 au niveau syntaxe, n'introduit pas des incompatibilités avec les versions précédentes. Ce sont des ajouts. Tu n'es pas obligé d'utiliser toutes ces nouveautés syntaxiques.
Ces modifications peuvent se faire lors de refactorisations de code ou lors d'ajout de code par exemple. Mais ce n'est pas une obligation.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -2.
Je parlais plus de l’émergence d'une version 7 : on a quand même eu une période très longue entre les 2 avec une version 6 avorté.
Tout le monde n'a pas été aussi chanceux.
Ça me fait toujours sourire cette entorse à Semver : Version majeur mais sans breaking changes.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
D'où tu tire qu'ils utilisent semver ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -2. Dernière modification le 30 novembre 2020 à 17:17.
Ben, quand on utilise des notations du genre "7.4.0 beta 1", pour moi on fait du semver.
Après, si c'est à moitié respecté, j'aurais tendance à dire qu'ils font de l'amateurisme.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Donc par exemple, linux c'est de l'amateurisme selon toi ? Ou gcc par exemple ? Gnome ? Comme gimp d'ailleurs.
Le versionning de TeX et de LaTeX, pour toi ça se classe où par exemple ?
Le sémantique versionning est très utilisé, mais il faut pas être obtus. Déjà il est arrivé après la notation mais il y a d'autres équipes qui font autrement je ne vois pas en quoi c'est de l'amateurisme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Comme dis plus bas, PHP respecte Semver et l'inverse m'aurait étonné donc y'a pas vraiment de débat.
Je sais bien que des projets qui ont une visibilité hors dev ce permettent d'incrémenter la version principal sans bc : Linux depuis pas si longtemps, Firefox, Gnome etc.
C'est des schémas assumés car dans leur cadre, ils déprécient peu de choses.
Gimp et Gcc sont Semver compliant.
Latex a fait le choix de ne pas s'appuyer sur Semver donc c'est délibéré.
Bien pour le coup, je reste obtus : Semver est volontairement simple, accessible et compréhensible. C'est une règle commune à tellement de projets que je trouve vraiment dangereux de s'y soustraire. Sois tu respectes, soit tu respectes pas mais tu fais pas à moitié. (personne ne viendrait à faire des mesures en mélangeant des mètres et des pieds)
[^] # Re: Des bonnes idées
Posté par wismerhill . Évalué à 5.
En tout cas pas les gens sérieux
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
héhé, le bug qui coûtent très cher.
[^] # Re: Des bonnes idées
Posté par wismerhill . Évalué à 2.
Il y en a, toute une série de choses (en particulier de vieilles extensions) qui étaient dépréciées dans PHP 7 ont été retirées.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 1.
donc ceci n'est pas vrai :
[^] # Re: Des bonnes idées
Posté par wismerhill . Évalué à 2.
Tout à fait.
D'ailleurs la page de la documentation qui liste les changements incompatibles est assez longue:
https://www.php.net/manual/en/migration80.incompatible.php
(mais la plupart sont des points de détail)
[^] # Re: Des bonnes idées
Posté par Raphaël G. (site web personnel) . Évalué à 2.
L'api interne entre php5 et php7 n'est pas compatible et demande de gros changements comme passer une majorité de paramètres par référence, des macros qui changent, etc…
Pour porter une vieille extension pour php7, c'est juste une galère, faut que je m'y remette d'ailleurs.
Autant la documentation utilisateur final php est un modèle sur lequel tous les autres langages pourraient copier les yeux fermés.
Pour ce qui est de la documentation de l'api interne, c'est franchement ni fait, ni à faire.
Pour trouver des informations sur certains fonctionnalités tu dois parfois dégainer archives.org ou le cache d'un moteur de recherche.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 8. Dernière modification le 30 novembre 2020 à 06:27.
Ils ont tout de même :
Je ne suis pas très à jours, mais aux dernières nouvelles que j'ai vu Facebook ne fais plus de php, mais uniquement du hack.
C'est les travaux de Facebook qui ont précipité la mort de php 6 et le travail de php 7 quasiment uniquement orienté vers la performance.
OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 3. Dernière modification le 30 novembre 2020 à 07:21.
Oui, beaucoup d'efforts pour "rester" sur PHP (ou un truc qui en est proche) ;-).
Peut-être que c'est parce qu'à ce moment là, la quantité de code PHP devenait trop grande pour migrer cela dit.
Bon point !
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 1.
Oui, et c'est parce que certains softs sont fait en PHP que les hébergeurs ne font aucun effort : le serpent qui se mort la queue.
J'espère franchement que la mode des conteneurs va faire sauter ce verrou : ça permettra de mettre tout le monde sur un pied d'égalité.
Blague : Owncloud pouvait le faire en Haskell et transpiller en PHP
[^] # Re: Des bonnes idées
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Chez Gandi, tu peux faire du js, du Python et du Ruby. Certes il manque un bon langage, mais il y a autre chose que PHP.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Tu t'appuis sur de l'analyse statique. La lancer dans une étape du build, sur ton ide, en pre-commit, en pre-push ou quand tu feux ça ne change pas grand chose.
Reprocher que ça n'est pas forcément exécuter c'est comme disqualifier les tests parce que rien ne t'oblige à les lancer. La plus part des projets utilisent des analyseurs statistiques aussi car ils en ont besoin.
PHP comme tous les langages est compilé mais compilé au runtime, ce qui signifie que le moindre run vérifie toute la sémantique de type tant que tu ne t'appuis pas trop sur du typage dynamique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -3.
Ben, voilà : t'as bien résumé ce que je reproche.
Vous voulez de la perf mais aussi vérifier des trucs au runtime et être interprété : on tente de résoudre la quadrature du cercle.
[^] # Re: Des bonnes idées
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 30 novembre 2020 à 08:25.
Alors, pour PHP je ne sais pas, mais pour info, Python est un langage compilé vers une machine virtuelle, comme Java. Il en est de même pour Perl, il me semble. PHP, je ne sais pas.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Je crois que c'est aussi le cas si tu utilise php-fpm il me semble.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Si on rentre dans les détails, ça peu effectivement paraitre plus flou.
Néanmoins, pour obtenir ce bytecode, on doit exécuter une première fois Python ou le lancer dans un build.
Et puis bon, les vérifs faites sont clairement très superficiels.(ce qui n'est pas forcément un mal)
Mais comme dis, ça dépend de la typologie du projet : pour plein de choses, Python me convient très bien mais je désapprouve toute tentative de le rendre plus typé car on risque de perdre ses plus grand atouts : simplicité, rapidité, lisibilité.
[^] # Re: Des bonnes idées
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
PHP utilise un OpCache, c'est pas du compilé bytecode, mais ça se rapproche un peu.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Des bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
En PHP, tu n'es pas obligé de les utiliser. Toutes les nouveautés syntaxiques sont des ajouts et sont optionnels.
Donc tu peux continuer à utiliser PHP comme en version 3 pour un langage de template, il n'y a pas de souci (enfin presque, les constructeurs des classes ne peuvent plus avoir le nom de la classe et doivent s'appeler
__construct, mais à part ça…).s/peuvent/veulent. Sérieux, pourquoi faudrait-il absolument passer à une autre techno ? Que sais-tu des besoins et envies des développeurs sur ces projets en PHP, surtout pour les projets internes ?
Si un langage satisfait les objectifs de l'application, aucune raison de changer. On choisi un langage selon l'application. Pas l'inverse. Ce n'est pas à toi de décider qu'il faudrait arrêter PHP, tout ça parce que tu n'aimes pas ce langage. C'est totalement absurde.
Totalement subjectif. Question de goût.
Mouai, ça montre surtout que tu ne connais pas bien l'éco-système PHP, et qu'au final, tu perd toute crédibilité dans tes conclusions.
On peut faire plein d'autres choses que du web. J'ai des workers en PHP dans une infra qui commence à être conséquente (des dizaines de VM) : aucun souci (pas de plantages, pas de problème mémoire.. rien). Avec ReactPHP, tu peux faire de l'asynchrone. Etc..
[^] # Re: Des bonnes idées
Posté par windu.2b . Évalué à 3.
Il me semble que la POO n'est arrivée qu'avec PHP 4 (ce que tu décris aurait donc eu lieu lors du passage à PHP 5.0)…
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -3.
Pour avoir bossé dans plusieurs boites avec plusieurs technos et des devs avec des niveaux différents, je dirais qu'un dev qui va promouvoir PHP est un dev qui n'a eu que très peu d'autres expériences de langages (ou alors sur des trucs tellement plus archaïque qu'il n'est pas vraiment objectif).
Dire le contraire c'est ce voiler la face.
Peu importe l'application, y'a des constantes : la fiabilité, la productivité et la performance sont présent pour n'importe quoi. C'est le pourcentage entre chaque qui change et le degré d'exigence.
Sur la fiabilité, je pense que les bugs critiques (erreur 500) ne plaisent à personne.
Sur des gros projets, tu dois pouvoir faire des modifs, du refactoring sans connaitre le code dans sa globalité, avoir toutes les connaissances métiers et sans avoir forcément une couverture de tests de malade et également travailler avec des personnes qui ont des niveaux variables (le mec qu'à 20 ans d'expériences en PHP va sans doute réussir à faire pas trop mal parce qu'il aura anticipé une bonne partie des faiblesses du langage)
PHP n'ai franchement pas taillé pour ça.
Le goût, ça s'affine.
Non, je ne connais pas bien car comme dis et du peu que je regarde, c'est que du réchauffé. On fait des trucs déjà existant depuis longtemps dans la techno qu'on connait bien mais pas ou peu d'innovations.
Quand j'ai été en relation avec des devs PHP "expérimentés" à chaque fois qu'on évoquais certains points (genre l'asynchronisme) c'était "on peut" et une fois dans les faits : "ben, c'est compliqué, tu comprends, y'a du legacy…"
Soit ils étaient tous nulles soit y'a anguille sous roche.
Mais pourquoi s'infliger ça !
Quand je bricole, je fais pas tout au marteau même si c'est possible.
Pourquoi prolonger la vie d'un truc qui s’essouffle ?
Justement, avec les VM/containers, une archi orienté micro-services, on peut varier les plaisirs.
Donc c'est pas natif et je sens la blague pour coupler ça avec des frameworks.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
C'est quoi ton problème ? Ta copine t'a trompé avec un développeur PHP au lycée ?
Pourquoi être aussi véhément ? Personne ne t'oblige à quoi que ce soit et les gens ont bien le droit d'utiliser les outils qui leur plais sans avoir à subir de regards noirs non ?
Tu dis toi même ne pas trop t'y intéresser c'est ton droit, mais pourquoi vouloir s'en prendre à PHP ? Soit tu t'y intéresse et tu peux donner des arguments soit tu troll comme là et ça te ridiculise plus que ça ne fait avancer ta cause.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par tisaac (Mastodon) . Évalué à 3.
Carton jaune !
On est pas loin de l'attaque ad hominem gratuite.
C'est assurément des suppositions fondées sur rien de factuel.
Cela ne fait pas avancer le débat.
Cela pourrait être pris comme violent.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 2. Dernière modification le 30 novembre 2020 à 21:46.
Je comprends la frustration et le dérapage de barmic, notre interlocuteur a quand même plus ou moins fait comprendre à tous les participants de ce fil de discussion, et à une partie de ses lecteurs, et de ses lectrices…
… qu'on était inexpérimentés / qu'on se voilait la face. Ce qui est peut-être vrai après tout mais bof. Comme communication bienveillante et ouverte, on a vu mieux et ça manque incroyablement d'humilité. Maintenant, même effectivement si elle m'a bien fait rire, cette remarque de barmic est déplacée et c'est bien d'avertir. Merci !
Globalement je pense qu'on peut arrêter ce débat ici, ça fait un moment qu'il est devenu stérile et ça commence sérieusement à tourner en boucle. Circulez, il n'y a plus rien à voir.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Bof, c'est pas un dérapage mais juste une blague pour moi.
C'est pas une atteinte perso, juste une constatation.
Je parle avec plein de devs et bon le sujet du "meilleur langage" (c'est des discussion de comptoirs donc effectivement c'est toujours un peu excessif) retombe souvent sur la table.
Néanmoins, y'a des trucs récurrents qui reviennent : Python, Scala, Haskell, Rust, TypeScript mais jamais PHP (pourtant, beaucoup d'eux l'utilise à titre pro).
Tous ne savent pas formaliser pourquoi mais le constat est là : personne n'attend rien de PHP et je ne pense pas que ça reste isolé à mon cercle de connaissance.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 3. Dernière modification le 30 novembre 2020 à 23:31.
Eh bien… regarde ici : on commente sur une dépêche dont 12 personnes ont participé à l'écriture, pertinentée par au moins 34 personnes en l'espace de 2 jours.
Peut-être que c'est mal vu / puni de montrer de l'intérêt pour PHP dans ton entourage alors les gens n'osent peut-être pas (franchement, perso, j'ai pas mal observé ça - par défaut quand tu lances une discussion sur PHP, on te fait comprendre que c'est nul, qu'il ne faut pas utiliser ça, X c'est mieux, etc (au moins parce qu'il est convenable de le faire) - sauf quand tu critiques négativement le langage, là tu gagnes du karma facilement - donc tu ignores ces remarques et parfois les gens t'écoutent quand même, ou alors c'est parfois juste plus simple de parler d'autre chose surtout quand tu connais plein d'autres trucs, en particulier des langages bien vus, sinon tu te tais, ça marche aussi ; selon les milieux, ça peut arriver avec Javascript aussi), ou gens n'ont effectivement pas d'intérêt, ou, simplement, les langages dont vous parlez sont plus récents, ou popularisent / rendent pratiques des concepts qui ne l'étaient pas avant ; quelque part, PHP c'est « ennuyeux », tout existe ailleurs alors pourquoi s'y attarder ?
Mais ici, c'est clair, il y a des gens qui montrent de l'intérêt et/ou de la curiosité pour PHP, y compris des gens qui connaissent, apprécient et pratiquent - parfois principalement - d'autres langages au quotidien, occasionnellement ou précédemment ; et des discussions intéressantes sur PHP peuvent avoir lieu :-)
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Ta véhémence ne doit pas beaucoup aider.
PHP, comme d'autres langages genre java. N'ont pas la hype. Mais il faut faire la part des choses entre la hype et ce qui est utilisé. Typescript et rust font énormément parler mais ça cache un biais. L'informatique, le développement c'est un énorme paquet de développeurs qui ne s'expriment pas ou pas dans ta langue ou pas là où tu va.
L'exemple le plus simple. Vu la com' on pourrait croire que react, angular et vue dominent le développement en navigateur alors qu'à eux 3 ils représentent 7% des sites web.
Certains des sites les plus visités au monde sont écris en PHP, la rivalité entre laravel et symphony crée une bonne dynamique,… Ça mérite un chouia plus de considération que de crier à tut tête qu'il faut l’abandonner surtout sans autre arguments que "je connais personne qui aime".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
J'essai de dissocier hype et réelles évolutions techniques.
A l'époque de la hype nodejs, je ne suis pas laissé embarqué parce que je considérais que c'était pour plein d'aspects un effet de mode sans réel fondement technique.
TypeScript et Rust ont a mon sens suffisamment d'arguments pour représenter le futur sans se cacher sous un effet de mode.
Les exemples sur les % de sites ne me paraissent pas pertinent.
C'est pas parce que le marché actuel est saturé d'une techno que ça veut dire qu'il ne faut pas changer.
Nginx a remplacé Apache alors que ce dernier était majoritaire par exemple.
Ça c'est opéré principalement pour des raisons techniques.
Après, on sait bien que derrière plein de boites, c'est pas vraiment l'aspect "technique" qui prime mais d'avantage l'aspect financier (et des investissements sur le court terme).
Ça explique (à mon sens) qu'il y ai autant de différence entre la demande du marché, les raisons objectives et les envies des développeurs.
Ces technos sont faites pour des web apps, pas vraiment des sites web. (par exemple, wikipédia, des sites vitrines en wordpress n'en ont a pas besoin)
Pleins de boites vont faire des apps webs sans que ça soit forcément visibles (intranet par exemple) donc ça représente une partie de l'iceberg.
Enfin, faudrait plus un indicateur sur les nouveaux sites et ceux refondus car le web a un peu d'histoire et effectivement tu remplaces pas 20 ans de vanilla JS/jquery par d'autres frameworks en un coup de baguette.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 3.
Il l'a surtout complémenté, dans beaucoup de cas. Il y a souvent Apache derrière Nginx.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Ce n'est pas ce que j'ai voulu dire. C'est leur publicité qui est un biais actuel. Comme go l'a eu avant et scala aussi par exemple. Ils ont une place, mais du fait de l'engouement qu'ils produisent ils sont surexposés. Ça contribue à leur créer une place d'ailleur (et c'est le cycle normal).
Il est question des parts de framework dans le navigateur dans le web publique, c'est bien explicité.
C'est forcément une inconnue, mais amha soit il y a encore plus de latence car moins d'investissement soit c'est du même ordre.
C'est pour ça que la démarche de l'almanach est annuelle, ils préparent la nouvelle version.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par nud . Évalué à 4.
Un langage de programmation et un serveur web ne sont pas comparables.
De la même façon qu'il y a toujours énormément de COBOL qui traine dans le monde financier, peu de boites sont prêtes à se faire un Netscape et tout réécrire leur code existant (en PHP) dans un autre langage. C'est une longue période sans vente et sans rentrée financière. Comme le langage n'est pas mort (pas comme COBOL) et que les développeurs qui peuvent travailler en PHP sont légion (comme Java), ces sociétés vont probablement continuer à faire leurs nouveaux projets en PHP.
PHP a de l'avenir, même si c'est seulement par inertie. C'est pas sexy, c'est ennuyeux, c'est peut-être moche mais ça fait la job.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Tu peux développer ?
Y'a des outils de parsing avec de l'AST qui permettent de convertir du COBOL en d'autres langages. Ca remplacera sans doute jamais une migration "humaine" au niveau "lisibilité mais ça marche sans bugs donc faute de mieux, c'est de plus en plus courant.
Y'a plein de moyens de faire des migrations sans se retrouver avec des période de gel de fonctionnalités :
De toute façon, des passages de versions qui peuvent être délicates, il faut en faire.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
C'est tellement un classique comme phrase qu'il y a très peu de chance. C'est de l'humour qui sert à exprimer qu'il faut se détendre. Le reste de mon commentaire l'explicite sans ambiguïté si c'était nécessaire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par Faya . Évalué à 3.
Je sais bien que "tu ne t'y intéresse pas" mais étant donné que tu tiens quand même à cracher dessus :
Donc non, aucune difficulté pour embarquer ReactPHP dans le framework de ton choix. D'ailleurs il est fourni sous forme de composants indépendants et indépendants (comme Symfony) donc tu peux sans soucis intégrer tout ou partie dans ton appli. Web ou CLI.
Et pour ne pas rester sur tant d'amertume, je profite également de ce commentaire pour rappeler d'autres outils bien pratiques de l'écosystème PHP :
var_dump.[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Je comprend pas trop la réponse :
C'est pas parce que c'est "simple" à installer avec un gestionnaire de dépendances tel que Composer que ça répond aux 2 pb soulevés :
1. une api (voir même de la syntaxe) pour faire de l'async nativement c'est pas la même chose que d'installer une lib (aussi bonne soit-elle)
2. c'est pas parce qu'une lib est indépendante qu'elle va s'intégrer magiquement à ton applicatif : genre t'installes cette lib et tu vas pouvoir mettre de l'async aux actions de contrôleur de Symphony en 3 coups de cuillères à pots ?
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Je ne connais pas assez PHP, mais en java on a pas attendu que ça fasse partie du langage pour avoir de l'asynchrone avec rx et netty. Python non plus d'ailleurs (à minima avec des trucs comme twisted). Pas plus que perl en fait (avec POE).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
ben voilà, ces langages ont de l'async en natif depuis 10 ans. Y'a un fossé qui ne cesse de grandir mais bon ça ne choque personne donc continuez.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 4.
Java a de l'async depuis quelques années (et encore ça n'est pas si simple), python depuis 5 ans si je ne m'abuse et perl n'en a pas encore. Comme PHP, ils passent par des bibliothèques externes.
À noter que le cas d'usage le plus répandu de PHP, un reverse proxy avec FPM, une base MySQL ou Postgres, pose différemment la problématique de l'asynchrone. Par exemple si ton driver de base de données n'est pas asynchrone ça n'a pas grand intérêt. En java on commence à en avoir, mais je suis suis pas sûr que ce soit très répandu ailleurs. Pour ce qui est de l'IO sur la socket client, je pense que c'est au sein de FPM (quand tu déploie avec FPM) que ça se gère et pas du tout au niveau des API du langage.
Bien sûr il y a d'autres IO possibles et classiques (en vraiment classique je pense à mongo et redis) mais il faut voir pour chacun où ça en est.
Ensuite faut se rappeler que l'asynchrone ça n'est pas forcément la panacée, ça dépend de ton workload.
Tu n'a pas l'impression de faire des jugements à l'emporte pièce pour chaque pseudo-argument que tu donne ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Java, je ne sais pas mais Python fait de l'asynchrone depuis très longtemps. Ils ont juste formalisé les choses un peu mieux avec des api et des mots clés dédiés depuis 5 ans : async/await.
Quand tu évoques le fait que l'async nécessite toute la chaine en async, j'en ai bien conscience et c'est pour ça que quand on me dit que c'est même pas supporté nativement, je doute que ça soit possible d'en faire aussi facilement.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 4.
asyncio a était intégré au langage en 2014, ok ça fait 6 ans. Mais asyncio était hors du langage avant ça et depuis bien avant il y avait twisted. Et ça n'a pas l'air d'avoir trop contraint tornado, flask et autres pour faire de l'asynchrone.
De ce que je vois avec python et java, on expérimente hors du langage et c'est quand les pratiques de la communauté se stabilise que l'on intègre dans le langage. Ça me paraît pas idiot comme approche.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 1.
asyncio c'est plus du "green threading" mais y'avait déjà la possibilité de faire des thread avec verrou ou du multiprocessing bien avant.
Twisted c'est plus une couche réseau à de l'async.
Flask ne fait pas d'async.
Tout à fait d'accord, d'ailleurs C# et Rust ont fait la même chose.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Ah ah. Oui d'accord. Mais ça on s'en fout et ça n'a pas grand intérêt en PHP. Quand on parle d'async, ce qui a de l'engouement c'est pas le multiprocessing. Toute le monde sait en faire et php est probablement bien mieux capable de paralléliser que python et le gil.
Non ce qui intéresse les gens c'est d'avoir des IO asynchrone. L'idée ce n'est pas de faire du parallélisme mais de multiplexer les IO à bas coup (sans utiliser des threads "lourd" et encore moins faire du multiprocessing).
C'est précisément ce qui est recherché quand on parle d'asynchrone.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Oula, bcp de notions qui se recoupent.
Tu sais sans doute ce qui précède mais je préférer formaliser les choses plutôt que d'avoir des quiproquos.
J'essai de distinguer 2 notions :
Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.
La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.
Pour ça, la technique jusqu'à il y a une dizaine d'année était de mettre un verrou sur des données le temps qu'on y touche puis de libérer ce verrou. (avec tous les autres problèmes qu'il soulève : si on libère jamais le verrou)
Puis on a eu les green thread, qui est grosso modo un algo qui fait ça tout seul sans qu'on s'en soucis.
Bien entendu, dès qu'on peut utiliser les green thread à la place des thread, il faut le faire car on se protège de tous les pièges cités.
Et si on peut passer par des green thread à la place de process, on y gagne aussi niveau ressources… et c'est pour ça qu'il y a pas mal de hype autours.
Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.
Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.
Le projet Servo (navigateur expérimental longtemps supporté par Mozilla et qui est passé il y a 1 mois dans les mains de la Linux Fondation) remplace ces process par des green threads.
Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process :
entre occupation mémoire et sécurité.
Bcp de projets font par ex le choix de partir sur des process (le petit projet qui démarre et qui n'a pas bcp de hits) puis passe par une phase d'optimisation ou ils remplacent.
(on gagne en utilisateurs, on peut perfectionner au lieu de gonfler le serveur)
Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?
On peut en faire mais ça passe par des libs PECL si je ne me trompe pas donc c'est pas natif.
Python, tout ça est natif depuis longtemps, sauf les green thread ou l'ajout date de 2014 dans la 3.4 et les mots clés await/async dans la version suivante.
Pour ce qui est du GIL, c'est une limitation de Python qui empêche le gain de parallélisme sur les thread (green thread compris) car il ne va s’exécuter que sur un processeur.
En gros, pour mon exemple sur les vidéos, le temps sera plus long pour traiter mon image avec des threads que sans.
C'est un sujet qui revient souvent sur le tapis mais qui nécessiterais une refacto profonde du code de Python (ou plus précisément CPython) dev en C.
Des autres implémentations de Python (mais en retard sur l'implémentation officiel) n'ont pas cette problématique tel qu'une version expérimental de Pypy (voir https://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for).
Dans la logique web oui mais bon Twisted permet principalement de simplifier avec du sucre syntaxique et des apis dédié pour faire du curl, du ftp, ssh, pop, imap etc.
Du coup, ça présente moins d'intérêt en natif
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 02 décembre 2020 à 01:00.
Je ne suis pas d'accord :)
Alors en soit oui, mais il y a des amalgames. La parallélisation est le fait de faire plusieurs choses en même temps et l'asynchronisme est le fait de gérer le décallage temporel qu'il peut y avoir entre 2 évènements. J'aime bien parler de réactif pour l'engouement actuel. Il s'agit de considérer toutes tes IO selon des paradigmes asynchrones supprimant tout blocage.
Pour la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.
Avoir la RAM suffisante est vraiment un palliatif quand on compare au résultats des solutions réactives et tu es face à un problème de taille : la multiplication de tes threads ou processus multiplie les commutations de contexte. Donc plus tu as de clients plus tu passe une proportion de ton temps dans tes commutations de contexte. Entre ça et la RAM qui va avec c'est très dommageable, pour les gros car ce sont des serveurs en plus à avoir et pour les petits parce que ça empêche de fonctionner correctement sur les les plus petites machines.
La différence est drastique.
Ils ont d'autres contraintes. Ils ont par exemple besoin de garantir qu'un onglet n'accède pas aux données d'un autre onglet. Le fonctionnement des greens threads pose aussi des problèmes quand tu exécute du code qui n'est pas à toi.
Tu te fourvoie sur les greens threads, ils ne sont pas vraiment fais pour la parallélisation et ce ne sont pas les meilleurs pour ça.
Le principe derrière réactif dont je parlais plus haut c'est d'avoir un pattern reactor. Tu as une boucle d'évènements1 et tu les traite l'un après l'autre sans avoir de thread (et encore moins de processus) entre la boucle d'évènement et le traitement. Tu as une boucle par CPU et une file d'évènements devant. Chaque IO doit passer par cette boucle d'évènements. Ça c'est l'interne, l'implémentation, c'est du traitement coopératif, on ne préempte pas c'est toi qui laisse la main. Évidement il ne faut pas être être CPU bound (sinon tu as besoin de paralléilisation) mais IO bound.
POE et twisted te montrent assez directement ce paterne. Mais tu as d'autres API qui l'encapsule et t'aide à t'en servir. C'est ça les green thread. Chaque appel qui paraît bloquant est en fait implémenté de façon asynchrone et est l'occasion de passer la main à l'évènement suivant. Mais il y en a d'autres comme les acteurs ou rx par exemple.
En php tu ne gère pas un serveur qui reçois des requêtes que tu dois traiter. Ton code est instancié pour chaque requête. C'est la stack qui s'occupe de ça pour toi. Tu as différentes façon de lancer ton code PHP ce n'est pas lié à ta version de php (pour pouvoir être réactif il faut effectivement ajouter des choses dans le langage). Pour le parallélisme, il est par essence massivement parallèle. Tu peut avoir des besoin de parallélisation en plus, mais en soit c'est rare et c'est dangereux de faire du parallélisme par requête.
c'est basé à fond sur
epoll(4)pour attendre des évènements sur une série de file descriptor ↩https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
T'as un peu redis la même chose, non (peut-être mieux je te l'accorde) ?
La commutation de contexte est surtout pénalisante quand celle-ci est lente donc les threads sont pour le coup bien moins handicapant que les processus. (qui en plus différent d'un OS à l'autre)
Tu as l'air de suggérer que les green threads n'auraient pas ce genre de soucis. (commutation de contexte)
Ça me parait tout à fait infondé et je suis curieux d'avoir des sources sur les propos avancés.
Bon Dieu non, je pensais plutôt à une requête et derrière du parallélisme (la requête ça peut être "applique un filtre à l'image que je t'ai envoyé précédemment"), un script lancé par un cron etc.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Je voulais signifier que les threads/processus et les greens threads (tel qu'ils sont implémenté maintenant) résolvent 2 problèmes différentes :
Un vielle exemple de l'impact que peux avoir le scheduling et qui fait un peu ressentir la différence c'est le vieux patch du noyau. On ne touche pas à l'usage CPU, ni au temps d'exécution, mais on a plus de latence.
Je suis pas persuadé que ça face une différence perceptible et quelques soit l'OS ça demande de passer en espace noyau et nettoyer le core sur lequel il s'exécute.
C'est la définition des greens threads donc je sais pas trop quoi dire. T'a l'air de ne pas trop te fier à wikipedia, donc je te laisse choisir la source qui te plaira. Je serais curieux de connaitre une source qui n'explique pas que c'est des threads en espace utilisateur. Après le fait de l'implémenter par de l'asynchrone "caché" n'est pas obligatoire, mais sans ça ça n'a pas vraiment d'intérêt. C'est pour ça que java a jeter sa vielle implémentation il y a un paquet de temps, mais qu'ils y réfléchissent de nouveau.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.
Moi, ce que j'en comprend c'est que c'est géré par le runtime du langage (et non par l'OS) et que c'est en espace utilisateur.
Ce dernier point permet de gagner de la souplesse (pas de lock) et j'imagine de la sécurité.
Je ne vois pas en quoi ça améliore le context switching. D'après https://en.wikipedia.org/wiki/Green_threads#Performance, c'est même l'inverse et ça me parait logique vu que c'est une couche d’abstraction en plus et que ça ne tiens pas en compte du matériel (mono CPU et pas de prise en compte du multi-threading physique)
Après, entre la définition (d'ailleurs chaque langage a un peu son nom a lui), l'implémentation (pareil, très fluctuent) et ce que ça fait réellement.
J'essai de diversifier mes sources et pas faire une confiance aveugle au premier résultat un tant soit peu pertinent.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.
Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés… C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.
Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.
A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Je ne dis pas le contraire. Ce qui se fait dans le scope d'un process reste vrai et vu qu'un thread (green ou non) est encapsulé dan un process, il sera forcément dépendant des interruptions/reprises de ce dernier.
Mais tu pars du postulat qu'il n'y a pas de context switching dans les green thread ce qui me semble tout à fait erroné.
Dès qu'il y a de la concurrence, c'est inévitable.
La seul différence c'est que c'est géré en espace utilisateur : c'est donc l'algo de ton langage qui s'occupe d'ordonnancer et non les routines de ton kernel.
(Ça permet sans doute d'uniformiser les comportements entre architectures physiques et OS mais bon ça reste du détail)
Comme tu le dis précédemment, le risque du context switching c'est que quand il n'y en a trop, ça devient plus long que du synchrone :
c'est pour ça que tu trouveras aussi bien dans les process, thread que green thread la possibilité de donner une limite d'opérations en simultannés.
Bref, rien n'est scalable à l'infini, tout à des limites physiques.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 06 décembre 2020 à 18:01.
Je n'ai pas était très précis, quand je parle de context switch, j'entends celui qui est le plus classique, qui s'appuie sur une interruption, implique de vider le core du CPU ainsi que d'autres choses comme le TLB. Les greens threads sont coopératifs, ils impliquent beaucoup moins de choses, on en nettoie pas le core (seuls quelques registres sont changé), ni le noyau1, ce qui en fait une opération drastiquement plus performante.
évidement cela se fait au détriment de la sécurité, mais on reste au sein d'une même application. C'est pour ça que ce n'est pas une bonne idée pour Firefox qui exécute du code qui n'est pas maitrisé, utiliser des threads systèmes c'est nécessaire (mais pas suffisant) pour ce genre de pratiques) ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Je me suis prêté à l'exercice rapide de comparatif : http://pastebin.fr/76926 (rien de mieux qu'un peu de pratique après de la théorie)
J'ai beau tourner le truc comme je veux, les threads sont plus rapides.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 2. Dernière modification le 06 décembre 2020 à 19:04.
Je vois plusieurs problème potentiels avec ce code :
Cela dit, ton résultat ne m'étonne pas : je m'attends à ce qu'un processus parallélisable s'exécute plus vite sur plusieurs threads systèmes que sur plusieurs green threads placés sur un seul thread système : il n'y a pas de parallélisme dans ce cas ! :-) Et c'est probablement ce que fait ressortir ton test.
Les vraies questions à mon avis seraient plutôt :
j'imagine que Barmic à plus ça en tête. Effectivement, il est possible que le "switch" soit plus léger au moins dans ce deuxième cas, voire dans le premier si c'est bien gérer (mais le risque dans le premier cas c'est de se payer aussi les context switch des threads systèmes en plus de entre les green threads si c'est mal géré…).
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Je te rejoins. Je n'ai pas le temps de tester le code, mais j'ajoueterais :
J'ai vite fais trouvé un bench qui fait exactement ce test mais sur qui montre plus l'évolution en fonction du nombre de requêtes, jusqu'à 10 url les threads sont meilleurs (contrairement à toi il utilise un pool de threads pour ne pas exploser son CPU et éviter de payer de trop le coût de création des threads). Tu peux trouver le lien ici : A better way for asynchronous programming: asyncio over multi-threading.
C'est précisément ce que fait go par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0. Dernière modification le 06 décembre 2020 à 20:53.
En réalité, j'ai anticipé ces questions.
J'ai volontairement simplifié le script pour l'exemple. J'ai testé avec un nb d'urls bien plus conséquent et plus j'ai tendance à rajouter, plus l'écart se creuse en faveur des threads.
asyncio est la couche de concurrence de Python haut niveau et elle s'appuie sur les green thread par défaut. (mais on peut la config pour s'appuyer sur des threads ou des process : ça pourrait d'ailleurs valoir le coup de tester)
Mais si d'autre veulent faire une impl dans un autre langage, je suis preneur
La, j'ai tout mis dans le même script mais en réalité j'ai effectué mes tests dans 2 fichiers distincts.
J'ai franchement joué le jeu en testant une autre liste d'url dans le sens inverse.
Pas une seul fois, (mais ça reste bien évidement possible, il suffit qu'un site soit plus lent temporairement) j'ai eu un résultat plus rapide avec asyncio.
Mais si l'on me démontre l'inverse, je m'inclinerais : je ne cherche pas à avoir raison.
Je peux bien sur pousser le truc plus loin, lancer des centaines de fois, faire des moyennes et des médianes et créer des graphiques… mais est-ce que le jeu en vaut la chandelle ?
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 2. Dernière modification le 06 décembre 2020 à 23:25.
Je ne sais pas si le jeu en vaut la chandelle, tout dépend du but, mais en tout cas il est exigeant. Le sujet est intéressant, mais si on veut faire bien les choses, je pense que déjà, la question doit être précisée parce qu'on ne sait pas trop ce qu'on cherche :
Et ensuite, il faudrait le jouer complètement avec des mesures et une démarche rigoureuse convaincante. J'ai été un peu sévère en jugeant tes mesures, et ce n'est pas pour être pénible, c'est juste qu'il y a mille et une manière de foirer ses mesures sur ce genre de chose. Je le sais, j'ai fait des études dans un domaine relatif à ce genre de questions, puis travaillé dans une équipe de recherche et été entouré de gens travaillant sur des questions de perf. C'est compliqué à faire correctement. Ce n'est pas ma spécialité, mais je vais avoir du mal à trouver les résultats fiables sans ça.
Ton script illustre que de l'asynchrone sur 1 thread pour faire 3 opérations d'I/O probablement bloquantes "suffisamment longues" est plus lent que 3 threads pour faire ces opérations en parallèle. Ok, en fait, l'inverse m'aurait étonné. C'est super d'avoir fait l'effort de mesurer et en plus de publier le script, ça permet une discussion concrète (et ça expose à la critique). Il a d'ailleurs permis de préciser les choses. Mais pour moi ça ne répond pas vraiment au problème qu'on a du mal à poser : est-ce que les green threads* sont plus efficaces que les threads natifs ? et dans quels cas ? (je m'attends à des résultats variés selon la charge de travail). En même temps, la question est vaste en fait !
C'est beaucoup de travail, c'est presque de la recherche. Il faut clairement poser le problème, éventuellement faire un état de l'art (des mesures existantes, types de charges de travail typiques, des techniques d'ordonnancement des threads système et en espace utilisateur), proposer un protocole expérimental rigoureux, l'appliquer et exploiter les résultats. Ça peut être fun et des gens adorent faire ça, mais clairement, je n'ai pas prévu de le faire maintenant xD. Il y a probablement des papiers là dessus, je n'ai malheureusement rien trouvé de récent après une recherche rapide. Il y a peut-être des choses intéressantes à ce sujet du côté de Go ou Haskell mais une recherche rapide n'a rien donné non plus. Il y a peut-être des articles de blog détaillés sur le sujet :-)
*disons, les threads en espace utilisateur, je suis assez persuadé que les greens threads limités de Java il y a 20 ans n'étaient pas vraiment performants - ce n'était d'ailleurs pas vraiment leur objectif, leur objectif c'était il me semble surtout de ne pas trop dépendre des spécificités de chaque système d'exploitation pour avoir un mécanisme plus ou moins concurrent.[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Y'avait pas vraiment de but en soit à part peut-être de démontrer que entre la théorie et la pratique, certains concepts sont loin d'être aussi simple qu'ils n'y paraissent et que autant choisir une techno pour ses fonctionnalités est souvent pertinent, pour les perfs, ça peut être à double tranchant.
L'asynchronisme, jouer avec plusieurs langages, implémentations c'est toujours intéressant mais chronophage.
Comme souvent, quand on va dans ce genre de voie :
* la doc est difficile à trouver
* le vocabulaire n'est pas standardisé : on va parler de "green thread" dans Java mais ça sera plutôt des coroutines dans d'autres langage voir "green processes" en Erlang
* la doc pertinente sera souvent noyé par beaucoup de bruit
* faudra se tourner vers de l'anglais
Je passe pas mal de temps à lire le source de gros projets dans des langages que je maîtrise ou à regarder http://www.rosettacode.org/wiki/Rosetta_Code qui permet de comparer des langages sur des algos similaires.
Je pense que l'on a tendance (surtout les dev) a surestimé (moi le 1er) les diffs du software entre le matériel cible alors que dans certains domaines (la concurrence en fait partie), les perfs peuvent être très diff selon l'architecture employé et que des fois il vaut mieux se satisfaire d'une méthodologie éprouvé mais pas optimal plutôt que chercher le saint Graal et finalement se retrouver avec quelque chose de très productif dans un scope précis et improductif dans d'autres.
Tout à fait.
Java, leur slogan c'est "run everywhere" et faire des if (os == 'bsd') ça devait pas trop les enchanter.
Je ne vais plus continuer sur ce fil les échanges concernant l'asynchronisme car ça devient un peu ridicule.
Néanmoins, ça pourrait être intéressant d'avoir un dépôt de code (et de doc en markdown) avec des exemples sur le sujet :
- de la vulgarisation
- des liens vers des trucs pertinents
- des benchmarks idéalement dans plusieurs langages
- recommandations : utiliser tel truc dans tel cas
Si ça botte quelque uns, je pourrais initier le sujet.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 06 décembre 2020 à 23:41.
Alors je ne jouerai pas avec ton script par flemme de lister pleins d'url. Par contre je viens de vérifier et asyncio et single core donc pour utiliser tout la puissance de ta machine il faut effectivement toi même créer un thread pour chaque cpu et chacun lance des requêtes. Ça devrait être mieux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par Faya . Évalué à 1.
Je répondais uniquement à "je sens la blague pour coupler ça avec des frameworks."
Ben non ça fonctionne très facilement avec les frameworks qui respectent les PSR (tous). Tu choisis le composant dont tu as besoin, puis
composer require xyzet il est disponible dans le contrôleur, dans son espace de nom. Et ReactPHP n'est pas le seul.https://www.zend.com/blog/why-you-should-use-asynchronous-php
[^] # Re: Des bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Moi je dirais que, de ton premier commentaire à celui-ci, tu as des idées (fausses) bien trop arrêtées pour te permettre un tel jugement.
J'ai 35 ans de programmation derrière moi, avec au final pas mal d'expérience dans beaucoup de langages. PHP n'est pas sans défaut, mais de là à le mépriser à ta façon, c'est totalement débile.
En tout cas, ce snobisme sur tel ou tel langage parce qu'il serait plus "pure", ça me gonfle, car souvent prônés par des personnes qui sont en décalage avec la réalité du terrain, et croient détenir la vérité à cause de leur immaturité professionnelle, et pour certains sous l'emprise d'un bel effet Dunning-Kruger.
Critiquer un truc qu'on ne connaît pas bien, c'est fort quand même…
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
J'ai toujours du mal avec le joker "cv". A côtoyer des devs d'âge et d'expérience pro divers, ce n'est sans doute pas le critère le plus pertinent.
Je ne le méprise pas mais ça reste un langage de "template" pour moi qu'on a voulu transformer en langage générique.
C'est comme si je disais qu'on va faire des applis entièrement en Jinja, Razor ou Twig (d'ailleurs, ce dernier quand on y pense c'est du template par dessus un langage de template).
Utilisons les choses pour ce qu'elles sont.
J'ai rien contre les twingo mais si on me dit qu'on va transformer les twingo pour en faire des ferrari, ben excuse moi d'être sceptique.
L'un n'empêche pas l'autre d'exister.
Ce que je reproche à PHP c'est de manquer d'identité.
Ca fait 10 ans que son évolution c'est de s'approcher de langage full POO et fortement typé et s'assoie sur ce qui a fait sa force au début.
Du coup, il ressemble à du Java/C# en mode dégradé.
La réponse magique a ça c'est de me dire que PHP est rétrocompatible.
D'une part, ce n'est pas entièrement vrai. (je sais de source sur que certaines boites ont investis énormément en temps et en énergie pour passer de PHP 5 à 7)
De l'autre, je trouve irresponsable de ne rien déprécier.
Ah bon, tu ne le fais jamais ?
Un politique va parler, tu vas jamais le critiquer ? Pourtant, t'as pas fait l'ENA.
Ton voisin va critiquer les mesures de confinement. Il n'est pas pour autant virologue.
On va pas se mentir, l'Homme même avec une discipline scientifique rigoureuse est en réalité très peu rationnel, soyons honnête.
On est tous soumis un jour ou l'autre à des dissonances cognitives.
Pour en revenir au sujet, je parle de l'écosystème (donc bien plus large que le langage) qui comprend bcp de choses (gestionnaire de dépendances, frameworks, libs, bonne pratiques) et qui demande souvent de l'expérimentation pour dire qu'on connait.
Mais bon, c'est des connaissances macros et ça n'empêche pas d'avoir un avis tout à fait objectives sans tout connaitre dans le détail.
C'est d'ailleurs le métier d'architectes logiciels : faire des choix techniques sans connaitre tout sur le bout des doigts.
Y'a une juste valeur a avoir. Par exemple, je laisserais des langages comme Haskell, Prolog, Ada dans le cadre "académique" : on apprend des concepts qu'on va pouvoir réutiliser dans des langages plus orienté "concret".
Faut déjà définir "être en phase avec la réalité". Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
C'est toi qui a lancé l'appel au CV :
Si l'expérience n'est pas un argument ne t'en sert pas toi non plus. Sinon évidement que les gens vont répondre en contextualisant avec leur expérience, tu leur demande.
Haskell et prolog, je ne sais pas, mais il n'y a pas plus industriel qu'Ada. « Dans ma réalité, un bug en prod pendant une journée peut coûter des milliers d'euros donc d'une on réfléchit à ce que tout soit rollbackable et de deux on table sur la sécurité. » Ada a carrément employé dans des endroits où l'apparition d'une erreur coûte des milliers d'euros (et oui l'histoire retiens que le langage ne fait pas tout).
Après je comprends toujours pas pourquoi reprocher à des langages que tu n'utilisent pas de choisir leurs évolutions.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Je vais croire que t'es payé pour répondre pour les autres.
Point pour toi.
Quand je pensais "expérience" je pensais plus "connaissance".
Si c'est juste des années au compteur, j'ai vu bcp de devs se complaire dans des taches assez répétitives et sortir peu de leur périmètre de confort.
Pour Ada, je suis sur que tu penses à https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5
J'ai jamais dit le contraire. C'est par parce que t'as une ceinture, l'abs et des airbags que tu peux faire le fou au volant… mais bon, quand ça te sauve la vie, t'es bien content.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 2. Dernière modification le 13 décembre 2020 à 12:48.
Tu fais références à ce passage ?
C'est sûr que si on ne respecte pas les procédures et qu'on ne lance pas les tests, bah ça peu foirer. À moins d'avoir un code et du matériel prouvé correct, mais bon courage avec ça.
Ou ce passage ?
C'est sûr que si on ne fait pas correspondre le matériel avec le logiciel, ça peut aussi mal se passer.
Que voulais-tu montrer avec ton lien ? Que les catastrophes sont souvent dues à une succession de décisions foireuses indépendantes des technologies utilisées ? Félicitations, c'est réussi, mais tu aurais pu être plus explicite. Je suis bien d'accord avec toi, c'est triste qu'on continue à faire des économies de bouts de chandelles de ce type, c'est comme si on n'avait rien appris du naufrage du Titanic et c'est regrettable.
Ou alors tu voulais illustrer le fait que Ada est un choix répandu pour concevoir des systèmes industriels embarqués critiques ? Drôle d'exemple pour ça, mais bon pourquoi pas. Un exemple n'est pas vraiment suffisant mais de toute façon je crois qu'on est tous convaincus qu'Ada est un très bon choix pour faire de l'embarqué critique même s'il ne peut malheureusement pas résoudre les problèmes causés par les décisions foireuses donc ce n'est pas très grave.
(et sinon, une discussion honnête et bienveillante, ça te dit ?)
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Un exemple de bug à plusieurs millions dev en Ada. Rien de plus, rien de moins.
Je pense qu'on a un peu épuisé le sujet et être lasse de devoir me justifier.
On se retrouvera sur d'autres thématiques sur linuxfr !
Je ne pense ni être malhonnête ni être malveillant.
J'ai exprimé simplement un coup de gueule et un avertissement (c'est ma première sur linuxfr) après avoir eu des expériences pro et associatives autours de trucs dev en PHP (et d'autres langages interprétés) qui me semble être plus du bricolage que du sérieux.
[^] # Re: Des bonnes idées
Posté par Nitchevo (site web personnel) . Évalué à 6.
Que Php soit devenu un langage aussi dominant s'explique par des raisons historiques ce qui était déjà critiqué par nombre de programmeur à l'époque de Php3. Il s'est depuis largement étoffé et continue de devoir supporter des critiques. je vois ces critiques comme aussi la poursuite d'un débat sans fin: les arguments changent au fur et à mesure que Php évolue mais il y a toujours quelqu'un qui se drape dans sa compétence dans d'autre langage pour expliquer que Php "c'est bien pour faire un truc vite fait mais dès que ça devient un peu important il faut un langage sérieux" comme, au choix, Java, Python, Perl, C++, Rust. Je ne conteste pas la qualité de ces langages mais au final Php est toujours là et le web ne s'est pas effondré.
[^] # Re: Des bonnes idées
Posté par Faya . Évalué à 7.
Ce genre de commentaires ce n'est que de la religion. Il le dit lui-même "Non, je ne connais pas bien car comme dis et du peu que je regarde, c'est que du réchauffé". Donc il ne connaît pas le langage, affirme des trucs faux, mais bon défoncer du PHP c'est bien vu. PHP est en retard sur d'autres langages ? Faut le jeter. PHP rattrape son retard sur d'autres langage ? Faut le jeter. Et on attend le commentaire qui va ressortir l'article vieux de 8 ans "PHP: a fractal of bad design" mais comme tu le dis si bien, 8 ans après ça fonctionne et ça évolue. Tiens ça me fait penser que dernièrement j'ai rencontré un dev PHP qui s'est foutu de ma gueule pendant une réunion parce que j'utilisais Vim. Si on ne juge pas ton langage on jugera ton éditeur, ton OS, ta distribution, ton environnement de bureau… Bref, haters gonna hate. En attendant Vim & PHP (entre autres) paient mon loyer et j'y prends du plaisir.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -2.
J'ai pas dit que je connaissais pas ou j'en avait pas fait. J'ai dit que je ne m’intéresse pas à l'écosystème : y'a quand même une grosse nuance.
Pour le principe de la religion : non, justement. Je ne suis pas attaché à un langage ou a une communauté en particulier mais j'essai de me rapprocher de ceux qui correspondent le plus à un besoin précis.
Je ne dis pas de le jeter mais d'arrêter de faire tout et n'importe quoi avec et de faire évoluer vers quelque chose qu'il n'est pas.
PHP en version 3, c'est à peu prêt là ou il aurait dût s'arrêter :
fait pour des petits projets web sans prétention, sans grosse connaissances techniques et c'est très bien !
Je comprend pas ce besoin d'améliorer sans cesse, on peut très bien laissé une techno, que ça soit un langage ou autre s'arrêter d'évoluer.
A la rigueur, apporter des choses comme l'utf-8, pourquoi pas mais de l'OO puis du typage pour arriver 10 ans après au même point que Java d'il y a 10 ans… je trouve légitime de trouver ça stupide et de l'exprimer quitte à passer pour un hater.
(Combien de dev PHP qui détestait Java pendant leur étude pourrait prendre une doloréan pour dire à leur moi du passé : tu feras du Java mais ça s'appellera PHP)
Alors, oui, je perds sans doute mon temps car personne ne se remettra en question et continuera a s'extasier d'avoir maintenant des match (et des switch) dans la nouvelle version de PHP.
[^] # Re: Des bonnes idées
Posté par Faya . Évalué à 4.
Même si tu parvenais à convaincre la totalité des utilisateurs PHP de linuxfr.org, je ne pense effectivement pas que ça ferait une vraie différence : PHP is used by 78.9% of all websites with a known server-side programming language
OK t'as pas dit de le jeter mais de "changer de langage" (je te cite). Il y a beaucoup de critiques constructives à faire sur PHP et le développement Web en général. Je t'assure que les développeurs/utilisateurs les connaissent. On a conscience des manques, des inconsistances, des bugs. Asséner "Vous n'avez rien compris, changez de langage" n'en est pas une. «There are only two kinds of languages: the ones people complain about and the ones nobody uses.» — Bjarne Stroustrup
Tu en es à 13 commentaires sur ce truc qui ne t'intéresse tellement pas… À la limite ceux qui gueulent contre systemd peuvent se plaindre du fait que ça affecte l'OS qu'ils utilisent quotidiennement, mais là… je ne vois pas ce qui t'empêche de juste passer ton chemin.
Très très simple : ceux qui développent / utilisent en ont ressenti le besoin donc ils l'ont fait.
Tu n'en as pas besoin ? Génial. Tu peux reprendre une activité normale.
[^] # Re: Des bonnes idées
Posté par Nitchevo (site web personnel) . Évalué à 4.
A l'époque de Php3 l'absence de modèle objet était le fer de lance de ceux qui disaient d'oublier Php pour se tourner vers un vrai langage, au hasard souvent Java; Aujourd'hui tu explique que l'OO de Php n'est pas meilleurs que celui de Java il y a dix ans…C'est très bien mais à l'époque pour avoir Java sur un petit site c'était compliqué et sur un gros les problèmes de ressources se posaient joyeusement. Aujourd'hui Php a à peu à peu coché les cases qui manquaient fait tourner des sites énormes sert de bases à des Frameworks performants et tu viens nous resservir un discours vieux de dix ans expliquant que tout aurait été mieux si cela avait été différent, ça c'est du déni de réalité.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Ben oui et je pense que c'est la même raison : PHP c'est bien pour des petits projets, pourquoi vouloir changer sa nature pour ressembler à quelque chose qu'il n'est pas.
Sa nature pour moi, c'était de faire du dynamique facilement sans avoir de connaissances en typage, en POO etc.
Bref, une courbe d'apprentissage rapide. (C'était un bon premier langage pour s'initier à la prog ou pour des personnes qui ne sont pas du métier.)
Si on regarde, il n'y a plus grand chose de ce genre qui existe : que des langages pour du pro (et expérimenté) et je trouve ça dommage.
En plus, une gamme de mots clés de plus en plus vaste.
J'imagine le débutant en PHP 8 qui va avoir des matchs et des switch dans le même applicatif… quelle tristesse.
Du coup, pour moi, le PHP va de moins en moins attirer les débutants car de plus en plus complexe et encore moins attirer les plus aguéris car d'autres langages sont mieux équipés et plus restreint dans leur syntaxe : en Rust, on a que les match, y'aura jamais de switch, en Python, pas de switch, que des if.
Je suis dac, les hébergeurs ont poussés pas mal à rester sur PHP car dès qu'on voulait utiliser un autre langage, fallait sortir le porte-feuille.
Perso, déjà il y a 10 ans j'arrivais à faire du web sans PHP.
Mais, un autre temps, d'autres combats.
Sauf que si l'évolution de Php tend à résoudre des soucis d'il 10 ans, il n'est donc plus adapté aux problématiques actuelles ?
On peut dire que le code de PHP actuelle ressemble à s'y m'éprendre à Java d'il y a 10 ans mais est encore en deçà au niveau qualité et rapidité.
Je rappel que Java effectue ses contrôles de type à la compilation et produit un bytecode qui est par nature plus rapide à interpréter.
Mais effectivement, je suis plutôt convaincu que la POO est un mauvais paradigme et qu'il y a des amalgames entre certaines choses utilisés dans des langages full POO qui n'est pas forcément de la POO (espace de noms, chaînage des appels, généricité, encapsulation etc.)
C'est un discours difficile à entendre car beaucoup ont perfectionné leurs apprentissages autours de ça (design pattern et autre joyeuseté).
J'ai moi même essayé de m'y accrocher pendant plusieurs années avant de m'y résoudre.
Je suis de loin pas convaincu.
Dans ces sites, c'est plus l'infra autours qui va faire la diff : load balancer, varnish, logstash, worflow autours de Git etc.
Tout ça a évolué très vite (le front aussi) mais pas vraiment PHP.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 4.
Il est interprété dans certains modes puis le JIT se met en place et ça fini en code natif après un temps de chauffe assez connu.
PHP compile vers des opcode au premier passage qui sont réutilisés aux autres appel et depuis PHP8 peut faire du JIT.
L'interprétation le bytecode à chaque appel jusqu'au JIT ou interprété du code source au premier accès puis réutiliser l'opcode. La mesure de performance est loin d'être aussi simpliste.
T'es convaincu de beaucoup de choses j'ai l'impression.
Les design pattern ce n'est pas forcément OO, une monade c'est un design pattern par exemple.
Il évolue pas assez vite ou trop ? Qu'est-ce nous donne à nous non utilisateur de ce langage une quelconque pertinence pour dire ce qui devrait être ou ne pas être du PHP ? D'autant que c'est des discussions qu'ils ont et qui sont bien plus argumentées que tout ce que nous pourront produire ici.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Je sais tout ça et c'est effectivement une facilité de reprocher un argumentaire car j'ai pris quelques raccourcis.
On va dire qu'il y a quand même des grandes lignes dans les performances :
un algo compilé en instructions natives sera plus rapide que de l'interprété.
c'est le ratio entre les 2 qui est difficile (voir impossible) à déterminer.
une mesure de perf sur un algo avec un garbage collector peut être fluctuent alors que sans il est plus prédictible.
Je pense me remettre suffisamment en question mais ça n'interdit pas d'avoir des opinions.
J'essai de tirer des conclusions de mes expériences et je trouve que la POO a tendance à figer pas mal de choses.
Par exemple, je pense que PHP a introduit la notion de trait pour justement donner plus de souplesse.
Tu joues avec les mots, je parlais de DP POO.
Et sinon, @barmic, c'est quoi ton intérêt de défendre cœur et âme PHP ?
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Et les opcodes+jit c'est quoi d'après toi ?
Le modèle d'exécution de php doit pas mal aider pour ça.
Te reprendre ce n'est pas défendre corps et âme. Je n'aime pas du tout php. Mais je distingue ne pas du tout aimer et considérer que c'est objectivement mauvais. Je n'aime pas le turquoise, ça n'en fais pas une mauvaise couleur.
Te répondre me donne l'occasion de faire des recherches sur php et python, je trouve ça cool. Ça fait bien longtemps que je ne te réponds plus pour tenter de te convaincre tu te remets bien suffisamment en question tout seul, mais revoir l'historique de l'asynchrone en python, s'intéresser au runtime php,… je trouve ça cool.
Je ne vais pas te demander pourquoi tu viens faire une croisade, au mieux c'est juste du troll.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 3.
D'ailleurs, tes réponses sont intéressantes !
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
C'est de l'intermédiaire.
Compare un algo simple en C et en PHP et fait un bench rapide dessus… tu risques de voir quelques diff. (mais ça veut pas forcément dire que c'est mauvais)
Le premier hit est plus coûteux que les autres.
Dans certains cas, c'est bien, d'en d'autres non (si t'as du cache après le premier hit, ça sert à rien)
Je m'en doutais.
mais si tout le monde s'habillait en turquoise, ça ne te chatouillerais pas de le dire ?
Tant mieux, on a jamais fini d'apprendre.
C'est assez simple, j'ai fait une expérience pro en PHP/Symphony alors que je faisais précédemment du .net et j'ai eu l'impression de faire un saut 10 ans en arrière.
Bien évidement, pour ceux qui n'ont fait que ça, tout est merveilleux.
Pareil, je participe à des projets libres (Primtux principalement) avec des softs devs dans des technos hétérogènes et à chaque fois que je tombe sur du PHP, du Perl ou des scripts sh (à distinguer avec des instructions en cli) ça m'épuise de médiocrité.
Du coup, voilà : en règle général, je passe mon chemin mais là j'avais envie de pousser une gueulante : sortez un peu de votre périmètre de confort et arrêtez de jouer avec votre nombril !
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 3.
Tu le ressent quand un site est en PHP ? Pas moi. Je n'ai pas particulièrement à expliquer aux gens comment s'habiller.
Il me semble bien moins confortable et nombriliste d'avoir un regard curieux sur quelque chose qu'on apprécie pas à priori que de cracher dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -2. Dernière modification le 01 décembre 2020 à 15:26.
Aha, quand j'ai une erreur PHP visible sur un site, oui mais là n'est pas la question : ce qui m'agace c'est plus quand j'ai à créer ou modifier un site en PHP.
J'ai accordé suffisamment de crédit à la curiosité : je suis passé par la lassitude et le désenchantement.
Il y a assez d'autres technos pour assouvir ma curiosité.
[^] # Re: Des bonnes idées
Posté par nud . Évalué à 2.
D'ailleurs je me demande comment un truc comme PHP-PM se comporte.
[^] # Re: Des bonnes idées
Posté par rewind (Mastodon) . Évalué à 8.
There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup (qui s'y connaît en langage qui se fait critiquer par tout le monde)
[^] # Re: Des bonnes idées
Posté par groumly . Évalué à 3.
Pas vraiment, a mon avis. Si t'as des erreurs de types, ton code ne tournera pas comme tu le veux. Si t'es super chanceux, ca marchera peut etre. Ou pas. Qu'il fasse une seule ligne ou 2000 ne change pas grand chose a ca.
Apres, l'inference de type, c'est pas fait pour les chiens, ca supprime l'immense majorité de la lourdeur du typage fort, tout en conservant le typage fort. Et meme java le fait maintenant, c'est dire a quel point c'est mainstream comme feature :)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à -1.
Ca ne tournera pas comme je veux mais j'identifierais le soucis rapidement donc ça ne me gênera pas outre mesure.
La diff entre un petit projet, un POC, un script en one shot etc c'est que justement t'as peu de maintenance, d'exigence qualité etc. Du coup, le typage a un rôle bien moins important.
Oui, l'inférence c'est cool mais bon c'est loin de gommer toute la lourdeur.
Rien que le typage dans les signatures de méthodes, j'ai pas envie de mes taper quand je veux juste faire un truc vite.
D'ailleurs, cite moi des langages interprétés qui font vraiment de l'inférence : doit pas y avoir grand monde car ça doit bien ralentir au runtime…
[^] # Re: Des bonnes idées
Posté par groumly . Évalué à 2.
Oui, alors ca, c’est très discutable.
Foutaises. Le typage te dit « ton code est cassé », au moment ou tu l’écris, pas plus tard, quand tu le fais tourner. C’est toujours important d’éviter des erreurs, et le plus tôt le mieux.
??
Le typage, c’est un truc de language compilé, pas interprété… y’a rien à inférer au runtime.
Sinon, je dirait swift, dans le sens où il support les shebang lines, mais je mettrais pas ma main à couper que c’est interprété.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
ben, si je veux faire un script rapide pour faire par exemple des regex et replace une fois (pas un truc réutilisable), je vais pas m'embêter avec un langage ultra typé. Je vais faire ça en python, pas forcément suivre les règles de pep à la lettre et ça "cassera" jusqu’à ce que ça passe une 1er fois.
Si la conversion est concluante, le script finira à la corbeille dans la foulée.
J'aurais le résultat de mon besoin sans grand efforts intellectuels ni temporels.
sur des petits projets comme celui mentionné à titre d'ex, l'IDE fera amplement le job pour me prévenir de soucis éventuelles et le reste se terminera sans doute par quelques essais/erreurs à l'exec vite résolus.
Pour moi, pas besoin de sortir le bazooka pour tuer une mouche et j'encourage a au moins maîtriser un langage interprété pour bosser vite et un langage compiler et fortement typé pour bosser bien.
Si tu vois mes autres commentaires, tu remarqueras qu'une de mes critiques générales sur PHP c'est précisément d'être trop léger sur le typage (et de faire des vérifs au runtime) pour l'envisager sur de gros projets.
[^] # Re: Des bonnes idées
Posté par groumly . Évalué à 2.
je pense pas que se poser la question 2 secondes de ce qu’une fonction prend en entrée et retourne en sortie soit sortir un bazooka. Qu’on écrive un poc ou le système de navigation de new horizons, ça change pas grand chose.
y’a des arguments pour le duck typing, mais « j’ai la flemme de savoir ce que la fonction que j’écris est censé faire » n’en fait pas partie.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Des bonnes idées
Posté par flan (site web personnel) . Évalué à 3.
Je ne comprends pas bien pourquoi tu parles de préciser les types dans les signatures à propos de l'inférence ; faire de l'inférence consiste justement à deviner le bon type à partir des informations disponibles, en évitant justement à taper les signatures.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Ex, en C#, tu écris une fonction, ça donne un truc du genre :
public int mafonction(MaSuperClass monobjet, string text, int num) { ... }
A l'appel de la fonction, en effet, je n'aurais pas besoin de préciser tout ça car l'inférence fera son job.
La même chose en python :
def mafonction(monobjet, text, num):
...
Pour ma part, j'ai même tendance dans certains cas à préciser explicitement des types parce qu'avec l'inférence, c'est des fois complexe de comprendre à la lecture si on manipule des choux ou des carottes.
[^] # Re: Des bonnes idées
Posté par groumly . Évalué à 2.
Ça dépend. Tout le monde ne fait pas l’inference à la caml. Java, swift, kotlin aussi il me semble font de l’inference au call site, mais exigent de déclarer les types d’entree/retour.
Ca permet de supprimer l’essentiel de la lourdeur d’un typage fort old school, tout en conservant une bonne lisibilité du code.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Pour java le terme inférence me semble un peu galvaudé. C'est plus comme ne pas déclarer 2 fois le type d'une variable. Si une variable est initialisée à sa déclaration, il est possible d'utiliser le mot
varà la place du type pour choisir le type de la partie droite.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par wismerhill . Évalué à 2.
Ben oui, et le type implicite de ce var est déduit de l'expression à droite de l'assignation.
Ça me semble bien être de l'inférence.
Et puis, var a été introduit dans java 8, mais dès java 8 il n'était souvent pas nécessaire de préciser le type des arguments des lambdas, ils étaient déduits du contexte (s'il n'y avait pas d'ambiguité).
[^] # Re: Des bonnes idées
Posté par flan (site web personnel) . Évalué à 2.
Je trouve vraiment étrange l'idée de vouloir « vérifier le typage » avant une mise en prod.
Et au contraire, le mieux est de s'assurer du bon type d'une variable le plus tôt possible, c'est-à-dire à l'écriture du code (donc dans l'IDE). Si tu as un problème de type à la compilation ou à l'exécution (que ce soit des tests ou en prod), c'est à mon avis que tu as raté quelque chose à l'écriture.
En Python, il est excessivement rare que j'ai des erreurs de type (que ce soit dans des tests unitaires ou en prod), car j'essaie d'indiquer les types qui ne peuvent pas être directement inférés.
[^] # Re: Des bonnes idées
Posté par raphj . Évalué à 2.
À la compilation (ou en lançant le vérificateur de type - mypy) ça ne me parait pas déconnant si tu n'utilises pas d'IDE.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Je pense que ça dépend du contexte. Si tu travailles sur des petits projets (ou tu as la capacité d'avoir une vue globale) pas trop exigeants, avec des algos simples, pourquoi pas.
Je dis tjs qu'un typage fin c'est une paire de tests unitaires "gratuits". (sur Python, par ex, j'aurais tendance à mettre des tests unitaires là ou j'en aurais pas le besoin sur d'autres langages)
Dans le cadre de la création pure, ça peut se tenir.
En revanche, dès que tu fais des modifs profondes : suppression de code, refactoring, changement de types, passage d'une lib à une autre etc.
C'est juste trop gros, pour que tu puisses juste t'appuyer uniquement sur ton IDE.
90% des bugs c'est des ratés dans l'écriture.
Si on codait tous parfaitement du 1er coup, y'aurais jamais de débugage.
Et puis, plus il y a de legacy, d'autres devs et
Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut (voir de faire du duck typing) donc foncièrement tu vas te retrouver avec moins d'erreurs de ce genre.
Enfin, ça c'est le sentiment. La réalité pour celui qui vient d'un langage fortement typé c'est que plein de choses sont nommé autrement (mais le soucis reste le même).
Si tu as supprimé un paramètre d'une fonction et que tu as oublié de l'enlever dans un appel, c'est un soucis de type pour moi car la signature de ta fonction a changé.
Par ex, en C# une fonction peut être passé dans une variable (un callback en somme) et du coup, la même fonction mais avec des signatures différentes seront des types distincts.
Tiens d'ailleurs : imagine que quelqu'un modifie la signature d'une fonction et push son travail.
Parallèlement à ça, je fais un appel avec l'ancienne signature : j'aurais pas de conflit au merge et y'aura un bug à l’exécution : pourtant j'ai été attentif et j'ai quand même un soucis.
Si t'as un bug lié à un oubli de try/catch c'est parce que tu n'as pas géré un "type" d'erreur.
Si tu fais un if/else sur un enum et que tu oublis un cas (ou plus fourbe, que t'as rajouté une entrée dans ton enum sans identifié minutieusement tous les endroits ou c'est appelé), tu te retrouves avec des cas non traités lié à un changement de type.
Bref, les exemples sont légion.
[^] # Re: Des bonnes idées
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Faux. Alors, certes quand la limite entre typage dynamique et statique est assez claire, on ne peut pas juste classer les langages dans les 2 catégories "typage fort" & "typage faible". On a des typages plus ou moins fort. Mais en général le typage de Python est considéré comme fort ; essaie de faire
[1, 2] + (3, 4)ou bien1 + '1'pour t'en convaincre.En revanche le typage de PHP (à moins que ça ait changé depuis 15 ans) ou de JavaScript est considéré comme faible.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 4.
Tout à fait. De plus :
Non python ne fais pas du duck typing quand ça l'arrange, il fait toujours du duck typing, c'est à dire qu'il ne fait pas un typage nominal, mais structurel1 et qu'il calcul ce typage au runtime. En python une variable est du bon type si et seulement si elle possède la propriété ou la méthode utilisée et pas si la type de l'objet est du même nom qu'attendu.
La force ou la faiblesse d'un typage c'est ça capacité à caster. Quasiment tous les langages ont un cast à un endroit (par exemple pour pouvoir affecter 1 à un entier, un long, un double), mais certains en font plus et en font de l'implicite.
En langage récent qui en fait il y a go et typescript (c'est d'ailleurs extrêmement pertinent pour lui). ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Tu pinailles, là. A la base, je dissociais des types simples (int, float, string) aux objets.
En effet, Python utilise toujours du Duck-typing (si ça fait coincoin, c'est que c'est un canard) et du EAFP.
En quoi trouves-tu que le duck-typing soit pertinent pour TypeScript ?
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Pour s'interfacer avec un langage à prototype comme l'est javascript, ça me semble être la meilleure solution.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Peut-être, j'avoue ne jamais m'être posé la question.
J'ai testé la transpilation de Rust (qui est loin d'être du duck-typing) en js (ou webassembly) et ça marche plutôt bien.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Ça tout le monde le fait. Compiler d'un langage à un autre c'est simple. C'est l'interfaçage qui est compliqué. Comment utilise-tu une bibliothèque js ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Avec des entry points sur des trucs simples et du mapping (clairement des trucs un peu dégeu mais au moins isolés) sur du plus compliqué.
Après, sur les projets sur lequel j'ai utilisé, j'ai fait en sorte d'utiliser le moins de libs js possibles.
Ma connaissance de Typescript est plus anecdotique mais je suis pas certain qu'ils font réellement mieux. La plupart des projets sont réécris intégralement en Typescript, pas de demi-mesure.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Y'a pas d'échelle gradué pour déterminé la force du typage.
Effectivement, si tu compares tes ex avec javascript ou PHP, on a indéniablement un meilleur typage.
Après, rien que assigner une variable avec un type puis la remplacer plus loin par un autre, pour moi c'est un soucis de typage. (que Python va laissé passer sans soucis)
Autre point qui le chiffonne pour du typage fort :
Aucun contrôle de type à l'entrée d'une fonction.
Du moment qu'on passe le bon nb d'arguments, on peut mettre ce que l'on veut et ça va casser qu'à l'intérieur de la fonction.
C'est potentiellement très dangereux à mon sens.
Bref, y'a plein de raisons pour moi (duck-typing compris) pour ne pas le classer dans les typages fort.
(Même si Wikipédia dit l'inverse)
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . Évalué à 2.
Tu mélange "trouver des inconvénients à un typage" ou "ne pas aimer un typage" et "typage faible". C'est un mélange sémantique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
Peut-être mais même des experts en linguistique ne sont pas vraiment capable de trancher.
Le plus souvent on distingue aussi statique et dynamique.
Perso, j'ai tendance à faire le raccourci que dynamique ne peut pas être du typage fort.
Dans "ma définition" et sans doute dans l'imaginaire collectif, un typage fort ne s'appui que sur des algorithmes prédictifs et déterministes.
On garanti la sécurité du type peut importe le scénario.
Des concepts comme le duck-typing c'est de l'impropre : ça marche bien dans 90% des cas, c'est plus rapide à calculer que de l'inférence de type mais ça reste perfectible.
Je n'ai rien contre le fait d'utiliser ce genre de mécanique mais si on fait un distingo entre faible et fort, je trouve malhonnête et dangereux de mettre des algos avec des trous dans la raquette du côté fort.
Comme dis, vu que personne n'a vraiment officiellement tranché, ça reste mon avis.
[^] # Re: Des bonnes idées
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Je vois ce que tu veux dire, mais je ne vois pas trop l'intérêt de faire ta propre définition, d'autant qu'il y a globalement consensus.
Si tu discutes avec des gens qui connaissent les concepts de typage fort/faible et statique/dynamique, il y a toutes les chances qu'ils connaissent les inconvénients du typage dynamique (on ne va pas faire du code hyper critique avec). Ça permet des combinaisons pour rapidement catégoriser les langages, genre le C qui a un typage statique mais plutôt faible (surtout si on ne demande pas au compilateur d'être un peu agressif) ou le Python qui a un typage fort mais dynamique.
[^] # Re: Des bonnes idées
Posté par mothsART . Évalué à 0.
J'essai d'adapter mon langage selon mon public (ce qui est délicat dans ce contexte).
Si je dis à un gars qui a fait principalement du Haskell, OOCaml et qui s'intéresse à Python que ce dernier est typé fortement, il va vite déchanté et l'argument "dynamique" ne lui suffira sans doute pas et je le comprendrais.
Typage fort, je m'attend à ce que ça soit contraignant et sécure peut importe les petites lignes.
C'est un choix délibéré, peut-être un peu fort de café mais j'assume.
De toute façon, si il y a consensus et qu'on emploi un terme (le mieux serait sans doute de ne pas l'utiliser vu qu'il est nébuleux) c'est forcément qu'on a Sa définition.
# Balance ton string
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Pourquoi pas juste Stringable? Le type string n'est pas Stringable?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Balance ton string
Posté par MCMic (site web personnel) . Évalué à 7.
Non, le type string est un scalaire, pas un objet. Il n’implémente donc aucune interface.
Pour les tableaux ya une filouterie avec le pseudo-type iterable: https://www.php.net/manual/fr/language.types.iterable.php (Qui correspond à
array|Traversable, mais à l’époque ça n’existait pas)Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.