Discussion :

[Gugelhupf]

@bouchery

L'Unicode dégrade surement les performances mais comment font les autres technos dans ce cas ?

Là où je veux en venir c'est :

• Il n'y a pas que les anglo-saxons qui font du PHP.
• Le web est un domaine très vaste, une techno dédié au web qui ne gère pas l'Unicode est un peu paradoxale.
• PHP est loin d'être la techno la plus performante (cf : d'après ce benchmark) donc autant gérer l'Unicode.
• Tu apportes des solutions mais n'est-ce pas un peu "bidouille" pour un langage de haut niveau ?

[Zefling]

@bouchery

L'Unicode dégrade surement les performances mais comment font les autres technos dans ce cas ?

Là où je veux en venir c'est :

• Il n'y a pas que les anglo-saxons qui font du PHP.
• Le web est un domaine très vaste, une techno dédié au web qui ne gère pas l'Unicode est un peu paradoxale.
• PHP est loin d'être la techno la plus performante (cf : d'après ce benchmark) donc autant gérer l'Unicode.
• Tu apportes des solutions mais n'est-ce pas un peu "bidouille" pour un langage de haut niveau ?

Il me semble que les langages travaillent en interne en UTF-16 (du moins pour ceux que j'avais vu) pour éviter les baisses de perfs, par contre ça mange plus de RAM.

[DonQuiche]

Il me semble que les langages travaillent en interne en UTF-16 (du moins pour ceux que j'avais vu) pour éviter les baisses de perfs, par contre ça mange plus de RAM.

Oui et non. En fait utf-16 était un choix contestable fait aux débuts de Windows et c'est de là que plusieurs langages l'ont adopté pour pouvoir communiquer rapidement avec Windows.

Mais, hormis le cas de la compatibilité Windows, utf-16 ne se justifie pas par les performances : par rapport à utf-8 les gains sont plutôt marginaux dans les cas extrêmes (pur texte chinois) et compensés par des pertes dans la plupart des cas (texte anglais ou européen, ou même page html chinoise). En fait la vraie raison du choix de MS (et d'autres) fut de pouvoir gérer de façon simpliste mais incorrecte les chaînes de caractères sans causer "trop" de bogues (on traite chaque paire d'octets comme un caractère et basta). A l'époque MS a trouvé ça satisfaisant, ce qui explique qu'encore récemment il fallait appuyer deux fois sur backspace pour supprimer certains caractères.

Aujourd'hui il existe même une page web assez populaire dédiée à l'éradication d'utf-16, prônant l'usage principal d'utf-8, et éventuellement d'utf-32 pour certains traitements internes. Leurs arguments sont d'ailleurs assez pertinents. Les nouveaux langages semblent quant à eux adopter utf-8, même si Rust avait d'abord opté pour du 32.

Cela dit même en utf-32 on ne peut souvent pas traiter chaque élément comme un caractère : il existe des éléments non-visuels, des éléments complétant le caractère suivant (élément accent aigu, aides à la lecture sous les caractères en japonais), etc. Il n'y a tout simplement pas d'alternative au fait de se plonger sérieusement dans unicode, ses normalisations et tout ce qui l'accompagne. D'où l'intérêt d'avoir de solides bibliothèques pour faire abstraction de tout ça lorsque de telles abstractions sont possibles. Unicode est un sujet suffisamment complexe et méconnu pour nécessiter une prise en charge simple et extensive par le langage.

[leomath]

Comment peut-on parler des subtilités d'un langage de programmation, quand on n'est capable d'écrire sa propre langue ?
16 fautes d'orthographe ou de syntaxe en quelques lignes et en plus c'est un expert !
Oui, PHP est permissif, comme le Français ... mais on peut écrire un programme en PHP proprement.
PHP n'est qu'un langage de programmation, il ne sert à traduire que des algorithmes stricts écrits en métalangage.

[RyzenOC]

Comment peut-on parler des subtilités d'un langage de programmation, quand on n'est capable d'écrire sa propre langue ?
16 fautes d'orthographe ou de syntaxe en quelques lignes et en plus c'est un expert !

Aujourd’hui les fautes d'orthographes, tous le monde en fait, il faut vivre avec.
J'ai jamais trop compris l’intérêt de ce genre de remarques qui n'apporte rien au débat.

Le meilleur moyen de ne plus faire de faute, serait de faire une nouvelle version du français (V2.0), plus permissive et sans exception. Malheureusement, les personnes qui sont a l'académie Francaise

[Spartacusply]

16 fautes d'orthographe ou de syntaxe en quelques lignes et en plus c'est un expert !

Personnellement moi je les vois pas, je trouve ça plutôt pas mal écrit, avec accents et tout ce qui va bien.

J'ai jamais trop compris l’intérêt de ce genre de remarques qui n'apporte rien au débat.

Tout à fait d'accord, de toutes façons, cette remarque n'apporte rien au débat.

Le meilleur moyen de ne plus faire de faute, serait de faire une nouvelle version du français (V2.0), plus permissive et sans exception. Malheureusement, les personnes qui sont a l'académie Francaise

Là par contre (même si c'est pas le sujet), je suis complètement opposé à cette idée. Le français est une richesse pour la France et pour les français qu'il nous faut à tout prix préserver. Le massacrer ne servirait en rien sa cause.

[bouchery]

J'ai justement fait une conf sur ce sujet :

[agripp]

Php évolue, mais ne se "révolutionne pas", ce n'est pas parce qu'un hébergeur a sauté ou téléchargé une mise à jour que les programmes plantent, ou si c'est le cas, la remise en route ne demande en général que des modifications mineures. Par ailleurs, la permissivité du langage n'empêche nullement de programmer avec rigueur.
D'ailleurs tirer parti de la permissivité est dangereux, par exemple php convertit automatiquement une chaine numérique en nombre, sauf sur certaines machines, il est donc prudent d'utiliser la fonction intval même si on peut s'en passer la plupart du temps... Personnellement j'apprécie beaucoup ce langage et j'attend la version 7 avec impatience .

[zoeus]

Php est très bon comme langage, mais il n'est pas autonome, il devait pouvoir gérer les événements. Ça sera super. On doit pouvoir se passer de js pour les événements

[RyzenOC]

Php est très bon comme langage, mais il n'est pas autonome, il devait pouvoir gérer les événements. Ça sera super. On doit pouvoir se passer de js pour les événements

Faudrais que les navigateurs le supporte nativement dans ce cas ?

PHP n'a jamais été conçue pour ca, c'est pas sont but, aucun langage serveur d'ailleurs (a part Node.JS ) ne fait cela.