Les nouvelles fonctionnalités de PHP 8

41
28
nov.
2020
PHP

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 que get_class($object) [RFC] ;
  • new et instanceof peuvent maintenant être utilisés avec des expressions arbitraires, sous la forme new (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] ;
  • throw peut 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

  • # Des bonnes idées

    Posté par  . Évalué à 10. Dernière modification le 29/11/20 à 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  . Évalué à 2.

      Ça avance vite

      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  . Évalué à 8.

        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

        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 ?

        la syntaxe juste imbuvable quand on a connu d'autres choses

        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  . Évalué à 1.

          lancer mypy en ligne de commande sans problème sans passer par un IDE pour vérifier le typage ?

          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é.

          Je ne comprends pas cette haine contre PHP.

          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.

          Rejeter ce langage d'un revers de manche parait un peu réducteur.

          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  . Évalué à 4.

            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

            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  (site Web personnel) . Évalué à 5.

            Le passage de PHP 5 à 7 a été très compliqué

            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  . Évalué à -2.

              Le passage de PHP 5 à 7 a été très compliqué

              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é.

              Je n'ai quasiment rien modifié dans les applis PHP que je maintiens.

              Tout le monde n'a pas été aussi chanceux.

              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.

              Ça me fait toujours sourire cette entorse à Semver : Version majeur mais sans breaking changes.

              • [^] # Re: Des bonnes idées

                Posté par  . Évalué à 2.

                Ça me fait toujours sourire cette entorse à Semver : Version majeur mais sans breaking changes.

                D'où tu tire qu'ils utilisent semver ?

                • [^] # Re: Des bonnes idées

                  Posté par  . Évalué à -2. Dernière modification le 30/11/20 à 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  . É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.

                    • [^] # Re: Des bonnes idées

                      Posté par  . É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  . Évalué à 2.

                Ça me fait toujours sourire cette entorse à Semver : Version majeur mais sans breaking changes.

                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  . Évalué à 1.

                  donc ceci n'est pas vrai :

                  n'introduit pas des incompatibilités avec les versions précédentes

                • [^] # Re: Des bonnes idées

                  Posté par  (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  . Évalué à 8. Dernière modification le 30/11/20 à 06:27.

          Facebook aurait certainement eu les moyens de faire des réécritures si PHP avait été un gros frein à son développement

          Ils ont tout de même :

          • créé un compilateur PHP vers C++ nommé HIPHOP
          • une machine virtuelle nommée HHMV
          • conçu un feu langage syntaxiquement proche de php nommé hack

          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, en 2010, aurait pu choisir Python (c'était la version 2.7, pas trop mal !).

          OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.

          • [^] # Re: Des bonnes idées

            Posté par  . Évalué à 3. Dernière modification le 30/11/20 à 07:21.

            Ils ont tout de même :

            • créé un compilateur PHP vers C++ nommé HIPHOP
            • une machine virtuelle nommée HHMV
            • conçu un feu langage syntaxiquement proche de php nommé hack

            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.

            OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.

            Bon point !

          • [^] # Re: Des bonnes idées

            Posté par  . Évalué à 1.

            OwnCloud a clairement choisi PHP car on ouvre plus d'hébergement LAMP que python, perl ou ruby.

            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  (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  . Évalué à 3.

        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.

        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.

        • [^] # Re: Des bonnes idées

          Posté par  . Évalué à -3.

          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.

          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  (site Web personnel) . Évalué à 5. Dernière modification le 30/11/20 à 08:25.

        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.

        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  . Évalué à 3.

          Je crois que c'est aussi le cas si tu utilise php-fpm il me semble.

        • [^] # Re: Des bonnes idées

          Posté par  . É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  (site Web personnel) . É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  (site Web personnel) . Évalué à 4.

        Ces typages sur des langages interprétés ont tendance plus à m'agacer

        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…).

        améliorer la qualité de produits qui ne peuvent pas changer de techno rapidement.

        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.

        la syntaxe juste imbuvable quand on a connu d'autres choses

        Totalement subjectif. Question de goût.

        l'incapacité de faire de l'asynchrone, de faire autre chose que du web etc.

        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  . Évalué à 3.

          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…).

          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  . Évalué à -3.

          Que sais-tu des besoins et envies des développeurs sur ces projets en PHP, surtout pour les projets internes ?

          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.

          Si un langage satisfait les objectifs de l'application, aucune raison de changer.

          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.

          Totalement subjectif. Question de goût.

          Le goût, ça s'affine.

          Mouai, ça montre surtout que tu ne connais pas bien l'éco-système PHP

          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.

          On peut faire plein d'autres choses que du web.

          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.

          ReactPHP

          Donc c'est pas natif et je sens la blague pour coupler ça avec des frameworks.

          • [^] # Re: Des bonnes idées

            Posté par  . É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.

            • [^] # Re: Des bonnes idées

              Posté par  . Évalué à 3.

              Carton jaune !

              C'est quoi ton problème ? Ta copine t'a trompé avec un développeur PHP au lycée ?

              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  . Évalué à 2. Dernière modification le 30/11/20 à 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…

                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.

                … 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  . Évalué à 0.

                  Je comprends la frustration et le dérapage de barmic…

                  Bof, c'est pas un dérapage mais juste une blague pour moi.

                  … qu'on était inexpérimentés / qu'on se voilait la face.

                  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  . Évalué à 3. Dernière modification le 30/11/20 à 23:31.

                    mais jamais PHP

                    je ne pense pas que ça reste isolé à mon cercle de connaissance

                    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  . Évalué à 3.

                    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).

                    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".

                    • [^] # Re: Des bonnes idées

                      Posté par  . É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.

                      react, angular et vue

                      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  . Évalué à 3.

                        Nginx a remplacé Apache alors que ce dernier était majoritaire par exemple.

                        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  . Évalué à 3.

                        TypeScript et Rust ont a mon sens suffisamment d'arguments pour représenter le futur sans se cacher sous un effet de mode.

                        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).

                        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)

                        Il est question des parts de framework dans le navigateur dans le web publique, c'est bien explicité.

                        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.

                        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.

                        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.

                        C'est pour ça que la démarche de l'almanach est annuelle, ils préparent la nouvelle version.

                      • [^] # Re: Des bonnes idées

                        Posté par  . Évalué à 4.

                        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.

                        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  . Évalué à -1.

                          Un langage de programmation et un serveur web ne sont pas comparables.

                          Tu peux développer ?

                          De la même façon qu'il y a toujours énormément de COBOL qui traine dans le monde financier

                          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.

                          tout réécrire leur code existant (en PHP) dans un autre langage.

                          Y'a plein de moyens de faire des migrations sans se retrouver avec des période de gel de fonctionnalités :

                          • migrer des parties des api qui ont peu d'adhérence avec le reste de l'applicatif
                          • convertir des algos d'une techno à une autre
                          • si le projet est un énorme truc monolithique, il est toujours intéressant de le fractionner en morceaux plus petits et migrer ces mini-projets
                          • passer tous les nouveaux projets dans le nouveau langage

                          De toute façon, des passages de versions qui peuvent être délicates, il faut en faire.

              • [^] # Re: Des bonnes idées

                Posté par  . É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.

          • [^] # Re: Des bonnes idées

            Posté par  . Évalué à 3.

            ReactPHP
            Donc c'est pas natif et je sens la blague pour coupler ça avec des frameworks.

            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 :

            • Ale, l'Asynchronous Lint Engine à coupler avec un serveur LSP
            • comme Phan ou Psalm
            • et toujours le très pratique Xdebug qui permet d'inspecter, debugger, profiler (avec carte des fonctions appelées/appelantes dans kcachegrind). Celui là est là depuis très longtemps mais je suis surpris d'avoir encore à le faire découvrir régulièrement à des stagiaires qui inspectent à coup de var_dump.
            • [^] # Re: Des bonnes idées

              Posté par  . É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  . É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).

                • [^] # Re: Des bonnes idées

                  Posté par  . É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  . É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 ?

                    • [^] # Re: Des bonnes idées

                      Posté par  . É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  . Évalué à 4.

                        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.

                        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.

                        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.

                        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.

                        • [^] # Re: Des bonnes idées

                          Posté par  . É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.

                          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.

                          Tout à fait d'accord, d'ailleurs C# et Rust ont fait la même chose.

                          • [^] # Re: Des bonnes idées

                            Posté par  . Évalué à 3.

                            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.

                            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).

                            Twisted c'est plus une couche réseau à de l'async.

                            C'est précisément ce qui est recherché quand on parle d'asynchrone.

                            • [^] # Re: Des bonnes idées

                              Posté par  . Évalué à -1.

                              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.

                              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 :

                              • asynchronisme : on lance une tache donc on ne connait pas la durée qui va s'exécuter en même temps qu'une autre : par ex, interroger une api.
                              • parallélisation : on veut réduire une tache en la fractionnant en n sous ensembles qui s’exécutent en même temps : par ex convertir une vidéo couleur en n&b : on peut découper la vidéo en 4 morceaux de même durée, appliquer l'algo sur chacun des morceaux et quand tous sont fini on ré-assemble le tout.

                              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).

                              C'est précisément ce qui est recherché quand on parle d'asynchrone.

                              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  . Évalué à 3. Dernière modification le 02/12/20 à 01:00.

                                Je ne suis pas d'accord :)

                                • asynchronisme : on lance une tache donc on ne connait pas la durée qui va s'exécuter en même temps qu'une autre : par ex, interroger une api.
                                • parallélisation : on veut réduire une tache en la fractionnant en n sous ensembles qui s’exécutent en même temps : par ex convertir une vidéo couleur en n&b : on peut découper la vidéo en 4 morceaux de même durée, appliquer l'algo sur chacun des morceaux et quand tous sont fini on ré-assemble le tout.

                                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 ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.

                                Pour la parallélisation oui, pour du réactif les threads et process sont de piètres palliatifs.

                                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.

                                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.

                                Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.

                                La différence est drastique.

                                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.

                                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.

                                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

                                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.

                                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é ?

                                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.


                                1. c'est basé à fond sur epoll(4) pour attendre des évènements sur une série de file descriptor 

                                • [^] # Re: Des bonnes idées

                                  Posté par  . Évalué à 0.

                                  Alors en soit oui…

                                  T'as un peu redis la même chose, non (peut-être mieux je te l'accorde) ?

                                  la multiplication de tes threads ou processus multiplie les commutations de contexte.

                                  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.

                                  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.

                                  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  . Évalué à 3.

                                    T'as un peu redis la même chose, non (peut-être mieux je te l'accorde) ?

                                    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 :

                                    • le premier sert à utiliser toute la puissance des CPU
                                    • le second les greens threads et tout ce qui est IO asynchrones sert à réduire le latence

                                    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.

                                    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)

                                    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.

                                    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.

                                    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.

                                    • [^] # Re: Des bonnes idées

                                      Posté par  . Évalué à 0.

                                      Je voulais signifier que …

                                      Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.

                                      C'est la définition des greens threads donc je sais pas trop quoi dire.

                                      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.

                                      T'a l'air de ne pas trop te fier à wikipedia, donc je te laisse choisir la source qui te plaira.

                                      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  . Évalué à 2.

                                        Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.

                                        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.

                                        Je ne vois pas en quoi ça améliore le context switching.

                                        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.

                                        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)

                                        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.

                                        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.

                                        A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.

                                        • [^] # Re: Des bonnes idées

                                          Posté par  . Évalué à 0.

                                          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.

                                          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  . Évalué à 2. Dernière modification le 06/12/20 à 18:01.

                                            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é.

                                            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.


                                            1. é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) 

                                            • [^] # Re: Des bonnes idées

                                              Posté par  . É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  . Évalué à 2. Dernière modification le 06/12/20 à 19:04.

                                                Je vois plusieurs problème potentiels avec ce code :

                                                • le test dépend de requêtes HTTP externes, ce qui introduit certainement beaucoup de variabilité, potentiellement plus grande que celle entre threads et green threads
                                                • la méthode pour faire ces requêtes n'est pas la même
                                                • tu ne mesures pas vraiment green thread vs thread système, mais asyncio vs threads systèmes en Python. Bon, pas le choix que de tester des implems existantes, mais peut-être que l'asynchrone Python n'est pas très performant par exemple, alors que peut-être que ce n'est pas une limite théorique des green threads (je ne connais pas très bien les green threads ni asyncio cela dit)
                                                • de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests, dans des ordres différents (tu risques de "chauffer" et donc favoriser le deuxième test en exécutant le premier d'une manière ou d'une autre, donc il est important d'alterner les tests)

                                                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 :

                                                • est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?
                                                • est-ce que pour un ensemble de tâches non parallélisables / non parallélisées, on arrive à une meilleure perf avec plusieurs plusieurs green threads sur un seul thread système versus plusieurs threads systèmes sur un seul cœur ?

                                                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  . Évalué à 2.

                                                  Je te rejoins. Je n'ai pas le temps de tester le code, mais j'ajoueterais :

                                                  • quel est l'impact de BeautifulSoup dans ton thread ?
                                                  • tu fais uniquement 3 requêtes ? Tu as combien de core ? Si tu parallélise avec un nombre inférieur ou égale à ton nombre de core tu n'a pas de context switch. Même si tu n'a qu'un seul core tu n'a que 3 context switch
                                                  • je suis pas sûr de voir de lissage dans ton test, même si en soit ça doit plus impacter les threads systèmes

                                                  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.

                                                  est-ce que si on implémente intelligemment les green threads sur plusieurs threads systèmes (éventuellement, en fixant ces threads sur des cœurs), on peut gagner en perf (en utilisant X green threads sur N cœurs versus X threads systèmes sur N cœurs) ?

                                                  C'est précisément ce que fait go par exemple.

                                                • [^] # Re: Des bonnes idées

                                                  Posté par  . Évalué à 0. Dernière modification le 06/12/20 à 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.

                                                  tu ne mesures pas vraiment green thread vs thread système

                                                  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)

                                                  peut-être que l'asynchrone Python n'est pas très performant par exemple

                                                  Mais si d'autre veulent faire une impl dans un autre langage, je suis preneur

                                                  de ce que je comprends du code, tu ne lisses pas les résultats en exécutant plusieurs fois les tests

                                                  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  . Évalué à 2. Dernière modification le 06/12/20 à 23:25.

                                                    le jeu en vaut la chandelle ?

                                                    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 :

                                                    • que mesure-t-on ?
                                                    • que compare-t-on ?
                                                    • quelle définition de green threads utilise-t-on ? (est-ce qu'on prend en compte tous les styles de threads en espace utilisateur possibles, en incluant des choses du style des go-routines, réparties efficacement sur plusieurs threads systèmes, ou se limite-t-on aux green threads de Java, tournant tous sur le même thread système abandonnés dans le début des années 2000 vues les limitations ?)
                                                    • sur quel genre de charge de travail ? (les résultats seront probablement différent si on fait de l'I/O, des opérations bloquantes ou du calcul pur)

                                                    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  . É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.

                                                      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.

                                                      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  . Évalué à 2. Dernière modification le 06/12/20 à 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.

              • [^] # Re: Des bonnes idées

                Posté par  . Évalué à 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)

                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 xyz et 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  (site Web personnel) . Évalué à 4.

            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

            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.

            Non, je ne connais pas bien

            Critiquer un truc qu'on ne connaît pas bien, c'est fort quand même…

            • [^] # Re: Des bonnes idées

              Posté par  . Évalué à 0.

              J'ai 35 ans de programmation derrière moi

              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.

              PHP n'est pas sans défaut, mais de là à le mépriser à ta façon, c'est totalement débile.

              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.

              Critiquer un truc qu'on ne connaît pas bien, c'est fort quand même…

              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.

              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

              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  . Évalué à 3.

                J'ai 35 ans de programmation derrière moi

                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.

                C'est toi qui a lancé l'appel au CV :

                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

                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.

                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".

                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.

                • [^] # Re: Des bonnes idées

                  Posté par  . Évalué à 0.

                  Je vais croire que t'es payé pour répondre pour les autres.

                  Si l'expérience n'est pas un argument ne t'en sert pas toi non plus.

                  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

                  et oui l'histoire retiens que le langage ne fait pas tout

                  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  . Évalué à 2. Dernière modification le 13/12/20 à 12:48.

                    Pour Ada, je suis sur que tu penses à https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

                    Tu fais références à ce passage ?

                    le Centre national d'études spatiales a tout simplement demandé à ne pas effectuer les simulations de vol pour ces appareils, ce qui devait ainsi lui permettre d'économiser 800 000 francs sur le coût des préparatifs avant-lancement. Réalisées en laboratoire après la catastrophe, ces simulations ont justement permis de vérifier que l'explosion était inéluctable

                    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 ?

                    Après enquête, les ingénieurs du CNES se sont aperçus que par mesure d'économie, le logiciel de navigation de la fusée Ariane 5 était celui qui avait été conçu pour Ariane 4, ce qui a induit une incompatibilité entre le logiciel et le matériel.

                    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  . Évalué à -1.

                      Que voulais-tu montrer avec ton lien ?

                      Un exemple de bug à plusieurs millions dev en Ada. Rien de plus, rien de moins.

                      et sinon, une discussion honnête et bienveillante, ça te dit ?

                      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  (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  . É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  . É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  . Évalué à 4.

              je perds sans doute mon temps car personne ne se remettra en question

              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

              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.

              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

              Pas de haine, un désintérêt abyssal.

              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.

              Je comprend pas ce besoin d'améliorer sans cesse

              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  (site Web personnel) . Évalué à 4.

              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…

              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  . Évalué à 0.

                A l'époque de Php3 l'absence de modèle objet était le fer de lance de ceux qui disaient d'oublier Php…

                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.

                C'est très bien mais à l'époque pour avoir Java…

                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 ?

                Aujourd'hui tu explique que l'OO de Php n'est pas meilleurs que celui de Java il y a dix ans…

                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.

                Aujourd'hui Php a à peu à peu coché les cases qui manquaient fait tourner des sites énormes

                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  . Évalué à 4.

                  Je rappel que Java effectue ses contrôles de type à la compilation et produit un bytecode qui est par nature plus rapide à interpréter.

                  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.

                  Mais effectivement, je suis plutôt convaincu que la POO est un mauvais paradigme

                  T'es convaincu de beaucoup de choses j'ai l'impression.

                  C'est un discours difficile à entendre car beaucoup ont perfectionné leurs apprentissages autours de ça (design pattern et autre joyeuseté).

                  Les design pattern ce n'est pas forcément OO, une monade c'est un design pattern par exemple.

                  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.

                  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.

                  • [^] # Re: Des bonnes idées

                    Posté par  . Évalué à -1.

                    … La mesure de performance est loin d'être aussi simpliste.

                    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.

                    T'es convaincu de beaucoup de choses j'ai l'impression.

                    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.

                    Les design pattern ce n'est pas forcément OO, une monade c'est un design pattern par exemple.

                    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  . Évalué à 2.

                      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.

                      Et les opcodes+jit c'est quoi d'après toi ?

                      une mesure de perf sur un algo avec un garbage collector peut être fluctuent alors que sans il est plus prédictible.

                      Le modèle d'exécution de php doit pas mal aider pour ça.

                      Et sinon, @barmic, c'est quoi ton intérêt de défendre cœur et âme PHP ?

                      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.

                      • [^] # Re: Des bonnes idées

                        Posté par  . Évalué à 3.

                        D'ailleurs, tes réponses sont intéressantes !

                      • [^] # Re: Des bonnes idées

                        Posté par  . Évalué à 0.

                        Et les opcodes+jit c'est quoi d'après toi ?

                        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 n'aime pas du tout php.

                        Je m'en doutais.

                        Je n'aime pas le turquoise, ça n'en fais pas une mauvaise couleur.

                        mais si tout le monde s'habillait en turquoise, ça ne te chatouillerais pas de le dire ?

                        Te répondre me donne l'occasion de faire des recherches sur php et python, je trouve ça cool.

                        Tant mieux, on a jamais fini d'apprendre.

                        Je ne vais pas te demander pourquoi tu viens faire une croisade, au mieux c'est juste du troll.

                        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  . Évalué à 3.

                          Je n'aime pas le turquoise, ça n'en fais pas une mauvaise couleur.

                          mais si tout le monde s'habillait en turquoise, ça ne te chatouillerais pas de le dire ?

                          Tu le ressent quand un site est en PHP ? Pas moi. Je n'ai pas particulièrement à expliquer aux gens comment s'habiller.

                          sortez un peu de votre périmètre de confort et arrêtez de jouer avec votre nombril !

                          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.

                          • [^] # Re: Des bonnes idées

                            Posté par  . Évalué à -2. Dernière modification le 01/12/20 à 15:26.

                            Tu le ressent quand un site est en PHP ?

                            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.

                            Il me semble bien moins confortable et nombriliste d'avoir un regard curieux

                            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  . Évalué à 2.

                        Le modèle d'exécution de php doit pas mal aider pour ça.

                        D'ailleurs je me demande comment un truc comme PHP-PM se comporte.

        • [^] # Re: Des bonnes idées

          Posté par  . Évalué à 8.

          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.

          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  . Évalué à 3.

        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.

        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  . Évalué à -1.

          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.

          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.

          Apres, l'inference de type, c'est pas fait pour les chiens

          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  . Évalué à 2.

            mais j'identifierais le soucis rapidement

            Oui, alors ca, c’est très discutable.

            Du coup, le typage a un rôle bien moins important.

            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.

            D'ailleurs, cite moi des langages interprétés qui font vraiment de l'inférence

            ??
            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  . Évalué à 0.

              Oui, alors ca, c’est très discutable.

              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.

              Foutaises. Le typage te dit « ton code est cassé », au moment ou tu l’écris, pas plus tard, quand tu le fais tourner.

              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  . Évalué à 2.

                Pour moi, pas besoin de sortir le bazooka pour tuer une mouche

                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  (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  . Évalué à 0.

              Ex, en C#, tu écris une fonction, ça donne un truc du genre :

              public int mafonction(MaSuperClass monobjet, string text, int num) { ... }
              Ou je dois préciser les types en entrée et en sortie.
              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):
              ...
              Tout ça pour dire que l'inférence c'est bien pour réduire du code rébarbatif mais ça simplifie pas tout et c'est pas non plus "magique".
              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  . É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  . É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.

                • [^] # Re: Des bonnes idées

                  Posté par  . É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  (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  . É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  . É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)

          Et au contraire, le mieux est de s'assurer du bon type d'une variable le plus tôt possible…

          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.

          c'est à mon avis que tu as raté quelque chose à l'écriture.

          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

          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.

          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  (site Web personnel) . Évalué à 2.

            Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut […]

            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 bien 1 + '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  . Évalué à 4.

              Tout à fait. De plus :

              voir de faire du duck typing

              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.


              1. En langage récent qui en fait il y a go et typescript (c'est d'ailleurs extrêmement pertinent pour lui). 

              • [^] # Re: Des bonnes idées

                Posté par  . Évalué à 0.

                Non python ne fais pas du duck typing quand ça l'arrange

                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  . Évalué à 2.

                  En quoi trouves-tu que le duck-typing soit pertinent pour TypeScript ?

                  Pour s'interfacer avec un langage à prototype comme l'est javascript, ça me semble être la meilleure solution.

                  • [^] # Re: Des bonnes idées

                    Posté par  . É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  . Évalué à 2.

                      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.

                      Ç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 ?

                      • [^] # Re: Des bonnes idées

                        Posté par  . É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  . É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  . Évalué à 2.

                Bref, y'a plein de raisons pour moi (duck-typing compris) pour ne pas le classer dans les typages fort.

                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.

                • [^] # Re: Des bonnes idées

                  Posté par  . É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  (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  . É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  (site Web personnel) . Évalué à 9.

    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].

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.