Journal PHP, A Fractal Of Bad Design

Posté par  (site web personnel) .
Étiquettes : aucune
0
12
sept.
2012

Oui journal, nous ne sommes pas vendredi, mais un bon troll, fais toujours du bien en cette rentrée trépidante.

Le sujet du troll est comme le titre l'indique, PHP.

Si ce "langage" n'avait pas tant de succès, on appellerait mon appeau à troll "tirer sur une ambulance", mais voilà, avec 6% et une position de 6ème langage le plus utilisé dans le monde, PHP sévit encore.

PHP, a fractal of bad design est un magnifique texte, tout de colère rentré, mais rigoureux et documenté, listant toutes les incohérences de la star des langages orienté "web".

La lecture est longue tant les débilités existantes dans ce langage sont nombreuses.

Votre serviteur n'est pas seulement qu'un aigri vomissant sur ce langage par amour d'autres langages plus "évolués", il (j'aime parler de moi à la troisième personne) a passé deux jours à tenter de convertir la grammaire PHP de yacc vers OcamlYacc et a complètement halluciné devant un des codes le plus immonde qu'il ait pu voir dans sa vie (genre le parser dans le lexer, sisi).

Pour vous allécher, voici quelques exemples d'horreurs dont parle le lien bookmark plus haut.

Empty the grammar

La fonction empty permet de vider une variable, très bien, pourquoi pas.

Mais la fonction empty, n'est pas une fonction !!!
C'est quoi alors ?
Devinez !

C'est un mot clé de la grammaire ! Si si, ils ont osé !

Donc empty($var) fonctionne mais empty($var || $var2) provoque un parse error !!

C'est beau, non ?

Found FALSE

Autre exemple, la fonction array_search renvoi l'index de l'élément recherché dans le tableau, ou FALSE sinon.

Certains, comme votre serviteur, vont tiquer : on renvoi un int ou un booléen (ou une exception à la limite), mais il faut choisir !

Mais que se passe t-il si l'élément recherché est à l'index 0 ? Mhhh ?
False égal quoi en PHP, déjà ?

Exemple pratique :

<?php
$array = array(0 => 'blue', 1 => 'red', 2 => 'green', 3 => 'red');
$key = array_search('red', $array);
echo "Cas 1 : recherche d'une valeur se trouvant &agrave; la deuxieme case";
echo "<br/>";
if ($key == FALSE) { 
        echo "Le tableau ne trouve rien"; 
      } else { 
              echo "Le tableau a trouv&eacute; qq chose &agrave; l'index ",$key;
      }   
echo "<br/>";
echo "Valeur de key=", $key;
echo "<br/>";
echo "<br/>";

echo "Cas 2 : recherche d'une valeur se trouvant &agrave; la premiere case";
$array2 = array(0 => 'blue', 1 => 'red', 2 => 'green', 3 => 'red');
$key2 = array_search('blue', $array2);
echo "<br/>";
if ($key2 == FALSE) { 
                echo "Le tableau ne trouve rien"; 
                      } else { 
                              echo "Le tableau a trouv&eacute; qq chose &agrave; l'index ",$key2;
                      }   
echo "<br/>";
echo "Valeur de key=", $key2;
?>

Nous donne le résultat suivant :

Cas 1 : recherche d'une valeur se trouvant à la deuxieme case
Le tableau a trouvé qq chose à l'index 1
Valeur de key=1

Cas 2 : recherche d'une valeur se trouvant à la premiere case
Le tableau ne trouve rien
Valeur de key=0

Conclusion

Bref, un texte à lire, pour éviter quelques chausses trappes et éventuellement passer à autre chose, si cela est possible.

Et comme disait notre ami Xavier Leroy : "Un peu de programmation nous éloigne des mathématiques, beaucoup de programmation nous y ramène".

  • # Réponses

    Posté par  (site web personnel) . Évalué à 10.

    Empty the grammar

    La fonction empty permet de vider une variable, très bien, pourquoi pas.
    Mais la fonction empty, n'est pas une fonction !!!
    C'est quoi alors ?
    C'est un mot clé de la grammaire ! Si si, ils ont osé !

    Tu t'attendais à quoi pour une fonction qui agit sur des éléments du langage lui-même, à savoir les variables ? En C++, del, c'est une fonction peut-être ?

    Donc empty($var) fonctionne mais empty($var || $var2) provoque un parse error !!

    Et ce serait censé donner quoi à part une erreur au juste ?

    Found FALSE

    Mais que se passe t-il si l'élément recherché est à l'index 0 ? Mhhh ?
    False égal quoi en PHP, déjà ?

    Ce n'est pas un problème de array_search() mais de l'opérateur == qui est inutilisable, comme l'indique l'article en question.

    • [^] # Re: Réponses

      Posté par  . Évalué à 3.

      En C++, del, c'est une fonction peut-être ?

      Tu veux dire delete ?
      (j'ai pas fait de C++ depuis longtemps…, les choses ont peut-etre changé)

    • [^] # Re: Réponses

      Posté par  (site web personnel) . Évalué à -1.

      Tu t'attendais à quoi pour une fonction qui agit sur des éléments du langage lui-même, à savoir les variables ? En C++, del, c'est une fonction peut-être ?

      Vu que le design de C++ est à peu près aussi consternant que celui de PHP (avec du niveau en plus, tout de même), … à mieux (cf plus loin)

      Donc empty($var) fonctionne mais empty($var || $var2) provoque un parse error !!

      Et ce serait censé donner quoi à part une erreur au juste ?

      Ça serait censer parser le code, parcourir gentillement l'AST et te cracher une belle erreur, en te disant que non là c'est pas possible, car sémantiquement ça veut rien dire.
      Mais mettre ça dans la grammaire, tu me diras ce que tu veux, moi je trouve ça crade.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Réponses

        Posté par  . Évalué à 1.

        empty($var || $var2) sémantiquement ça veut rien dire.

        Ça pourrait pas vouloir dire : vide la variable $var si elle est définie, sinon vide $var2 si elle est définie, sinon erreur ?

        • [^] # Re: Réponses

          Posté par  . Évalué à 4.

          Ça ne peut vouloir dire que empty(TRUE) ou empty(FALSE). Donc forcément une erreur.

          Un exemple plus parlant aurait été :

          empty( mafonction() ? $var1 : $var2 )

          ou encore :

          empty( ma_fonction_qui_retourne_une_variable() )

          Dans les deux cas ça fonctionne.

          • [^] # Re: Réponses

            Posté par  . Évalué à 3.

            En plus j'avais répondu ça en considérant que empty() « vidait » une variable, je ne me souvenais pas que c'était un test.

    • [^] # Re: Réponses

      Posté par  . Évalué à 5.

      En C++, delete est un opérateur, donc une fonction. C'est surchargeable, d'ailleurs.

    • [^] # Re: Réponses

      Posté par  . Évalué à 1.

      Il faut utiliser l'opérateur === pour déterminer si array_search retourne false ou 0.

      Dire que vous vous n'en avez rien à faire de la vie privée parce que vous n'avez rien à cacher, c'est comme dire que vous n'en avez rien à faire de la liberté d'expression parce que vous n'avez rien à dire. Edward Snowden

  • # == vs. ===

    Posté par  (site web personnel) . Évalué à 10.

    Pour ton second problème, il faut utiliser le « === » qui vérifie les types au lieu du « == » qui gère les équivalences.

    Je ne cherche pas à défendre PHP, mais ce que tu veux faire est prévu dans le langage.

    • [^] # Re: == vs. ===

      Posté par  (site web personnel) . Évalué à 10. 

      Cette fonction peut retourner FALSE, mais elle peut aussi retourner une valeur équivalent à FALSE. Veuillez lire la section sur les booléens pour plus d'informations. Utilisez l'opérateur === pour tester la valeur de retour exacte de cette fonction.

      C'est surtout indiqué noir sur blanc dans la doc officiel.

      • [^] # Re: == vs. ===

        Posté par  . Évalué à -3.

        Une exception, ça ne serait pas plus propre ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: == vs. ===

          Posté par  . Évalué à 2.

          ou une valeur négative, tout simplement !

          Parce que ne pas trouver une valeur dans un tableau, je ne comprends pas pourquoi ça devrait lever une exception…

          • [^] # Re: == vs. ===

            Posté par  (site web personnel) . Évalué à 10.

            Bizarre de voir un commentaire aussi bien voté oublier totalement que les entiers négatifs sont aussi des clés valides d'arrays :)

            • [^] # Re: == vs. ===

              Posté par  . Évalué à 2.

              Oh merde, tu as raison : c'est alors considéré comme une clé "texte", non ?

    • [^] # Re: == vs. ===

      Posté par  . Évalué à 2.

      +1, même si je n'aime pas ce langage où les développeurs ont décidé que les arguments des fonctions devaient être le plus hétérogène possible. Je ne donne pas d'exemple, il suffit de survoler la doc des fonctions de manipulation d'array pour s'en rendre compte : http://fr2.php.net/manual/fr/ref.array.php

  • # empty() ne permet pas de vider...

    Posté par  . Évalué à 8.

    …mais de tester di une variable vaut 0 ou "".

    Dans le cas d'array_search, tu dois utiliser ===

    Aprés, tu peux aussi déclarer tes variables et adopter des comportements / une configuration te permettant d'avoir un comportement plus strict.

    Mais sur le fond, on sent bien l'héritage grand public. C'est pas forcément un mal ceci-dit, c'est sans doute un élément clé de la popularité de PHP. Tout est affaire de compromis.

    • [^] # Re: empty() ne permet pas de vider...

      Posté par  (site web personnel) . Évalué à 3.

      …mais de tester di une variable vaut 0 ou "".

      Ah, ça explique des choses. Effectivement, mettre une telle fonction dans la grammaire du langage, c'est abominable.

    • [^] # Re: empty() ne permet pas de vider...

      Posté par  . Évalué à 0.

      …mais de tester di une variable vaut 0 ou "".

      Toutafé ! Et du coup, il est regrettable de ne pas pouvoir faire : empty($var || $var2)

      • [^] # Re: empty() ne permet pas de vider...

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Et c'est censé tester quoi ? Que si $var est vide il faut tester $var2 ? Ou qu'il faut tester si $var est false il faut tester $var2 ? Cette syntaxe ne veut rien dire…

        La solution évidente c'est empty($var) || empty($var2)

        Pour revenir au journal, venant d'un ahuri qui n'a même pas lu le manuel pour voir ce que empty() était censé faire, j'ai peur qu'il n'ait absolument aucune compétence générale en programmation…

        « 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: empty() ne permet pas de vider...

          Posté par  . Évalué à 2.

          La solution évidente c'est empty($var) || empty($var2)

          C'est ce que ma proposition voulait signifier, en s'épargnant la répétition de la fonction empty(), c'est tout !

  • # L'indice TIOBE

    Posté par  . Évalué à 2.

    Ton texte est truffé d'erreur.

    avec 6% et une position de 6ème langage le plus utilisé dans le monde

    D'abord comme il est dit dans ton lien sur l'indice TIOBE : "Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written."
    Il s'agit d'un indice qui mesure la compétence des ingénieurs selon des critères. Personne ne peut croire qu'il y ai plus de gens qui programment en Objective-C qu'en C# ou en C++…
    Ensuite comme dit plus haut remplace
    php
    == FALSE

    par
    php
    === FALSE

    dans ton code.

  • # N'importe quoi.

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 12 septembre 2012 à 12:28.

    Personnellement, ça m'énerve de voir ce genre d'article à deux sous.

    PHP est un langage de programmation. Comme tout les langages, il a une syntaxe à respecter, des règles à respecter.
    Et tout est indiqué dans la documentation !!! Et le meilleur, c'est que 95% de la documentation est écrite en français et est très claire de compréhension ! Tout les langages ne peuvent pas s'en venter.

    Alors, ton problème avec empty :
    Premièrement, cette fonction « ne permet pas de vider une variable".
    Deuxièmement, tu aurai lu la documentation à propos d'empty, tu auras pu lire que « empty() ne vérifie que les variables, toute autre chose retournera une erreur d'analyse. En d'autres termes, ce qui suit ne fonctionne pas : empty(trim($name)). A la place, utilisez trim($name) == false. »

    Ensuite, pour array_search, que dire de plus que ceci.

    Personnellement, j'écris du PHP toute la journée pratiquement. Étrangement, je ne suis pas perturbé par tout ces pseudo problème que vous trouvé si immonde. Peut-être tout simplement que je sais lire une documentation, et pas d'autre.

    Par contre, j'avoue que certain point peuvent être problématique, mais ça tend à se résoudre avec les dernières mise à jour de PHP.

    • [^] # Re: N'importe quoi.

      Posté par  (site web personnel) . Évalué à -3.

      Tout les langages ne peuvent pas s'en venter.

      T'imagines si le serpent s'envolait ?

      Personnellement, j'écris du PHP toute la journée pratiquement.

      Je compatis.

    • [^] # Re: N'importe quoi.

      Posté par  . Évalué à 0.

      « empty() ne vérifie que les variables, toute autre chose retournera une erreur d'analyse. En d'autres termes, ce qui suit ne fonctionne pas : empty(trim($name)). A la place, utilisez trim($name) == false. »

      C'est precisement le problème. A quoi sert empty alors?
      C'est completement con, et typique du design (inexistant) de php, un gros bordel fourre tout sans aucune logique et avec des comportement dangereux (genre retourner false si l'element d'un tableau n'est pas trouve, par exemple).

      Et on passera sur le nommage de la fonction, qui laisse effectivement croire que la fonction va avoir un effet sur la variable. genre isEmpty() aurait ete un peu moins debile.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Il y a deux sorte de languages...

    Posté par  (site web personnel) . Évalué à 10.

    Comme le disait Bjarne Stroustrup:

    There are only two kinds of languages: the ones people complain about and the ones nobody uses.

    • [^] # Re: Il y a deux sorte de languages...

      Posté par  . Évalué à 6.

      There are only two kinds of languages: the ones people complain about and the ones nobody uses.

      Ah bon?

      Pourtant Lisaac par example pete le feu (il n'y a qu'a voir le site web)!
      Il faut dire que depuis que l'unique contributeur a fondu une durite et s'est reconverti dans l'etude des illuminatis qui controlent le monde, l'interet pour le language a explose.

      (desole, c'etait trop tentant…)

  • # C'est étrange...

    Posté par  . Évalué à 1. Dernière modification le 12 septembre 2012 à 13:14.

    D'abord je suis entièrement d'accord c'est un langage merdique !
    (c'est-à-dire que JE n'aime pas).
    Ce qui est étrange, c'est qu'il est presque aussi merdique que Javascript conclusion : le Web ne semble pas être une ecosystème
    favorisant les bons langages

  • # Old

    Posté par  . Évalué à 10.

    Ce texte est très vieux et a suscité beaucoup de réponses dont :

    http://www.codinghorror.com/blog/2012/06/the-php-singularity.html

    Qui dit en gros, certes PHP est une grosse bouse infâme. Certes, plein de choses sont contre-intuitives, pas naturelles, pas logiques, mal faites, pas cohérentes.

    Et personnellement, je suis d'accord avec ces points et j'ai été choqué par la majorité des points soulevés par l'article (oui, je l'ai lu en entier).

    Mais PHP a su s'imposer. Il est présent sur n'importe quel serveur Web (ou presque) tous les presta de service offrant de l'hosting Web en proposent.

    On attend que les autres langages arrivent à s'imposer, s'il sont réellement meilleurs.

    Ou en une phrase : si c'est si pourri, sortez vous les doigts et proposez mieux.

    Le FN est un parti d'extrême droite

    • [^] # Re: Old

      Posté par  (site web personnel) . Évalué à 7.

      Ou en une phrase : si c'est si pourri, sortez vous les doigts et proposez mieux.

      Ça serait ignorer l'effet masse de la base installée qui fait que PHP est maintenant en place pour longtemps.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Old

        Posté par  . Évalué à 5.

        Ou en une phrase : si c'est si pourri, sortez vous les doigts et proposez mieux.

        Ça serait ignorer l'effet masse de la base installée qui fait que PHP est maintenant en place pour longtemps.

        C'est le propos de l'auteur.

        Si c'est si pourri, pourquoi un tel effet de masse ?

        Pourquoi les autres n'ont pas percé ?

        Les débutants et le grand public (relativement geek quand même) y trouve son compte. Pourquoi Perl n'a pas percé alors qu'il était là avant, qu'il est plus propre et que php est basé dessus ?

        Je précise que je suis un fan inconditionnel de Perl et que je rêve la nuit d'en voir partout. Mais il faut arrêter de cracher sur PHP à longueur de journée.

        Ok, PHP, c'est pourri. Est ce que ça vaut le coup de faire un article qui met des heures à lire (et probablement des semaines à écrire) ? Pour quelqu'un qui conchie php, l'auteur de l'article semble quand même sacrément fasciné par ce langage.

        PHP a su trouver une place que les autres langages n'ont pas trouvé. Plutôt que de passer des journées à dénigrer PHP, faites en sorte que les autres langages trouvent leur place.

        Le FN est un parti d'extrême droite

        • [^] # Re: Old

          Posté par  (site web personnel) . Évalué à 1.

          Si c'est si pourri, pourquoi un tel effet de masse ?
          Pourquoi les autres n'ont pas percé ?

          J'ai longuement étudié cette question afin de pondre quelques dizaines de page sur la question, et il apparaît, qu'en général, ce sont les technos les plus moyennes qui réussissent. VHS vs Betacam, Frame, Tex lost vs Word/HTML, etc…

          Tu trouveras une tentative d'explication là : http://www.dreamsongs.com/Files/AcceptanceModels.pdf

          En gros un langage doit être avant tout simple.
          J'en ai explicité le modèle ici : https://linuxfr.org/nodes/86566/comments/1246354

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Old

            Posté par  . Évalué à 2.

            https://linuxfr.org/nodes/86566/comments/1246354

            Pourquoi tant de mépris envers les développeurs web?

            Et puis c'est la foire à la propagande pro ocaml, c'est plus qu'un langage ça devient un mode de pensé.

            type message = { … }
            C'est trop camelien !

            C'est moi qui comprend rien ou c'est juste de la syntax?

            As tu déjà écrit des choses réel avec ocaml? (par exemple un truc qui prend en compte plusieurs cpu)

            • [^] # Re: Old

              Posté par  (site web personnel) . Évalué à 1.

              Pourquoi tant de mépris envers les développeurs web?
              Juste une constatation. Après, j'ai grande admiration pour ceusse qui maîtrise les CSS, et autre HTML5. J'ai jamais rien compris à CSS, malgré mes tentatives et HTML5 c'est guerre mieux. Donc disons que je suis assez consterné de voir le genre de code en ce concerne le traitement des données. Le niveau en culture générale est faible, c'est aussi une constatation "statistique".

              Et puis c'est la foire à la propagande pro ocaml, c'est plus qu'un langage ça devient un mode de pensé.

              C'est complètement vrai, et c'est encore mieux quand ça devient un mode de pensé, tu programme du code avec très peu de bug.
              Mais j'en suis encore très loin, tant le monde du fonctionnel Haskell/OCaml/Scala est vaste et te pousse à l'humilité quand tu te rends compte que ton code est nul et mal pensé.

              As tu déjà écrit des choses réel avec ocaml? (par exemple un truc qui prend en compte plusieurs cpu)

              Oui, en ce moment même d'ailleurs (le temps de switcher de vim à firefox), une GED de 10 000 lignes en OCaml.

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Old

              Posté par  (site web personnel) . Évalué à 1.

              Et j'oubliai de préciser que ça scale merveilleusement bien (merci OcamlNet) sur une archi multi-cpu.

              « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Old

            Posté par  . Évalué à 3.

            En gros un langage doit être avant tout simple.

            En quoi simple implique-t-il pourri ? Personne ne reproche à PHP d'être simple.
            Et à vrai dire, rapporté à sa puissance d'expression, PHP n'est pas si simple…

            • [^] # Re: Old

              Posté par  (Mastodon) . Évalué à 5.

              La simplicité, elle n'est effectivement pas dans le langage, mais dans son modèle d'exécution. Et c'est à mon avis là que réside la principale raison du succès de PHP.

              Le modèle est simple et immédiatement compréhensible : on part d'une URL, qui va correspondre à un fichier sur le disque, fichier qui sera interprété du début à la fin. Pas de magie, pas de code exécuté en cachette, pas d'état caché quelque part.

              Du coup, pour démarrer, ça semble effectivement simple. Les horreurs du langage, on ne les voit pas immédiatement, mais ce qu'on voit, c'est qu'on arrive rapidement à écrire une petite application qui va lire et écrire en base de données.

              • [^] # Re: Old

                Posté par  . Évalué à 3.

                on part d'une URL, qui va correspondre à un fichier sur le disque, fichier qui sera interprété du début à la fin. Pas de magie, pas de code exécuté en cachette, pas d'état caché quelque part.

                Parce que c'est pas le cas pour du Perl ou du Python ?

                • [^] # Re: Old

                  Posté par  . Évalué à 5.

                  Non, pour Python, le modèle WSGI est plutôt d'associer toute une arborescence à une application, c'est-à-dire un "fichier", unique (au lieu d'avoir une bijection URL <-> fichier).

                  C'est évidemment plus puissant, ceci dit, puisque l'application et son état sont persistants, alors qu'avec PHP l'interpréteur est rechargé à neuf à chaque requête.

            • [^] # Re: Old

              Posté par  . Évalué à -2.

              ruby et java sont tres simple.
              Ils ne sont pas pourri comme php.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: Old

                Posté par  (Mastodon) . Évalué à 7.

                ruby et java sont tres simple.

                Ruby, je ne connais pas assez pour juger, mais Java, simple ? T'es sérieux ? Si on parle de développement web, "simple" doit bien être un des derniers mots qui me viendrait à l'esprit pour décrire Java…

                • [^] # Re: Old

                  Posté par  . Évalué à -1.

                  Le langage.
                  C'est sur que l'appli enterprise J2EE de base est loin d'etre simple, mais rien n'empeche de faire un framework tres simple.
                  Le JSP sont pas tres compliquees conceptuellement.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Old

      Posté par  . Évalué à 8.

      Ou en une phrase : si c'est si pourri, sortez vous les doigts et proposez mieux.

      Pourquoi faire ? Ça existe déjà : Python, Ruby, etc, ainsi que leurs frameworks associés.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Old

        Posté par  . Évalué à 4.

        Ou en une phrase : si c'est si pourri, sortez vous les doigts et proposez mieux.

        Pourquoi faire ? Ça existe déjà : Python, Ruby, etc, ainsi que leurs frameworks associés.

        Tu as oublié templeet.

        Le FN est un parti d'extrême droite

        • [^] # Re: Old

          Posté par  . Évalué à 2.

          Qui d'ailleurs est écrit en PHP, si je ne m'abuse.

      • [^] # Re: Old

        Posté par  (site web personnel) . Évalué à -3.

        Pourquoi faire ? Ça existe déjà : Python, Ruby, etc, ainsi que leurs frameworks associés.

        Python, c'est tellement bien que certaines personnes éprouvent le besoin de passer à Ruby.
        Ruby, c'est tellement bien que certaines personnes éprouvent le besoin de passer à Python.
        etc…

        Finalement, PHP semble mettre plus de monde d'accord que les noms que tu as cité… Faut croire qu'ils ne sont pas si "mieux" que ça. Raté.

        • [^] # Re: Old

          Posté par  (site web personnel) . Évalué à 4.

          Finalement, PHP semble mettre plus de monde d'accord que les noms que tu as cité

          Ouais il met d'accord les vrais dév. contre lui :). Dans mon entourage, c'est simple, un premier filtre en cas de recherche d'emploi c'est : y a PHP dans l'offre => poubelle.

          • [^] # Re: Old

            Posté par  . Évalué à 5.

            Ah les joies du plein emploi…

    • [^] # Re: Old

      Posté par  (Mastodon) . Évalué à 10.

      Mais PHP a su s'imposer. Il est présent sur n'importe quel serveur Web (ou presque) tous les presta de service offrant de l'hosting Web en proposent.

      Il a su s'imposer, en créant au passage toute une génération de pseudo-développeurs qui n'ont connu que ça et qui sont complètement incompétents sur des domaines cruciaux comme la sécurité.

      • [^] # Re: Old

        Posté par  . Évalué à 2.

        Il a su s'imposer, en créant au passage toute une génération de pseudo-développeurs qui n'ont connu que ça et qui sont complètement incompétents sur des domaines cruciaux comme la sécurité.

        Alors que si c'était ruby, plus aucun site n'aurait de faille de sécurité.

        Le FN est un parti d'extrême droite

        • [^] # Re: Old

          Posté par  (Mastodon) . Évalué à 5. Dernière modification le 12 septembre 2012 à 17:09.

          Pas forcément, mais ça serait certainement nettement mieux.

          Si je me mets dans la peau d'un débutant qui veut commencer à coder, je vais faire une petite recherche avec "php tutorial" ou "ruby tutorial" par exemple.

          Le gros problème, c'est qu'avec PHP, la plupart des résultats retournés donnent des exemples avec des problèmes de sécurité potentiels, sans aucun avertissement. On risque donc de prendre de mauvaises habitudes dès le départ, et d'écrire du code vulnérable à tout un tas de problèmes de sécurités. Et c'est là qu'on revient à ma remarque d'au-dessus : on a une quantité impressionnante de développeurs incompétents, qui vont écrire de la doc de mauvaise qualité, qui va servir à former d'autres développeurs incompétents, et le cycle peut recommencer.

          Au contraire pour Ruby, la doc trouvée donne des exemples avec de bonnes pratiques. Ça ne veut pas dire qu'on ne peut pas avoir de failles, bien sûr, mais on part sur de bien meilleures bases.

          Maintenant, on pourra me répondre que c'est pas vraiment la faute du langage si la doc disponible sur le net est dans la plupart des cas médiocre. Certes, mais dès le départ, PHP a incité à programmer salement, et les nombreux bricolages qui prétendaient améliorer la sécurité (genre magic quotes) ont encore empiré les choses. Même si les évolutions récentes du langage vont dans le bon sens, les anciennes pratiques sont encore ancrées très profondément (suffit de lire un forum dédié à la programmation pour s'en rendre compte, certaines réponses données à des débutants font vraiment peur)

      • [^] # Re: Old

        Posté par  (site web personnel) . Évalué à 2.

        Eh, c’est de moi qu’on parle ?
        Alors oui, j’avoue. J’avais besoin de mettre des livres d’or sur mes sites, et :
        a) PHP c’est facile. Trop peut-être ?
        b) Chez les deux hébergeurs de mes sites c’était PHP ou rien.
        Je pense être représentatif d’un paquet d’amateurs qui ont eu besoin ponctuellement d’apprendre la petite programmation pour un besoin très ponctuel.
        Et qui ne connaissent que : html, et PHP (+ TeX en ce qui me concerne).
        De PHP, j’ai pratiquement tout oublié après m’en être servi une fois.
        Mes livres d’or, c’est pas beaucoup de lignes de code.
        Et du très basique, tellement basique qu’à la limite ça me rassure au niveau sécurité.
        Je ne pense pas avoir laissé de faille à cause justement de cette simplicité.
        Mais s’il y en avait une, je serais incapable de la détecter.
        Tout comme je suis incapable de juger des qualités et défauts de PHP.
        Mais si défauts il y a, ne pourrait-ce être dû à ce que justement il a été créé aussi pour les webmestres amateurs ? Syntaxe simple, accès facile… Ça ne doit pas être par hasard si chez plusieurs hébergeurs c’est PHP ou rien.
        Au fait, les livres d’or je pense à les fermer. Plus très rentables, malgré autant de visiteurs.
        Moinsez si vous voulez, mais ne tapez pas sur la tête.

    • [^] # Re: Old

      Posté par  . Évalué à 3. Dernière modification le 12 septembre 2012 à 16:47.

      Peut être que php est un exemple du worse is better.

      http://en.wikipedia.org/wiki/Worse_is_better#effects

      Once it has spread, there will be pressure to improve its functionality, but users have already been conditioned to accept "worse" rather than the "right thing". "Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.

      Il me semble que c'est toute l'histoire de php qui tient dans ces deux phrases.
      1 . un truc simple utilisable par plein de gens php < 4
      2 . expansion de la base d'utilisateurs et ajout de fonctionnalites php4
      3 . tentative de revenir au concept "right thing" php > 5

      ou bien ai je fumé ?

      • [^] # Re: Old

        Posté par  . Évalué à 4.

        3 . tentative de revenir au concept "right thing" php > 5

        Je ne vois pas en quoi PHP 5 est fondamentalement mieux que PHP 4. Toute la structure de base (typage pourri, stdlib mal fichue…) est la même.

  • # J'aimais bien PHP

    Posté par  (site web personnel) . Évalué à 10.

    J'aimais bien PHP jusqu'au jour où j'ai proposé des patchs pour le module LDAP. Quand j'ai vu l'introduction des fonctions ldap_control_paged_result_response et ldap_control_paged_result qui est hack immonde puisque ce genre de contrôles sont passé à ldap_set_options ou en paramètre des fonctions de recherche et récupéré par ldap_parse_results

    Bref, j'ai fais une série de patch dans cette ordre là :
    1) un patch qui enlevait l'utilisation de toutes les fonctions dépréciés de libldap2
    2) un patch qui utilisait ces nouvelles fonctions pour permettre les contrôles serveur ou client.

    Bien entendu ces deux changements n'impactaient en rien le code PHP précédemment écrit et apportaient des fonctionnalités nécessaires et réclamées ! Bah, depuis le mois de mai il ne se passe rien (à part un mail d'un type, ayant envoyé un patch aussi, pour me dire qu'il ne se passera rien et que dans trois mois je serais triste), les hacks immonde s'enracinent dans le langage, j'ai jeté les patchs qui auraient dû suivre (il y'avait 3 et 4, mais y'a plus rien (ou peut-être, mais je ne vais pas chercher pour qu'ils tombent encore une fois dans l'oubli)) et je me suis remis sur Perl.

    Enfin un des mainteneurs a parlé d'un php ldap "next", peut-être qu'ils ré-écrivent le tout (ce qui n'est pas nécessaire puisque l'API php-ldap suivait plus ou moins l'API définie par la RFC 1823) secrètement.

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: J'aimais bien PHP

      Posté par  . Évalué à 1.

      Ouais, ok… mais bon trois mois sans news ça ne me choque pas non plus, c'est souvent ainsi dans plein de projet…
      J'ai attendu un an pour un truc bien plus simple que toi. Ils ne préviennent pas quand ils commencent, tu sais qu'au commit.

      Domage pour tes autres patch.

      • [^] # Re: J'aimais bien PHP

        Posté par  (site web personnel) . Évalué à 4.

        Sauf que trois mainteneurs pour un module où il y a peu d'activité, quand une fois il y'en a (et surtout que j'amène des solutions qui sont demandées depuis longtemps …
        Il m'a fallu une semaine pour plonger dans le code de PHP. À ce moment j'étais "chaud". Maintenant ça fait 5 mois que je n'ai plus touché à ce code, j'ai très peu la motiv' de me refaire une semaine avec la documentation très lacunaire de Zend pour comprendre à nouveau ce que font mes patchs.

        Et les patchs seraient faciles à refaire, dès que le code qui permet d'encoder ça :

        <?PHP
array(
  'oid'=> LDAP_CONTROL_PAGEDRESULTS,
  'iscritical'=> $critical,
  'value'=> array(
      'type'=>'sequence', 'value'=>array(
         array('type'=>'integer', 'value'=>$page_size),
         array('type'=>'octetstring', 'value'=>$cookie)
      )
   )
)
?>

        en BER (et retour) est intégré. C'est le deuxième patch, il modifie ldap_parse_result et ldap_set_options pour permettre cette conversion. Les patchs suivant auraient été ceux qui ajoute ça sur des fonctions comme ldap_search_ext.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Bof...

    Posté par  . Évalué à -1. Dernière modification le 12 septembre 2012 à 16:45.

    Être exhaustif sur les défauts d’un langage, ça ne suffit à en faire un mauvais langage, surtout quand certains des dits défauts sont parfaitement défendables.

    Il est certain qu’on trouve des langages plus matures, mieux pensés (Python, Go, etc.), mais on trouve des langages tellement plus pénibles (C++, Java, etc.) que ça relativise vachement le propos.

    Malgré ses défauts et tout le mal que j’en avais entendu dire, je trouve plutôt agréable de coder en PHP, la doc est bien faite, le langage ne fait pas vraiment chier avec ses bizarreries, on peut faire ce qu’on veut avec sans trop de peine, et je n’ai pas constaté d’emmerdements majeurs pour faire ce que je voulais. Donc c’est efficace et ça marche.

    • [^] # Re: Bof...

      Posté par  (site web personnel) . Évalué à 4.

      mais on trouve des langages tellement plus pénibles (C++, Java, etc.)

      Le problème de Java ce n'est pas le langage qui est très simple, mais le goût pour les frameworks bloated.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Bof...

        Posté par  (site web personnel) . Évalué à 6. Dernière modification le 12 septembre 2012 à 17:53.

        Oh, le langage lui-même, ou plutôt sa bibliothèque standard — ça s'appelle un classpath je crois, en jargon javaiste — a aussi des problèmes d'abus de raffinement de conception, souvent liés aux patrons de conception — le design par terre.

        Typiquement, le fait d'avoir en standard une interface HashMap et plusieurs implémentations à utiliser au choix du programmeur. Ou encore, des croquemitaines comme la fabrique singleton de fabrique de documents XML, qui amène à écrire ce genre d'horreur :

        Document doc = DocumentBuilderFactory.getInstance().newDocumentBuilder().createDocument()

        Alors certes, ce genre d'absurdité a sans doute un intérêt théorique, seulement comme personne à part son concepteur ne comprend cet intérêt — et encore, je n'en suis même pas sûr — tout le monde les utilise sans comprendre comme des sauvages et ça ne fait qu'alourdir le langage.

        • [^] # Re: Bof...

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          L'interface c'est Map, HashMap est une des implémentations possibles. Et ça c'est juste de l'objet standard et ça ne pose aucun problème.
          L'exemple pour le XML par contre, c'est vrai que c'est chiant. Par contre ça a une réelle utilité, et c'est utilisé. Ça permet de fournir d'autres implémentations (qui s'enregistrent au près de la fabrique) et qui font un travail un peu différent, ou plus rapide, ou que sait-je d'autre. Par contre c'est un peu dommage qu'il n'existe pas un masquage ou wrapper pour éviter d'écrire ce genre de choses à rallonge quand on n'est pas intéressé par le type d'implémentation précise qui sera choisi.

          Il existe surtout pas mal de choses qui sont manquantes dans la grammaire Java qui peuvent être chiantes au quotidien, mais ce n'est pas du tout les exemples que tu montres.
          Java 7 améliore quelques petites choses sur le langage (switch sur un type string, catch multiples, meilleure gestion des ressources systèmes ouvertes (équivalent des file descriptors), syntaxe diamond pour l'intialisation de type générique), mais on est encore très loin de la souplesse de grammaire qu'offre un langage comme Python par exemple avec ses dictionnaires, tuples et surtout toutes les méthodes qui tournent autour.

          Car tout de même, dans un langage procédural (fusse-t-il objet), on a majoritairement un enchaînement de blocs de contrôles (if, while, for, switch, try catch), de manipulation arithmétique, affectations…et de manipulations ensemblistes.

          Et sur ce dernier point que Java est très très loin derrière les autres langages. C'est la panacée du tout‑objet, qui fait qu'il n'existe qu'un seul type primitif de liste, qui est très très limité, et que pour le reste il faille passer par des objets/classes ensemblistes (java.util.Collection) qui ont une API très pauvres. Du coup il existe un tas de bibliothèques qui permettent d'ajouter quelques fonctionnalités ensemblistes, mais on reste sur une manipulation orientée objet, ce qui n'est pas du tout adapté pour ce cas de figure. De plus, ces librairies externes ne sont pas considérées pour une future inclusion dans le JRE, ce qui reste donc pénalisant.

          Je pense qu'il existe d'autres domaines que la pauvreté du domaine ensembliste qui pourrait être cité, mais c'est vraiment celui qui me dérange au quotidien.

        • [^] # Re: Bof...

          Posté par  (site web personnel) . Évalué à 6.

          Typiquement, le fait d'avoir en standard une interface HashMap et plusieurs implémentations à utiliser au choix du programmeur

          J'aimerais bien avoir autant de "map" dans les autres langages, car pouvoir choisir entre trié, non trié, avec conservation de l'ordre d'insertion ou non, c'est un gros avantage!

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Bof...

          Posté par  . Évalué à 4.

          Le runtime java (rien avoir avec le classpath, mais alors vraiment rien) est plutot pas mal concu en soi.
          C'est un truc vieux de 20 ans, dans l'ensemble ca s'en sort plutot bien. Ok, ya des boulets a droite a gauche, genre la classe Date qui est deprecated a 99%, ca serait sympa d'avoir des versions immutables des collections, ou une version mutable de String.
          Par dessus, l'autoboxing a foutu la zone, et la tendance de sun a rajouter du sucre syntaxique au compilo ammene des problemes chiant (comme une for(Object object : list) qui te pete une NPE quand list est null, ou a+ b qui fait pareil, merci l'autoboxing).

          Le truc de java, c'est le monde entreprise. Des applis critiques massivement complexes destinees a interagir avec d'autres applis massivement complexes sans que les deux se connaissent.
          Le but de java, c'est pas de rendre le developement simple/facile, c'est de rendre le developement de gros bouzin super complique possible.
          D'ou des designs gigantesques, et dans un design gigantesque, ya toujours qq trucs qui partent un peu couille, et ca donne sa reputation a java.

          Ton exemple xml te fait peut etre marrer, mais ya une palanquee de providers xml differents, et oui, ca a une utilite.
          En contraste, le monde java sait aussi faire des trucs super simples. Pour du json avec jaxson, tu ponds du json (ou du xml) avec tres exactement 0 lignes de code.
          Return monObjet, pouf il est serialise par jersey, en xml ou en json, merci les annotations.

          Le coup de la map, je sais pas d'ou tu viens ni qui t'as appris ton design objet, mais environ 100% des langages objets suivent ce pattern pour les collections… Une interface definit l'api, le runtime fournit de bonnes implementations de base, et libre a toi d'implementer ce dont t'as besoin.
          Faut etre un peu tare (ou idiot) pour mettre en dur les collections typees contre une classe concrete…

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Bof...

            Posté par  (site web personnel) . Évalué à 1.

            Sans compter le design douteux de la JVM. Tous les spécialistes de la compilation (objet ou fonctionnel) avec qui j'ai pu en discuter (objet) ou lire des comptes rendus (fonctionnel) pointent le fait que générer du code pour la JVM est une vrai galère, surtout à cause de l’absence de véritable types numériques.

            Xavier Leroy explique très bien pourquoi c'est très galère de compiler pour une JVM ou du .NET

            So, when the source language isn't quite what the VM designers had in
            mind, the "natural mapping" doesn't work and one has to revert to
            encodings of data structures. For instance, integers and floats may
            have to be boxed (wrapped inside an object) most of the time.
            Source-level objects may have to be mapped to VM objects that manage
            themselves their own vtable of methods, bypassing that of the VM.
            Source-level classes map to even more complicated encodings.

            Cela ne veut pas dire que c'est infaisable, mais que c'est beaucoup plus difficile que de générer de l'assembleur processeur.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Bof...

              Posté par  (site web personnel) . Évalué à 4.

              En même temps la JVM n'a été faite qu'avec Java "in mind", non?

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Bof...

              Posté par  . Évalué à 2.

              Wed, 14 Feb 2001

              Depuis on a eu F# et le DLR, mais bon le fait que tu ailles chercher un message vieux de plus de 11 ans sur archive.org en dit long.

              Xavier Leroy est quelqu'un de tres competent, mais depuis 2001 il s'en est passe des choses et la VM .NET a evolue (et dans une moindre mesure celle de Java aussi). D'ailleurs, un peu plus d'un an plus tard, voila ce qu'il avait a dire sur F# (alors juste un projet de recherche).

              Bref, try harder…

              • [^] # Re: Bof...

                Posté par  (site web personnel) . Évalué à 1.

                C'est petit comme bashage.

                Les fondamentaux de la JVM n'ont pas évolué depuis 11 ans et posent toujours les même problèmes. .NET a rectifié le tir, très bien, mais il n'en reste pas moins que le design n'ayant pas été fait pour ça, cela pose des problèmes à beaucoup de langages.

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: Bof...

                  Posté par  (site web personnel) . Évalué à 4.

                  Scala s'en tire pas mal non ?
                  (Je dis pas que c'est parfait hein, mais ça montre que c'est possible d'avoir des bonnes perfs avec un truc différent de Java)

                  • [^] # Re: Bof...

                    Posté par  (site web personnel) . Évalué à 1.

                    Scala a un modèle très intéressant, complètement objet, tout en tentant de réutiliser les résultats théoriques sur la sureté de type.
                    Utilisant de l'objet, Scala est un peu plus à l'aise pour compiler sur de la JVM.

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: Bof...

                  Posté par  (site web personnel) . Évalué à 3.

                  Je ne sais pas pour les fondamentaux, mais les performances de la JVM se sont beaucoup améliorées. On reste de loin de C++, mais bien devant python ou ruby.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Bof...

                    Posté par  (site web personnel) . Évalué à -1.

                    Il faut bien voir aussi que les ressources consacré à l'optimisation de la JVM sont énormes par rapport à ceux de bien d'autres langages à VM ou compilateur.

                    Je serai curieux de voir les perfs de Ruby si une dizaine d'ingénieurs avaient pour tâches d'accélérer les performances :-)

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # .

    Posté par  . Évalué à 9.

    Empty the grammar

    La fonction empty permet de vider une variable, très bien, pourquoi pas.

    Mais la fonction empty, n'est pas une fonction !!!
    C'est quoi alors ?
    Devinez !

    C'est un mot clé de la grammaire ! Si si, ils ont osé !

    Donc empty($var) fonctionne mais empty($var || $var2) provoque un parse error !!

    C'est beau, non ?

    Eh ben on voit que tu connais bien le sujet. empty() ça permet pas de vider une variable, mais de tester si elle est vide.

    Après, cet argument c'est de la merde. Que ce soit une fonction ou un mot clé de la grammaire, on s'en fout c'est un détail d'implémentation.

    L'exemple est risible. empty($var || $var2), ça devrait faire quoi ? Les priorités des opérateurs implique que le || passe en premier. Pour que ça est un sens, conversion en booléen des 2 arguments donc. Donc tester si vrai ou faux c'est vide ? C'est vrai que c'est intéressant comme test.

    Si on veut tester si $var ou $var2 est vide, empty($var) || empty($var2) ça semble quand même parfaitement cohérent.

    Personnellement j'aime pas PHP, mais faut quand même pas raconter n'importe quoi !

    • [^] # Re: .

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      En fait, c'est surtout de ne pas pouvoir faire ça qui est dommage :

      <?php empty($one or $two) ;

      Oui, l'opérateur « or » ne retourne pas un booléen, mais la première variable interprétée comme vraie ou la dernière, contrairement à l'opérateur « || ».

  • # Tu chipotes.

    Posté par  . Évalué à 5.

    Mouais, bon, perso, si je veux montrer un gros défaut de PHP dans sa conception, j'utilise la casse.

    <?php
$a = 3;
echo $A;
?>

    Là, je lance l'interpréteur, tac, variable A undefined.

    Maintenant on essaie ce code là :
    <?php
    function toto() {
    echo "toto";
    }
    toto();
    TOTO();
    ToTo();
     ?>
    Et j'ai bien trois fois toto qui s'affiche.
    Donc en résumé, le langage est sensible à la casse, logique, mais pas pour les fonctions.
    Alors oui, c'est pas dérangeant quand on programme toussa toussa, mais pour moi il y a un certain problème de cohérence dans le langage, et ceci est ce qui doit le mieux le symboliser.

    • [^] # Re: Tu chipotes.

      Posté par  (Mastodon) . Évalué à 3.

      mais pour moi il y a un certain problème de cohérence dans le langage, et ceci est ce qui doit le mieux le symboliser.

      Je trouve que c'est plutôt du côté de la bibliothèque standard que le manque de cohérence est le plus flagrant…

    • [^] # Re: Tu chipotes.

      Posté par  (site web personnel) . Évalué à 5.

      Pour moi, le plus gros défaut est quand même le ==, qui ne sert strictement à rien (comme tout le monde le fait remarquer)… mais pourquoi utiliser le symbole ==, avec un sens différent de celui utilisé dans tous les langages, qui prête à confusion, qui ne sert à rien, et qui a changé de sens entre PHP4 et PHP5 ?

      Les « tableaux » sont également une blague. Les physiciens se plaignent avec la dualité onde-corpuscule, mais que devrait-on dire de ces objets qui se comportent parfois comme des listes, parfois comme des ensembles, et parfois comme des tables de hash ? Impossible de savoir quel sera le comportement adopté en fonction de la situation.

      Je comprends que PHP ait pu avoir du succès à sa sortie, mais actuellement, je ne le comprends plus tellement. Je ne vois pas un seul avantage intrinsèque de PHP par rapport à ses concurrents, notamment par rapport à Python (vu que je maîtrise maintenant assez bien Python, après avoir fait pas mal de PHP).

      • [^] # Re: Tu chipotes.

        Posté par  . Évalué à 1.

        Je comprends que PHP ait pu avoir du succès à sa sortie, mais actuellement, je ne le comprends plus tellement.

        Le poids de l'existant. Quand t'as l'integralite de ta technologie en php, la convertir a autre chose peut vouloir dire la fin de ton business.
        Ton produit n'evolue plus pendant la conversion, ca va probablement prendre des mois/annees, et si tu te rates, t'es mort.

        Meme facebook est verouille dans ce langage, et c'est dur de les accuser de pas regarder les nouvelles technologies.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: Tu chipotes.

        Posté par  (site web personnel) . Évalué à 6.

        Je ne vois pas un seul avantage intrinsèque de PHP par rapport à ses concurrents

        Le drop-on-my-server-and-play?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Tu chipotes.

          Posté par  (site web personnel) . Évalué à 0.

          En effet, c'est peut-être le seul avantage de PHP.
          Mais :
          * ce n'est pas une bonne idée de faire ça,
          * tu peux faire sensiblement la même chose avec Python en CGI.

      • [^] # Re: Tu chipotes.

        Posté par  (site web personnel) . Évalué à 2.

        Je comprends que PHP ait pu avoir du succès à sa sortie, mais actuellement, je ne le comprends plus tellement. Je ne vois pas un seul avantage intrinsèque de PHP par rapport à ses concurrents, notamment par rapport à Python (vu que je maîtrise maintenant assez bien Python, après avoir fait pas mal de PHP).

        Le langage en tant que tel, il n'a aucun avantage. Plutôt des désavantages même (moins puissant et expressif que Ruby ou Python). Par contre, le gros truc de PHP c'est que c'est super simple à déployer : tu copie un .php dans un dossier et tu vas sur http://monserveur/mondossier/fichier.php et c'est bon.

        Python, Ruby et les autre, c'est en général plus compliqué : il faut en général mettre en place un URL dispatcher et utiliser des template pour séparer HTML du code. Au final, ça donne des applis plus propres, mais faut apprendre un peu plus.

        Et puis bon, PHP a l'avantage d'être supporté par tous les fournisseurs d'hébergement web, d'être quasi-intégré à Apache. Par rapport à d'autres langages ou il faut utiliser fastcgi ou autre, c'est plus simple.

    • [^] # Re: Tu chipotes.

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Donc en résumé, le langage est sensible à la casse, logique, mais pas pour les fonctions.

      Autant je suis d'accord pour dire qu'il y a un gros manque de cohérence dans le langage, autant je vois pas pourquoi il est logique qu'un langage soit sensible à la casse. C'est juste une convention.
      D'ailleurs, cette convention, les humains ne la suivent pas forcément . Pour preuve, si je t'écris en mettant Sébastien, sebastien, séBastien ou SEBASTIEN, tu sauras que je parle de toi.
      Ce n'est finalement pas forcément logique d'être case-sensitive. Ce qui l'est, c'est d'y être sensible partout ou nulle part.

Suivre le flux des commentaires

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