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.
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.
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.
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…
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.
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.
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)
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.
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
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.
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é.
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 !
Le concept (Darcs) et l'implémentation sont vraiment intéressants! En espérant qu'il trouve ça place dans le milieu des DVCS écrasé par le (trop) populaire git.
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.
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.
… 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 ?
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.
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.
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 ?
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.
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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Avec des entry points sur des trucs simples et du mapping (clairement des trucs un peu dégeu mais au moins isolés) sur du plus compliqué.
Après, sur les projets sur lequel j'ai utilisé, j'ai fait en sorte d'utiliser le moins de libs js possibles.
Ma connaissance de Typescript est plus anecdotique mais je suis pas certain qu'ils font réellement mieux. La plupart des projets sont réécris intégralement en Typescript, pas de demi-mesure.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.
Moi, ce que j'en comprend c'est que c'est géré par le runtime du langage (et non par l'OS) et que c'est en espace utilisateur.
Ce dernier point permet de gagner de la souplesse (pas de lock) et j'imagine de la sécurité.
Je ne vois pas en quoi ça améliore le context switching. D'après https://en.wikipedia.org/wiki/Green_threads#Performance, c'est même l'inverse et ça me parait logique vu que c'est une couche d’abstraction en plus et que ça ne tiens pas en compte du matériel (mono CPU et pas de prise en compte du multi-threading physique)
Après, entre la définition (d'ailleurs chaque langage a un peu son nom a lui), l'implémentation (pareil, très fluctuent) et ce que ça fait réellement.
J'essai de diversifier mes sources et pas faire une confiance aveugle au premier résultat un tant soit peu pertinent.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Ca ne tournera pas comme je veux mais j'identifierais le soucis rapidement donc ça ne me gênera pas outre mesure.
La diff entre un petit projet, un POC, un script en one shot etc c'est que justement t'as peu de maintenance, d'exigence qualité etc. Du coup, le typage a un rôle bien moins important.
Oui, l'inférence c'est cool mais bon c'est loin de gommer toute la lourdeur.
Rien que le typage dans les signatures de méthodes, j'ai pas envie de mes taper quand je veux juste faire un truc vite.
D'ailleurs, cite moi des langages interprétés qui font vraiment de l'inférence : doit pas y avoir grand monde car ça doit bien ralentir au runtime…
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
T'as un peu redis la même chose, non (peut-être mieux je te l'accorde) ?
La commutation de contexte est surtout pénalisante quand celle-ci est lente donc les threads sont pour le coup bien moins handicapant que les processus. (qui en plus différent d'un OS à l'autre)
Tu as l'air de suggérer que les green threads n'auraient pas ce genre de soucis. (commutation de contexte)
Ça me parait tout à fait infondé et je suis curieux d'avoir des sources sur les propos avancés.
Bon Dieu non, je pensais plutôt à une requête et derrière du parallélisme (la requête ça peut être "applique un filtre à l'image que je t'ai envoyé précédemment"), un script lancé par un cron etc.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Tu pinailles, là. A la base, je dissociais des types simples (int, float, string) aux objets.
En effet, Python utilise toujours du Duck-typing (si ça fait coincoin, c'est que c'est un canard) et du EAFP.
En quoi trouves-tu que le duck-typing soit pertinent pour TypeScript ?
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Je pense que ça dépend du contexte. Si tu travailles sur des petits projets (ou tu as la capacité d'avoir une vue globale) pas trop exigeants, avec des algos simples, pourquoi pas.
Je dis tjs qu'un typage fin c'est une paire de tests unitaires "gratuits". (sur Python, par ex, j'aurais tendance à mettre des tests unitaires là ou j'en aurais pas le besoin sur d'autres langages)
Dans le cadre de la création pure, ça peut se tenir.
En revanche, dès que tu fais des modifs profondes : suppression de code, refactoring, changement de types, passage d'une lib à une autre etc.
C'est juste trop gros, pour que tu puisses juste t'appuyer uniquement sur ton IDE.
90% des bugs c'est des ratés dans l'écriture.
Si on codait tous parfaitement du 1er coup, y'aurais jamais de débugage.
Et puis, plus il y a de legacy, d'autres devs et
Python est un langage faiblement typé et qui a tendance justement à caster implicitement quand il peut (voir de faire du duck typing) donc foncièrement tu vas te retrouver avec moins d'erreurs de ce genre.
Enfin, ça c'est le sentiment. La réalité pour celui qui vient d'un langage fortement typé c'est que plein de choses sont nommé autrement (mais le soucis reste le même).
Si tu as supprimé un paramètre d'une fonction et que tu as oublié de l'enlever dans un appel, c'est un soucis de type pour moi car la signature de ta fonction a changé.
Par ex, en C# une fonction peut être passé dans une variable (un callback en somme) et du coup, la même fonction mais avec des signatures différentes seront des types distincts.
Tiens d'ailleurs : imagine que quelqu'un modifie la signature d'une fonction et push son travail.
Parallèlement à ça, je fais un appel avec l'ancienne signature : j'aurais pas de conflit au merge et y'aura un bug à l’exécution : pourtant j'ai été attentif et j'ai quand même un soucis.
Si t'as un bug lié à un oubli de try/catch c'est parce que tu n'as pas géré un "type" d'erreur.
Si tu fais un if/else sur un enum et que tu oublis un cas (ou plus fourbe, que t'as rajouté une entrée dans ton enum sans identifié minutieusement tous les endroits ou c'est appelé), tu te retrouves avec des cas non traités lié à un changement de type.
Bref, les exemples sont légion.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Oula, bcp de notions qui se recoupent.
Tu sais sans doute ce qui précède mais je préférer formaliser les choses plutôt que d'avoir des quiproquos.
J'essai de distinguer 2 notions :
Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.
La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.
Pour ça, la technique jusqu'à il y a une dizaine d'année était de mettre un verrou sur des données le temps qu'on y touche puis de libérer ce verrou. (avec tous les autres problèmes qu'il soulève : si on libère jamais le verrou)
Puis on a eu les green thread, qui est grosso modo un algo qui fait ça tout seul sans qu'on s'en soucis.
Bien entendu, dès qu'on peut utiliser les green thread à la place des thread, il faut le faire car on se protège de tous les pièges cités.
Et si on peut passer par des green thread à la place de process, on y gagne aussi niveau ressources… et c'est pour ça qu'il y a pas mal de hype autours.
Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.
Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.
Le projet Servo (navigateur expérimental longtemps supporté par Mozilla et qui est passé il y a 1 mois dans les mains de la Linux Fondation) remplace ces process par des green threads.
Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process :
entre occupation mémoire et sécurité.
Bcp de projets font par ex le choix de partir sur des process (le petit projet qui démarre et qui n'a pas bcp de hits) puis passe par une phase d'optimisation ou ils remplacent.
(on gagne en utilisateurs, on peut perfectionner au lieu de gonfler le serveur)
Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?
On peut en faire mais ça passe par des libs PECL si je ne me trompe pas donc c'est pas natif.
Python, tout ça est natif depuis longtemps, sauf les green thread ou l'ajout date de 2014 dans la 3.4 et les mots clés await/async dans la version suivante.
Pour ce qui est du GIL, c'est une limitation de Python qui empêche le gain de parallélisme sur les thread (green thread compris) car il ne va s’exécuter que sur un processeur.
En gros, pour mon exemple sur les vidéos, le temps sera plus long pour traiter mon image avec des threads que sans.
C'est un sujet qui revient souvent sur le tapis mais qui nécessiterais une refacto profonde du code de Python (ou plus précisément CPython) dev en C.
Des autres implémentations de Python (mais en retard sur l'implémentation officiel) n'ont pas cette problématique tel qu'une version expérimental de Pypy (voir https://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for).
Dans la logique web oui mais bon Twisted permet principalement de simplifier avec du sucre syntaxique et des apis dédié pour faire du curl, du ftp, ssh, pop, imap etc.
Du coup, ça présente moins d'intérêt en natif
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
héhé, le bug qui coûtent très cher.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Tu peux développer ?
Y'a des outils de parsing avec de l'AST qui permettent de convertir du COBOL en d'autres langages. Ca remplacera sans doute jamais une migration "humaine" au niveau "lisibilité mais ça marche sans bugs donc faute de mieux, c'est de plus en plus courant.
Y'a plein de moyens de faire des migrations sans se retrouver avec des période de gel de fonctionnalités :
De toute façon, des passages de versions qui peuvent être délicates, il faut en faire.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -2. Dernière modification le 01 décembre 2020 à 15:26.
Aha, quand j'ai une erreur PHP visible sur un site, oui mais là n'est pas la question : ce qui m'agace c'est plus quand j'ai à créer ou modifier un site en PHP.
J'ai accordé suffisamment de crédit à la curiosité : je suis passé par la lassitude et le désenchantement.
Il y a assez d'autres technos pour assouvir ma curiosité.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
C'est de l'intermédiaire.
Compare un algo simple en C et en PHP et fait un bench rapide dessus… tu risques de voir quelques diff. (mais ça veut pas forcément dire que c'est mauvais)
Le premier hit est plus coûteux que les autres.
Dans certains cas, c'est bien, d'en d'autres non (si t'as du cache après le premier hit, ça sert à rien)
Je m'en doutais.
mais si tout le monde s'habillait en turquoise, ça ne te chatouillerais pas de le dire ?
Tant mieux, on a jamais fini d'apprendre.
C'est assez simple, j'ai fait une expérience pro en PHP/Symphony alors que je faisais précédemment du .net et j'ai eu l'impression de faire un saut 10 ans en arrière.
Bien évidement, pour ceux qui n'ont fait que ça, tout est merveilleux.
Pareil, je participe à des projets libres (Primtux principalement) avec des softs devs dans des technos hétérogènes et à chaque fois que je tombe sur du PHP, du Perl ou des scripts sh (à distinguer avec des instructions en cli) ça m'épuise de médiocrité.
Du coup, voilà : en règle général, je passe mon chemin mais là j'avais envie de pousser une gueulante : sortez un peu de votre périmètre de confort et arrêtez de jouer avec votre nombril !
# Sympa
Posté par mothsART . En réponse au journal Pijul, version 1.0 en approche. Évalué à 4. Dernière modification le 01 décembre 2020 à 14:00.
Le concept (Darcs) et l'implémentation sont vraiment intéressants! En espérant qu'il trouve ça place dans le milieu des DVCS écrasé par le (trop) populaire git.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 1.
asyncio c'est plus du "green threading" mais y'avait déjà la possibilité de faire des thread avec verrou ou du multiprocessing bien avant.
Twisted c'est plus une couche réseau à de l'async.
Flask ne fait pas d'async.
Tout à fait d'accord, d'ailleurs C# et Rust ont fait la même chose.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
J'essai de dissocier hype et réelles évolutions techniques.
A l'époque de la hype nodejs, je ne suis pas laissé embarqué parce que je considérais que c'était pour plein d'aspects un effet de mode sans réel fondement technique.
TypeScript et Rust ont a mon sens suffisamment d'arguments pour représenter le futur sans se cacher sous un effet de mode.
Les exemples sur les % de sites ne me paraissent pas pertinent.
C'est pas parce que le marché actuel est saturé d'une techno que ça veut dire qu'il ne faut pas changer.
Nginx a remplacé Apache alors que ce dernier était majoritaire par exemple.
Ça c'est opéré principalement pour des raisons techniques.
Après, on sait bien que derrière plein de boites, c'est pas vraiment l'aspect "technique" qui prime mais d'avantage l'aspect financier (et des investissements sur le court terme).
Ça explique (à mon sens) qu'il y ai autant de différence entre la demande du marché, les raisons objectives et les envies des développeurs.
Ces technos sont faites pour des web apps, pas vraiment des sites web. (par exemple, wikipédia, des sites vitrines en wordpress n'en ont a pas besoin)
Pleins de boites vont faire des apps webs sans que ça soit forcément visibles (intranet par exemple) donc ça représente une partie de l'iceberg.
Enfin, faudrait plus un indicateur sur les nouveaux sites et ceux refondus car le web a un peu d'histoire et effectivement tu remplaces pas 20 ans de vanilla JS/jquery par d'autres frameworks en un coup de baguette.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Je sais tout ça et c'est effectivement une facilité de reprocher un argumentaire car j'ai pris quelques raccourcis.
On va dire qu'il y a quand même des grandes lignes dans les performances :
un algo compilé en instructions natives sera plus rapide que de l'interprété.
c'est le ratio entre les 2 qui est difficile (voir impossible) à déterminer.
une mesure de perf sur un algo avec un garbage collector peut être fluctuent alors que sans il est plus prédictible.
Je pense me remettre suffisamment en question mais ça n'interdit pas d'avoir des opinions.
J'essai de tirer des conclusions de mes expériences et je trouve que la POO a tendance à figer pas mal de choses.
Par exemple, je pense que PHP a introduit la notion de trait pour justement donner plus de souplesse.
Tu joues avec les mots, je parlais de DP POO.
Et sinon, @barmic, c'est quoi ton intérêt de défendre cœur et âme PHP ?
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Ben oui et je pense que c'est la même raison : PHP c'est bien pour des petits projets, pourquoi vouloir changer sa nature pour ressembler à quelque chose qu'il n'est pas.
Sa nature pour moi, c'était de faire du dynamique facilement sans avoir de connaissances en typage, en POO etc.
Bref, une courbe d'apprentissage rapide. (C'était un bon premier langage pour s'initier à la prog ou pour des personnes qui ne sont pas du métier.)
Si on regarde, il n'y a plus grand chose de ce genre qui existe : que des langages pour du pro (et expérimenté) et je trouve ça dommage.
En plus, une gamme de mots clés de plus en plus vaste.
J'imagine le débutant en PHP 8 qui va avoir des matchs et des switch dans le même applicatif… quelle tristesse.
Du coup, pour moi, le PHP va de moins en moins attirer les débutants car de plus en plus complexe et encore moins attirer les plus aguéris car d'autres langages sont mieux équipés et plus restreint dans leur syntaxe : en Rust, on a que les match, y'aura jamais de switch, en Python, pas de switch, que des if.
Je suis dac, les hébergeurs ont poussés pas mal à rester sur PHP car dès qu'on voulait utiliser un autre langage, fallait sortir le porte-feuille.
Perso, déjà il y a 10 ans j'arrivais à faire du web sans PHP.
Mais, un autre temps, d'autres combats.
Sauf que si l'évolution de Php tend à résoudre des soucis d'il 10 ans, il n'est donc plus adapté aux problématiques actuelles ?
On peut dire que le code de PHP actuelle ressemble à s'y m'éprendre à Java d'il y a 10 ans mais est encore en deçà au niveau qualité et rapidité.
Je rappel que Java effectue ses contrôles de type à la compilation et produit un bytecode qui est par nature plus rapide à interpréter.
Mais effectivement, je suis plutôt convaincu que la POO est un mauvais paradigme et qu'il y a des amalgames entre certaines choses utilisés dans des langages full POO qui n'est pas forcément de la POO (espace de noms, chaînage des appels, généricité, encapsulation etc.)
C'est un discours difficile à entendre car beaucoup ont perfectionné leurs apprentissages autours de ça (design pattern et autre joyeuseté).
J'ai moi même essayé de m'y accrocher pendant plusieurs années avant de m'y résoudre.
Je suis de loin pas convaincu.
Dans ces sites, c'est plus l'infra autours qui va faire la diff : load balancer, varnish, logstash, worflow autours de Git etc.
Tout ça a évolué très vite (le front aussi) mais pas vraiment PHP.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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: Similaire à NixOS
Posté par mothsART . En réponse à la dépêche GNU Guix 1.2.0 est publié. Évalué à 1.
C'est déjà bien de le reconnaître.
Le fait d'avoir réfléchit à un outil graphique compense (ça manque cruellement dans Nix).
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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 mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 0.
Bof, c'est pas un dérapage mais juste une blague pour moi.
C'est pas une atteinte perso, juste une constatation.
Je parle avec plein de devs et bon le sujet du "meilleur langage" (c'est des discussion de comptoirs donc effectivement c'est toujours un peu excessif) retombe souvent sur la table.
Néanmoins, y'a des trucs récurrents qui reviennent : Python, Scala, Haskell, Rust, TypeScript mais jamais PHP (pourtant, beaucoup d'eux l'utilise à titre pro).
Tous ne savent pas formaliser pourquoi mais le constat est là : personne n'attend rien de PHP et je ne pense pas que ça reste isolé à mon cercle de connaissance.
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. É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.