[F] high-tech » PHP et autres langages - Page 3

(déjà que développer avec faut être motivé, alors le développer... )

J'en vois au moins une : pour forcer le changement d'habitudes (genre le coup sur ereg il me semble), ils préfèrent "dupliquer" pour à terme rendre "obsolète" l'ancienne version...

La réponse est assez simple : il y a plein d'extensions PHP qui sont devenues natives "en lot", alors qu'elles ont débord été développées séparément (par Zend, sur PEAR, etc.). Quand leur intégration a été faite, ça s'est fait "à la bourrin", sans réflexion sur l'existant. A présent, on en crève (typiquement, c'est pareil avec les fonction multibytes).

Meowcate (./52) :
Mais en définitive, le langage PHP est-il pleinement fonctionnel (et complexe dans sa diversité) ou simplement mauvais ? en somme, l'usage d'un framework (j'ai fait un peu de PRADO, maintenant sous CakePHP) qui ne fait qu'exploiter PHP pour en rendre les tâches de développement avec ce langage plus simple est-il une bonne solution ou faut-il vraiment oublier PHP (et par ricochet, ses frameworks) et partir plutôt sur un langage comme Python ou Rails ?

rails n'étant pas un langage, pour autant que je sache, mais un framework Ruby

Pour faire du PHP quelque chose comme 40h par semaine depuis plusieurs années, et réussir à en faire ce que je veux / ce dont j'ai / mes collègues / clients ont besoin, PHP est "suffisament fonctionnel".
Après, "pleinement fonctionnel", c'est vague : au final, quelque soit le langage, ce n'est pas le rôle du langage que de répondre à 100% de tes besoins ; le rôle du langage est de fournir les briques permettant de construire ce dont tu as besoin -- quitte à utiliser des bibliothèques / frameworks existant, qui ne sont que d'autres briques d'un niveau plus élevé, t'évitant de réinventer la roue (en risquant de la faisant carrée).

Meowcate (./57) :
Je comprends néanmoins les prises de tête quand un collègue dit à un autre d'utiliser strpos pour vérifier si un mot existe dans une phrase, et qu'à vérifier la fonction sur la doc il y a une fonction "strripos" pour exactement la même tâche, mais en version case-insensitive. Réécrire strpos avec un paramètre optionnel pour la gestion du case n'aurait pas été préférable ?

Deux choses, là dessus :
- il y a un brin d'historique : en C, majuscules et minuscules ne sont pas la même lettre.
- deux chaines qui n'ont pas la même casse ne sont pas "égales", en informatique ; strpos et stripos faisant deux choses distinctes, plutôt que de rajouter un paramètre (puis un autre, puis encore un autre, et encore encore un autre au fur et à mesure des cas venant se rajouter), autant avoir deux fonctions distinctes.

Et une troisième pour la route et pour raler :
- quid de l'unicode (en fait, strpos travaille sur des octets, et pas des caractères... un des vrais gros défauts de PHP)
- tu peux aussi ajouter ce qui est collation / locale : un "é" est-il la même chose qu'un "e" ? Et dans une autre langue que le français ? Voire même des cas tordus où un caractère peut être assimilé à plusieurs autres caractères (je pense au "B" de l'allemand, qui, si ma mémoire est bonne, peut revenir au même que "ss" dans certains cas ? ) ? Voire des cas encore plus tordus où un caractère représente un mot ? une idée ?
- un autre "problème" de PHP c'est que tu as stripos pour chercher la position d'une sous-chaine dans une chaine en case-insentive ; alors que tu as strcasecmp pour comparer deux chaines en case-insensitive \o/

vince (./58) :
C'est ce qu'on (ici) appelle le dév golgotha : on empile des petites merdes patch par patch pour au final obtenir un truc monstrueux mais qui se tient à peu près...

Au niveau du langage, tu n'y peux malheureusement pas grand chose
Au niveau de ton code à toi / du code des applis que tu maintient, à toi de reworker le code pourri pour l'améliorer -- ce qui ne correspond pas forcément à un esprit SSII, mais est tout plus facilement envisageable dans d'autres contextes.

vince (./62) :
pour forcer le changement d'habitudes (genre le coup sur ereg il me semble), ils préfèrent "dupliquer" pour à terme rendre "obsolète" l'ancienne version...

Au niveau des ereg vs preg, la fonctionnalité n'est pas la même, la syntaxe des expressions rationnelles n'est pas la même non plus.
Les preg étant plus abouties, déprécier les ereg est la chose à faire, pour que les développeurs cessent peu à peu de les utiliser (utiliser des preg pour les nouveaux développements est la chose à faire, en l'occurence).
Ce mécanisme de "on déprécie dans la version N, et on supprimera dans la version N+1" est plutôt une bonne approche : ça laisse aux développeurs le temps de migrer doucement -- tout en ayant des avertissements sur ce qui est à revoir.

Nil (./54) :
Meow > Concrètement, le PHP souffre globalement (et sans troller) des mêmes problèmes de base que le C/C++ : ce sont deux langages qui ont été radicalement transformés entre leur première version et les versions actuelles. Contrairement au Java ou ("mieux" encore, en terme de réflexion initiale sur le langage) à la technologie .NET, qui ont été pensés dans une direction donnée et s'y sont maintenus, le PHP et le C sont des langages qu'on a voulu faire évoluer au maximum tout en les laissant au plus compatibles avec les versions précédentes. On a donc des technologies assez bâtardes, mais qui permettent de faire plein de choses à plein de niveaux (bon, avec le C, on a quand même des éléments structurants qu'on n'a pas en PHP, donc ça reste quand même un peu plus compliqué à appréhender que le PHP, sans compter tout ce qui est accès mémoire, typage, etc.).

On trouve tout de même dans le PHP beaucoup plus de problèmes de conceptions que dans le C
Notamment au niveau de la comparaison (un point de détail, presque jamais utilisé)...

echo ("123e3" == 123000) ? "OK\n" : "KO\n";
echo (123000 == 0123000) ? "OK\n" : "KO\n";
echo ("123e3" == "123000") ? "OK\n" : "KO\n";
echo (123e3 == "123000") ? "OK\n" : "KO\n";
echo (123 == "123foo")   ? "OK\n" : "KO\n";
echo ("0123000" == 123000) ? "OK\n" : "KO\n";

Jeu quelle est le résultat ?

flanker (./65) :
Notamment au niveau de la comparaison (un point de détail, presque jamais utilisé)...

que je sache, le comportement de l'opérateur == est documenté, y compris au niveau des conversions qu'il peut entrainer.
à toi de ne pas utiliser == à tord et à travers, et d'utiliser === quand tu considères que c'est plus judicieux

oué, bon, ok, de temps en temps il m'arrive encore de me faire avoir ^^ surtout avec des trucs à la *** genre in_array qui est en mode non-strict par défaut

Mais à quoi sert le ==, du coup ?
Quel est l'intérêt d'avoir une égalité du type "123e3" == 123000 == "0123000" != 0123000 ?

à comparer
quand tu veux que des valeurs plus ou moins égales soient considérées comme égales, plus ou moins indépendamment de leurs types (désolé
)

Tu veux dire que PHP est conçu pour plus ou moins programmer ?

plus ou moins, oui

flanker (./69) :
Tu veux dire que PHP est conçu pour plus ou moins programmer ?

plus ou moins "conçu", déjà ^^ cela dit, il y a certainement plus de réflexion maintenant qu'il y a quelques années, heureusement.
Quant à "programmer"... à la base, c'était pas vraiment fait (j'ai pas dit conçu ^^ ) pour programmer ; les premières pages web que j'ai fait avec un peu de PHP dedans (et encore, ça devait être en PHP 3 -- autrement dit, j'ai jamais touchéà PHP/FI), c'était loin d'être des "programmes" du genre des applis sur lesquelles j'ai bossé depuis quelques années ; et il reste, plus ou moins heureusement, un fond d'historique...
Heureusement, ça en est tout de même arrivé à un point, aujourd'hui, où ça permet de développer de façon relativement confortable (PHP 5.2 est à peu près correct ; PHP 5.3 a apporté quelques points forts intéressants ; PHP 5.4 c'est trop jeune pour que j'en parle) -- et, finalement, chaque fois où je me dis "php c'est de la merde", c'est à cause de détails à la con, généralement au niveau de la bibliothèque standard (fonctions "de base", extensions "de base", extensions "usuelles", et SPL, le tout confondus), et rarement à cause du langage en lui-même

mais comparé à un autre langage (Python ou Ruby), PHP a-t-il vraiment des avantages ?

J'ai fait pas mal de PHP il y a quelques années, maintenant je maîtrise pas mal Python, et autant je vois des points positifs à Python, autant je n'en vois pas des masses à PHP..

faut vraiment que je me mette à Python, histoire de pouvoir comparer un peu -- d'autant plus que tu n'es pas le seul que je connaise à dire ça.

Si tu n'es pas pressé, attends peut-être que Django soit passé à Python 3 ^^

Python 3 amène un certain nombre d'incompatibilités syntaxiques (heureusement que la plupart sont résolues avec l'outil 2to3), mais il amène quelques améliorations bien pratiques. À mes yeux, la plus importante est la fin de la mixité ASCII et Unicode (il y avait un type de chaînes ASCII et un type de chaînes Unicode, parfois ça posait des problèmes) vu que l'ASCII est complètement viré.

On en est à Django 1.4, et la 1.5 devrait amener la compatibilité Python 3.3.

flanker (./74) :
Si tu n'es pas pressé, attends peut-être que Django soit passé à Python 3 ^^

j'ai déjà entendu ça avec PHP 6 ; et avec Perl 6 aussi, il fut un temps (cf ma signature, que je n'ai pas changé depuis l'époque -- j'ai arrếté de suivre, Perl, par contre...)

flanker (./74) :
la fin de la mixité ASCII et Unicode

ah, ça aussi, ça rappellerait presque PHP 6 -- et c'est pas en bien

La situation est tout de même bien différente
Python 3 existe depuis longtemps (ils en sont à Python 3.3 en dev, 3.2 en stable) mais quelques grosses libs ne sont pas encore compatibles ( ), ce qui fait que beaucoup restent en Python 2.6+.

Fondamentalement, Python 3 n'apporte rien au niveau de la gestion de l'Unicode, mais au contraire retire les chaînes ASCII du circuit, ainsi que le préfixe u ("toto" == ASCII et u"toto" == unicode en Python 2, "toto" == unicode en Python 3). Du coup, la plupart des problèmes avec de l'Unicode (souvent à cause d'un préfixe u oublié dans un coin de code rarement appelé) disparaissent magiquement. Comme je trouve que c'était LE problème de Python, je suis plutôt content ^^

flanker (./76) :
Python 3 existe depuis longtemps (ils en sont à Python 3.3 en dev, 3.2 en stable) [...]ce qui fait que beaucoup restent en Python 2.6+.

j'ai fait l'apt-cache search après avoir lu ton post précédent, et j'ai vu que j'avais 3.2 à dispo sur ma distrib ; sur le coup, je me suis demandé pourquoi c'était 2.7 qui était la version installée ^^

Résoudre les problèmes qu'il pouvait y avoir, en versions précédentes, avec unicode, ça peut être qu'un bien, sur le long terme ; juste la transition / cohabitation qui va pas être évidente... et si c'est comme pour PHP, ça va durer quelques années
(quand je vois que PHP 5.3, sorti il y a bientôt 3 ans, est déployé sur tout juste 25% des serveurs exposant la version de PHP... ça fait mal )

Ça prend déjà des années pour passer à Python 3 ^^ mais comparé à d'autres langages (genre Perl), ça se passe plutôt bien... Le problème se situe comme toujours au niveau de l'écosystème, mais si les gros frameworks passent à Python 3 (PyQt, Django, Matplotlib, Twisted), le reste devrait suivre assez rapidement.

flanker (./78) :
mais comparé à d'autres langages (genre Perl)

oué, enfin, tu peux parler de PHP 6 aussi, pour lequel ça s'est tellement bien passé que la version en question a été abandonnée, et le full-unicode avec...

flanker (./78) :
mais si les gros frameworks passent à Python 3 [...], le reste devrait suivre assez rapidement.

Il y a peut-être moins d'applis / hébergements en Python qu'en PHP, mais ce qui ralenti l'adoption de PHP 5.3, c'est pas les gros frameworks : ça fait longtemps qu'ils fonctionnent très bien en PHP 5.3, voire même ont 5.3 comme version minimale requise.
Le problème c'est plus tous les hébergements bon marchés / gratuits, la quantité d'applications codées n'importe comment, qui casseraient plus ou moins en 5.3 (il y a des trucs qui "cassent en 5.3", mais si en fait les développeurs avaient pas fait n'importe quoi de considéré comme "bad practice" depuis des années, y'en pas mal pour lesquelles la montée de version de PHP se passerait bien mieux), les gens qui ont déployé des applis PHP "parce que c'est gratuit / opensource / l'hébergement est facile à trouver / le petit-neveu du voisin bidouille / il y a de la main d'oeuvre (pas forcément qualifiée) / ..."

Python, au moins, souffre peut-être moins du problème que PHP a (longtemps eu ?) d'être "trop facilement accessible".

squale92 (./64) :
rails n'étant pas un langage, pour autant que je sache, mais un framework Ruby

Certes, mais tu vois ce que je veux dire ^^

squale92 (./64) :
Deux choses, là dessus :
- il y a un brin d'historique : en C, majuscules et minuscules ne sont pas la même lettre. - deux chaines qui n'ont pas la même casse ne sont pas "égales", en informatique ; strpos et stripos faisant deux choses distinctes, plutôt que de rajouter un paramètre (puis un autre, puis encore un autre, et encore encore un autre au fur et à mesure des cas venant se rajouter), autant avoir deux fonctions distinctes.

Je sais tout cela : ma question n'était pas de se demander quel était l'intérêt d'avoir une fonction pour faire de la comparaison sans être case-sensitive, mais pourquoi ne pas avoir ajouté un paramètre à la fonction d'origine pour mettre le case-sensitive en true/false, en guise d'exemple de la multiplication inutile de fonctions.

Mon collègue vient de me demander "comment trier un tableau si je veux que...". je suis allé voir sur la doc, et comme je m'y attendais j'ai passé 20min à comparer une quinzaine de fonctions de tris. Même pas des noms du genre "sortByKey", "sortByValue", là encore j'aurais pardonné la multiplicité, mais impossible d'avoir une réponse claire et rapide (même la doc est parfois insuffisante, il faut chercher des exemples d'utilisation dans les commentaires en dessous).

http://fr.php.net/manual/en/array.sorting.php is your friend \o/ (bon, j'imagine que tu connais, mais ça évite de se prendre la tête pour trois bricoles quand tu sais ce que tu veux et que tu ne sais plus quelle fonction fait quoi).

C'est justement en tombant sur cette page que j'ai déprimé.

https://bugs.php.net/bug.php?id=50696 (lisez les premiers commentaires)

Haha énorme ^^

C'est le grand problème avec PHP, il y a plein de comportements tordus dont beaucoup de monde dépend. S'ils gardent les comportements tordus, tout le monde se plaint que c'est tordu, s'ils les modifient, tout le monde se plaint que c'est incompatible.

Les derniers commentaires sont sympas aussi ^^