Journal Sortie de PHP 5.3

Posté par (page perso) .
Tags : aucun
19
1
juil.
2009
Bonjour à vous,

Le langage PHP est régulièrement critiqué comme étant un langage pour mauvais programmeurs, trop laxiste et ayant des années de retard sur ce que fait Python ou encore Ruby (s'il vous plaît, ne commencez pas les comparaisons stupides en RoR et PHP...), donc bien qu'à priori, cela n'intéressera pas forcément tout le monde, le langage continue d'évoluer et, à mon humble avis, plutôt dans le bon sens.

La sortie de PHP 5.3 apporte son lot de nouveautés et de correction de bugs (une centaine de correction)

Parmi les nouveautés :
  • Une meilleure gestion des méthodes et propriétés statiques avec l'ajout d'une méthode magique __callStatic() permettant la gestion de méthodes statiques non définies. Ou encore la possibilité de faire un appel à une méthode statique avec un nom de classe en variable (de ce style : $class::methode(); )
  • La possibilité d'utiliser des fonctions lambda. Il était déjà possible de créer dynamiquement des fonctions avec la fonction create_function() mais ces dernières n'étaient pas prises en compte dans les système de cache d'opcode et rendaient le code moins lisible
  • L'ajout des fermetures qui ajoutent aux fonctions lambda la possibilité d'utiliser des variables externes. Celle-ci sont passées, par défaut, par valeur ce qui permet de ne pas avoir de résultats indésirables (que l'on pourrait avoir avec l'utilisation d'un global)
  • L'une des fonctionnalités les plus attendues : l'espace de noms. Je ne vous ferez pas l'affront de vous décrire les utilités d'un tel ajout dans le langage mais si vous ne savez ce que cela peut apporter, référez vous aux liens ci-dessous. Des critiques sont notamment apparu sur le choix du séparateur, je me garderais bien de commenter cette décision avant de l'avoir tester plus profondément.
  • L'amélioration du fichier de configuration php.ini qui permet maintenant d'avoir des variables à l'intérieur de ce dernier, très utile pour éviter les redondances (ah si on pouvait avoir la même chose en CSS...). De plus il est possible d'avoir un fichier de configuration par site et/ou par utilisateur (si l'on fonctionne en CGI), très pratique pour donner plus ou moins de droits en fonction de la confiance accordée aux différents usagés de votre serveur.
  • Une meilleure gestion de garbage collector qui avait quelques difficultés avec les objets ayant une relation parent-enfant.
  • Certaines extensions rentre dans le cœur de PHP. C'est le cas de FileInfo (utilisé pour connaitre des informations sur les fichiers), Intl (fonctions pour le support de l'unicode), Phar (fonctions d'empaquetage de fichier et qui permettent également l'utilisation directe de fichier php à l'intérieur de l'archive), mysqlnd (remplacement de l'extension utilisé auparavant par MySQL et MySQLi) et SQLite3 (ah, enfin le support natif de la version 3, il était temps)
  • L'arrivée de la constante d'erreur E_DEPRECATED qui sera renvoyé lors de l'utilisation de fonctions non supportées par la prochaine version de PHP. Parmi ces fonctions dépréciées : ereg_* que l'on conseille de remplacer par preg_* car il n'y aura plus qu'un seul moteur d'expressions régulières ou encore les magic_quotes.
  • Enfin et j'ai préféré garder le meilleur pour la fin. L'instruction bien connue "goto" fait son arrivée. J'aurais pu attendre vendredi rien que pour cette instruction, mais je préfère poster mon premier journal sereinement...

Voilà, cette version de PHP intègre vraiment des choses prometteuses pour les développeurs web. Gageons qu'ils seront en tirer le meilleur.

Pour aller plus loin dans la découverte de PHP 5.3 :
Les nouveautés de PHP 5.3 (sur Developpez.com)
PHP 5.3 : Nouveautés : Introduction et Sommaire (de Pascal Martin)
  • # PHP

    Posté par (page perso) . Évalué à -10.

    PHP, c'est Plutôt Horriblement Pourri.
    Huhu.

    Blague à part, y a quoi comme véritable intérêt à PHP ?
    J'ai jamais compris le goût pour ce langage sans aucune sémantique qui se contente d'empiler bug^wfeature sur feature.
    • [^] # Re: PHP

      Posté par . Évalué à 5.

      Dis comme ça, c'est du fud, De quels bugs parle-tu ? Et un "langage sans sémantique", c'est quoi pour toi ?
      • [^] # Re: PHP

        Posté par (page perso) . Évalué à 10.

        Je cite le "Revised(4) Report on the Algorithmic Language Scheme"

        >> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

        PHP, c'est exactement l'inverse. Y'a qu'à voir, ils mettent en avant une nouvelle méthode magique, des fonctions anonymes, des fermetures, un goto, etc, etc.

        Et l'un des lien précise "ha, c'est chiant, le goto ne permet pas de sauter n'importe où", "le break ne permet pas de s'échapper de plusieurs boucles imbriquées", "le goto n'a pas de portée dynamique" et autres trucs du genre.
        Ensuite le langage appelle tableau des dictionnaires ou tables de hachage.

        Je cite wikipedia au passage qui dit "le nom des fonctions (ainsi que le passage des arguments) ne respecte pas toujours une logique uniforme".


        Bref, toutes ces petites choses qui font la différence entre un langage pensé et développé pour et par des gens intelligents, et le reste dont PHP est selon moi l'un des "meilleurs" représentants.
        Après, si t'es pas d'accord, libre à toi de coder en PHP. J'en dirai toujours du mal, car le langage mal conçu initialement ne pourra *jamais* devenir bien, alors que d'autres langages qui sont partis de bonnes bases formelles et qui évoluent tout autant se rafinent avec le temps.
        • [^] # Re: PHP

          Posté par . Évalué à 7.

          En fait, je suis tout à fait d'accord avec toi, je réagissais sur la forme, et non sur le fond. Belle argumentation cette fois-ci. ;)
        • [^] # Re: PHP

          Posté par (page perso) . Évalué à 10.

          Non mais PHP quand tu abordes ça déjà tu te dis que le langage c'est un vrai bordel. Plus amusant, le bordel est changeant et polymorphe selon les versions du langage, ce qui rend quasi impossible l'écriture de code capable de fonctionner simplement sur plusieurs versions du langage.
          Ajoutons à cela que le langage est assez permissif et neuneu-compliant pour inciter à l'écriture de code illisible, et que la sécurité est une préoccupation qui semble avoir toujours eu une priorité basse sauf peut-être récemment, et on comprend que 99% du code PHP est buggé et souffre de failles persistantes.


          Et puis tu commences à regarder l'API.
          Et là tu pleures.

          Je crois que je n'ai jamais vu un tel bordel. Une tétrachiée de fonctions avec des idées sympas genre:
          - plusieurs fonctions font la même chose
          - plusieurs fonctions se ressemblent, mais ne font pas la même chose
          - plusieurs fonctions sont voisines, mais l'ordre de leurs arguments est subtilement différent
          - une fonction a une fonctionnalité qui change complètement selon le nombre d'arguments qu'on lui passe.
          - le nommage est aléatoire. parfois il y a un préfixe devant les noms de fonctions d'une même API, parfois pas.
          - Il n'y a de toutes façons pas de convention de nommage. fonction(), api_fonction(), ApiFonction() et diverses autres conventions se mélangent allègrement.
          - des fonctions non documentées
          - des fonctions dons la doc (uniquement dispo en ligne, trop de la balle pour développer quand t'as pas une connexion internet) qui disent que ça marche pas
          - etc, etc.

          Ce langage n'est qu'un ramassis de verrues qui ont poussé sur un truc qui était à l'origine pas fait pour (Personnal Home Page que ça voulait dire PHP, c'était pas pour rien), et ça se voit. Sa seule chance a dû être de disposer d'un module Apache et d'être assez facile à utiliser pour que les hébergeurs s'y intéressent et le proposent à leur clients.
          • [^] # Re: PHP

            Posté par . Évalué à 3.

            Allez encore une nouvelle extension Mysql, ce sera juste la... troisième !
            Comme DOM, DomXML... bordel courant récurrent
            Java avait introduit les avertissements de dépréciation dès le début. PHP a du attendre la 5.3, qui introduit pourtant des changements mineurs par rapport au passage 4->5.
            Vraiment du n'importe quoi.
        • [^] # Re: PHP

          Posté par (page perso) . Évalué à 9.

          Moi je connais l'intérêt de coder en php. Ça permet de garantir ton boulot de webmestre à vie. Ou ça permet aux SSII qui repassent derrière de se faire un max de pognon. Ça permet aussi à tous les neuneux qui débarquent sur le marché du travail d'en trouver facilement et de créer plein de nouveaux emplois.

          Vraiment en ces périodes de crises, PHP, c'est le langage qui va vous permettre de passer à côté de la charrette.
    • [^] # Re: PHP

      Posté par . Évalué à 3.

      T'as raison, Perl vaincra !

      En plus, en Perl, on peut être encore plus crade qu'en Php.

      D'ailleurs, je me demandais, si on met de côté les langages de laboratoire ( Brainfuck, Malbolge...), quel est le langage suprême en terme de cochonneries que l'on peut trouver couramment en production ?
      Allez, vous êtes tous tombés un jour sur des scripts non-commentés, tordus, incompréhensibles tellement le langage utilisé permettait d'écrire en mode sale... A part Perl et Php, avez-vous de telles expériences avec d'autres langages ?
      • [^] # Re: PHP

        Posté par (page perso) . Évalué à 7.

        Java avec un tas de frameworks !
      • [^] # Re: PHP

        Posté par (page perso) . Évalué à 5.

        quel est le langage suprême en terme de cochonneries que l'on peut trouver couramment en production ?
        Le C voyons

        D'ailleurs comme on dit :
        Le langage C combine l'efficacité de l'assembleur avec la lisibilité de l'assembleur

        Sans parler du mondialement connu concours du IOCCC (International Obfuscated C Code Contest) http://www.de.ioccc.org/main.html .

        Dans mon expérience, le C est un des langages qui permet de faire du code très sale, à plus forte raison quand on commence à jongler avec les macros et les différentes API qui n'ont pas la même convention de syntaxe...
        • [^] # Re: PHP

          Posté par . Évalué à 5.

          oui enfin tu peux faire des choses très sales avec ta femme aussi, ou avec ton chien (mais ça ne nous regarde pas), ça ne veut pas dire que tu le feras.
          • [^] # Re: PHP

            Posté par (page perso) . Évalué à 5.

            oui enfin tu peux faire des choses très sales avec ta femme aussi, [...], ça ne veut pas dire que tu le feras.

            Mais tu aurais bien tort de ne pas le faire :o)
          • [^] # Re: PHP

            Posté par . Évalué à 4.

            Donc si je résume: en PHP, tu peux faire des choses (très) sales, mais çà ne veut pas dire que tu le feras et tu peux coder proprement ?
      • [^] # Re: PHP

        Posté par . Évalué à 5.

        Il y a encore pire que PHP : les "progiciels" qui viennent avec leur propre langage. Généralement vendus avec la recette "Vous achetez un logiciel propriétaire super cher, mais vous pouvez scripter vous meme les fonctions", ils sont généralement atrocement mal concus, peu puissants, les parseurs sont buggés, ont des tas de fonctions magiques absolument pas documentés (sauf dans la tête du consultant...)

        J'ai des exemples mais ils sont souvent assez spécifique à mon domaine...Pourtant je suis sur que tout le monde a rencontré ces horreurs :)
        • [^] # Re: PHP

          Posté par . Évalué à 3.

          Au hasard ... SAP R/3 (c'est le premier exemple qui me vient à l'esprit) ?

          Un autre truc complêtement pourri : BladeLogic.
    • [^] # Re: PHP

      Posté par (page perso) . Évalué à 4.

      J'ai bien suivi l'argumentation, je suis d'accord et j'aimerais ne plus dependre de PHP. Quelle alternative est la plus facile a aborder (en terme de simplicite et de populartite)?
      • [^] # Re: PHP

        Posté par . Évalué à 10.

        Python ?

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

        • [^] # Re: PHP

          Posté par . Évalué à 1.

          Non, on a dit sérieux. (ah, c'est pas vendredi ?)
      • [^] # Re: PHP

        Posté par . Évalué à 3.

        Personnellement je suis très satisfait de Ruby/Rails.

        Un peu difficile au début, car le framework Rails bouge beaucoup et la documentation a parfois un peu de mal à suivre, mais une fois qu'on a compris le truc, ça va tout seul.
        • [^] # Re: PHP

          Posté par . Évalué à 1.

          Ouais, j'ai cru voir que c'était puissant, en me documentant un peu et en jouant 5 minutes avec.

          Cela dit, si RoR bouge tous les 6 mois, ça doit pas être fastoche de faire de la production... ou du moins, à chaque mise à jour, ça doit être coûteux en temps de validation, de correction, etc...
          Pour un petit site dynamique, ça peut encore passer, mais si l'on décide de coder une *grosse* application avec RoR, ça doit pas mal compliquer la tâche...

          Vous avez des retours d'expérience là-dessus ?
          • [^] # Re: PHP

            Posté par (page perso) . Évalué à 2.

            Je trouve sa question intéressante, puisque je me la pose aussi. Est-il risqué d'un point de vue compatibilité descendante d'investir dans RoR ?
            • [^] # Re: PHP

              Posté par . Évalué à 2.

              C'est comme pour toute echno : a un instant T tu choisis une verson V et tu n'en bouges pas ......

              Je n'ai pas suffisamment de recul mais il me semble également que du code écrit pour une version N de rails fonctionnera avec une versio n+x.

              Le temps et l'investissement passés à l'apprendre sont largement compensés par la puissance du langage/framework.
    • [^] # Re: PHP

      Posté par . Évalué à 3.

      C'est à se demander pourquoi ces cons d'hébergeurs se sont mis d'accord avec ces imbéciles de développeurs de CMS pour le mettre quasiment partout!
      • [^] # Re: PHP

        Posté par . Évalué à 9.

        Bah c'est connu, ya un complot organisé par des sociétés secrètes qui descendent des templiers pour que PHP soit utilisé partout. Tout le monde le sait.
      • [^] # Re: PHP

        Posté par . Évalué à 2.

        Effet boule de neige ? À une époque je suppose que c'était le plus abordable (au niveau courbe d'apprentissage) et/ou le plsu facile à mettre en place sur des serveurs (supposition toujours). Du coup il y a eu plein de développeurs, et donc de plus en plus d'hébergeurs, etc.

        Pour faire un parallèle :

        C'est à se demander pourquoi ces cons de fabricants d'ordinateurs se sont mis d'accord avec ces imbéciles de développeurs d'applications pour mettre Windows quasiment partout!

        Tu trouves toujours que les parts de marchés sont un argument quant à la qualité d'un produit ? :o)
        • [^] # Re: PHP

          Posté par . Évalué à 3.

          Certes non, mais des CMS sous Java et Python, ça existe (Zope, pour ne citer qu'un "pas connu" ;) ).
          Alors pourquoi les hébergeurs qui proposent des CMS par défaut ne proposent-ils pas Zope par défaut et option PHP plutôt que le contraire?

          Pour revenir sur la comparaison, c'est MS qui se met d'accord tout seul pour flinguer tout constructeur qui ne proposerait pas Windows partout et mis en valeur. Je vois pas la communauté PHP menacer les hébergeurs, et ceux qui proposent du Python ne sont pas légions.

          Alors je ne dis pas que PHP c'est mieux que Python, je dis juste que si c'était si mauvais, nombreux sont ceux qui seraient passés à autre chose, non?

          J'aimerais avoir des retours de développeurs de CMS sur la pertinence du "Python est vachement meilleur que PHP".
          • [^] # Re: PHP

            Posté par . Évalué à 2.

            C'est peut-être dû à l'effet d'inertie ?

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

          • [^] # Re: PHP

            Posté par . Évalué à 7.

            Alors je ne dis pas que PHP c'est mieux que Python, je dis juste que si c'était si mauvais, nombreux sont ceux qui seraient passés à autre chose, non?

            Non, c'est justement parce que c'est mauvis que c'est répandu ...
        • [^] # Re: PHP

          Posté par . Évalué à 1.

          Oui ..... Plus c'est merdique (donc pas cher) plus c'est vendu.

          Ya qu'a voir la musique. En plus si on a les moyens de faire un buzz dessus, c'est gagné.
  • # GOTO : Nostalgie...

    Posté par . Évalué à 3.

    Ah, le GOTO, tellement de souvenirs !

    Je me souviens que j'ai commencé à programmer sur un MSX, en basic. Bien sur ligne numérotées, et à la toque de GOTO. Un bon code est un code à base de GOTO (-:

    Quand je suis arrivé à l'IUT et qu'on a commencé à coder en Ada, ça m'a foutu un choc. Impossible d'arriver à faire quoi que ce soit avec ce fichu langage !!! Pouah !!! Manquait plus qu'on m'enseigne les fonctions et là, vraiment, j'étais largué.

    Bon, évidemment, maintenant que beaucoup d'eau a coulé sous les ponts, ça me ferait vraiment tout drôle de refaire du code avec un GOTO dedans... mis à part un petit coup de nostalgie, il y a une vraie utilité au GOTO ?
    • [^] # Re: GOTO : Nostalgie...

      Posté par (page perso) . Évalué à 10.

      non
    • [^] # Re: GOTO : Nostalgie...

      Posté par . Évalué à 10.

      Une des rares utilités du goto, c'est pour les langages qui ne supportent pas les exceptions (C, par exemple), ça permet de simplifier le code de gestion d'erreur. C'est utilisé couramment dans le noyau Linux, par exemple.

      Dans un langage avec des exceptions, par contre, j'ai vraiment du mal à voir à quoi ça sert.
      • [^] # Re: GOTO : Nostalgie...

        Posté par . Évalué à 3.

        Mais comme PHP n'est pas foutu d'utiliser ses propres fonctionnalités (en l'occurrence, je parle des exceptions), on comprend de suite pourquoi ils ont rajouté le goto !
      • [^] # Re: GOTO : Nostalgie...

        Posté par . Évalué à 3.

        Moi, je m'en sers entre autre pour faire débuter le premier cycle d'une boucle while un peu plus loin que le début. Ça permet de gérer tous les cas de type « 1 + le reste » sans avoir à faire un test à chaque itération.

        Cependant, le goto est tellement banni de nos jours qu'on ne peut même plus se permettre de l'utiliser dans des cas légitimes (les gens préférent presque voir une variable à la place). Je suis d'accord qu'il ne faut pas habituer les jeunes programmeurs à y recourir systématiquement mais là, plus personne ou presque ne sait aujourd'hui pourquoi cette instruction est tant proscrite.

        À dire vrai, je milite pour la rédaction un guide du bon usage du goto et pour son enseignement « propre » dans les écoles. Pour certains, n'importe quelle horreur est préférable à un goto (par exemple des exit() au beau milieu d'une procédure).
        • [^] # Re: GOTO : Nostalgie...

          Posté par (page perso) . Évalué à 5.

          Moi, je m'en sers entre autre pour faire débuter le premier cycle d'une boucle while un peu plus loin que le début. Ça permet de gérer tous les cas de type « 1 + le reste » sans avoir à faire un test à chaque itération.

          Heu... tu peux fournir un exemple?
          Car tel que tu le dis, je fais juste un do{} while() à la place de while(){} et c'est réglé, donc je ne vois toujours pas d'utilité à goto.
          • [^] # Re: GOTO : Nostalgie...

            Posté par . Évalué à 4.


            int x,y;

            x=1;
            y=5;

            goto entree:
            do
            {
            printf ("-");
            entree:
            printf ("%d",x);
            }
            while (x<5);


            1-2-3-4-5
            • [^] # Re: GOTO : Nostalgie...

              Posté par . Évalué à 3.

              Édit après relecture : il faut lire while(x<y) (ou virer y) et mettre un x++ quelque part, bien sûr. Mais le principe reste le même.
            • [^] # Re: GOTO : Nostalgie...

              Posté par . Évalué à 1.

              Manque un X++ sinon ton code donne 1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1
            • [^] # Re: GOTO : Nostalgie...

              Posté par (page perso) . Évalué à 2.

              bouuuuuu le påbôvläin

              déjà comme ca, le compilo C (admettons qu'on donne ca à manger à un compilo C dans un bô main tout propre) va faire plop !
              parce que c'est pas goto entree: qu'il faut mettre mais goto entree;

              ensuite si tu colles tout ca dans un beau main, ca va faire :
              1-1-1-1-1-1-1-1-1-1-1-1-1-1[...]

              parce qu'il faut mettre printf("%d", x++);

              enfin, ca affichera 1-2-3-4 parce que while (x<5) s'arrêtera lorsque x==5 donc pan !

              et peux-tu m'expliquer l'intérêt de y=5; vu que tu t'en sers pas, mmmmmm ?

              Nous avons ici, mesdames et messieurs la preuve irréfutable que le GOTO est considéré comme nuisible !
            • [^] # Re: GOTO : Nostalgie...

              Posté par . Évalué à 5.

              aux erreurs citées ci-dessus près, je vois ce que tu veux dire (-:

              c'est vrai qu'un poil documenté (un simple commentaire "on saute le premier '-' pour afficher un chiffre d'abord") permet au code d'être parfaitement maintenable.

              on ne peut pas dire que ce soit particulièrement crasseux.
            • [^] # Re: GOTO : Nostalgie...

              Posté par . Évalué à 1.


              for( int x = 1; ;++x )
              {
              printf "%d",x);

              if( x >= 5 )
              break;

              printf ( " - " );

              }


              Tant pis pour les quotes...
              • [^] # Re: GOTO : Nostalgie...

                Posté par . Évalué à 2.

                En effet, on peut faire un break.

                Mais niveau "propreté", c'est pas génial, j'en suis à peu près aussi fan que le GOTO. Sans compter que tu passes ton temps à faire un "if" supplémentaire dans ta boucle, uniquement pour ce break. Le GOTO a l'avantage de ne pas alourdir du tout ton code (mais je suis le premier à préférer la propreté à l'efficacité pure et simple).

                Et au passage le "++x" est vraiment moche, et très dangereux. De là où je viens, c'est même formellement interdit !
                • [^] # Re: GOTO : Nostalgie...

                  Posté par . Évalué à 3.

                  Et surtout, le if() à chaque itération était l'une des choses que je cherche précisément à éviter dans mon premier commentaire.

                  Par contre, je suis assez fan des pré-incrémentations, aussi. Peux-tu nous expliquer pourquoi elles sont proscrites par chez toi ?
                • [^] # Re: GOTO : Nostalgie...

                  Posté par (page perso) . Évalué à 3.

                  C'est rigolo, de là où je viens c'est x++ qui est considéré comme très dangereux, et qui est très déconseillé.

                  En effet, en C++, lorsque l'on post incrémente un gros objet, le compilateur peut avoir envi de faire une grosse copie qui ne sert à rien.

                  Après certains optimisent, mais c'est bien de le faire directement comme il faut.

                  Envoyé depuis mon lapin.

                  • [^] # Re: GOTO : Nostalgie...

                    Posté par . Évalué à 3.

                    (je réponds aux 2).

                    "chez moi", c'est le développement logiciel embarqué avionique.

                    les règles sont simple : une seulke instruction par ligne. du coup ca élimine de fait le ++x ainsi que le x++. exception : la boucle for dans sa forme de base : for(i=min;i<=max;i++)

                    sur une seule ligne on a le droit de faire x++ (on ne nous oblige pas à faire x=x+1) (et je crois que x+=1 est interdit aussi).

                    le ++x est strictement interdit.

                    je pense que la raison de toutes ces règles est uniquement la clarté du code. les formes abrégées sont généralement proscrite, puisque le code de toute façon sera le meme, autant explicité les traitements.
                    • [^] # Re: GOTO : Nostalgie...

                      Posté par (page perso) . Évalué à 1.

                      Bon, je comprends bien l'idée d'une seule instruction par ligne, mais raison de plus pour ne pas utiliser x++.

                      ++x, c'est:
                      x = x+1;

                      x++, c'est:
                      temp = x;
                      temp = temp +1;
                      x = temp;

                      Cette copie n'est utile que lorsque l'on passe un objet en paramètre d'une fonction, et que l'on veut qu'il soit incrémenté juste après son passage en tant que paramètre.

                      Et c'est justement que que tu ne dois pas faire.

                      Envoyé depuis mon lapin.

                      • [^] # Commentaire supprimé

                        Posté par . Évalué à 5.

                        Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à 3.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: GOTO : Nostalgie...

                            Posté par . Évalué à 0.

                            En cycle processeur, c'est donc, kif-kif (add ou inc à notre époque c'est 1 cycle)
                            Perdu. inc et add ne sont pas toujours équivalents en termes de vitesse d'exécution (par exemple sur les processeurs de type x86).
                        • [^] # Re: GOTO : Nostalgie...

                          Posté par . Évalué à 6.

                          Ça, c'est un autre troll débat.

                          D'une part, la lisibilité est une notion très subjective. Ça peut être justifié mais, huit fois sur dix, quand on dit qu'un code n'est pas lisible, c'est que l'on manque d'argument. Un « ++x » ni plus ni moins lisible qu'un « x++ ». C'est un peu comme polémiquer pour savoir s'il faut mettre l'accolade ouvrante « {&nsbp;» à droite ou en dessous du nom de la fonction (je la mets en dessous).

                          Ensuite, écrire du code d'une certaine façon en tablant sur le fait que le compilateur va l'optimiser ensuite n'est pas une raison valable à elle seule d'adopter une manière d'écrire plutôt qu'une autre. D'abord parce que ce n'est pas garanti (dépend du compilateur) et qu'ensuite, ça ne sert à rien d'écrire d'une certaine manière si l'on veut que ce soit traduit de façon complètement différente.
                          • [^] # Commentaire supprimé

                            Posté par . Évalué à 1.

                            Ce commentaire a été supprimé par l'équipe de modération.

                            • [^] # Re: GOTO : Nostalgie...

                              Posté par (page perso) . Évalué à 4.

                              C'est trivial pour un type de base. Pas pour un objet.

                              Après, peut-être que tu n'incrémente pas des objets tout les jours, mais ça arrive. Et là, ce n'est plus du tout trivial.

                              Envoyé depuis mon lapin.

                              • [^] # Commentaire supprimé

                                Posté par . Évalué à 2.

                                Ce commentaire a été supprimé par l'équipe de modération.

                                • [^] # Re: GOTO : Nostalgie...

                                  Posté par . Évalué à 4.

                                  Tu n'a aucune garantie que le constructeur de l'objet n'a pas un effet de bord. (surtout si tu n'a pas le source).

                                  Sans parler que en C++, a++ et ++a sont deux fonctions différentes, et qu'un programmeur pourrait décider par exemple, d'implémenter un copy-on-write, et ça c'est moins évident à optimiser pour un compilateur.
                        • [^] # Re: GOTO : Nostalgie...

                          Posté par (page perso) . Évalué à 0.

                          J'espère bien qu'il est capable d'optimiser ce passage.

                          Mais autant faire ce qu'il faut directement. Interdire la version qui fait directement ce qu'il faut au profit d'une autre qui nécessite une étape de plus, même si elle est supprimée par certains compilateurs, c'est étrange.

                          Et ton passage sur l'assembleur n'est valable que pour un certain type de variable.
                          Si tu veut incrémenter un objet qui est très gros (disons 150 octets, il contient du texte par exemple), c'est pas vraiment pareil.

                          Envoyé depuis mon lapin.

                          • [^] # Commentaire supprimé

                            Posté par . Évalué à 1.

                            Ce commentaire a été supprimé par l'équipe de modération.

                            • [^] # Re: GOTO : Nostalgie...

                              Posté par (page perso) . Évalué à 1.

                              Faire confiance à un compilateur que l'on ne connait pas (il peut changer), ou faire confiance à son code, telle est la question.

                              C'est certain qu'avec gcc, tu risques pas d'avoir une grande différence. Mais après c'est encore une fois un tout petit truc où il faut faire un choix.
                              Ce qui change est très léger, mais est légèrement mieux.

                              Mais comme le compilateur fait le travail à ta place, autant faire la mauvaise solution dans ce cas là.

                              Envoyé depuis mon lapin.

                              • [^] # Commentaire supprimé

                                Posté par . Évalué à 5.

                                Ce commentaire a été supprimé par l'équipe de modération.

                                • [^] # Re: GOTO : Nostalgie...

                                  Posté par (page perso) . Évalué à 2.

                                  C'est peut-être parce que je parlais dans le cas du C++ que l'on était pas d'accord.

                                  D'ailleurs, je viens de regarder les profils des opérateurs pour incrémenter des objets, et pour la post incrémentation, c'est :
                                  Lol * const operator++ (int)

                                  et dans le cas de la prés incrémentation, c'est:
                                  Lol * const operator++ (void)

                                  Le int en argument n'est là que pour différencier les deux fonctions, c'est pas vraiment beau.

                                  Dans le cas de la post incrémentation, tu es censé renvoyer une copie avant modification (sinon, tu ne respecte pas les conventions de codage), et là c'est ton code. Après, le compilateur peut s'amuser à supprimer le passage où tu fais la copie, ainsi que le renvoi du pointeur, mais c'est toujours la même histoire, doit-on faire confiance au compilateur ?

                                  Envoyé depuis mon lapin.

                    • [^] # Re: GOTO : Nostalgie...

                      Posté par . Évalué à 0.

                      les règles sont simple : une seulke instruction par ligne. du coup ca élimine de fait le ++x ainsi que le x++. exception : la boucle for dans sa forme de base : for(i=min;i<=max;i++)

                      Mais qu'appelles-tu une "instruction" ? C++ n'est pas assez bas-niveau (proche de la machine) pour que cette notion ait un sens. Quoique tu écrives, sur une ligne ou sur plusieurs, tu ne peux pas garantir le code machine généré. A mon avis, à part pour des cas très spécifique (peut-être que ton métier est dans ce cas ceci-dit), il faut justement laisser les considérations que tu cites de côté afin de se concentrer sur l'aspect métier du code.
                      • [^] # Re: GOTO : Nostalgie...

                        Posté par . Évalué à 2.

                        Ça doit vouloir dire pas des horreurs du style :

                        i = prout( (bla,i++) , procedureaveceffetdebord(parametre--,&i), i ;

                        Genre ça doit être à peu prêt valide en C si je me trompes pas, mais pour savoir ce qui se passe ... C'est pas trivial genre.
                        • [^] # Re: GOTO : Nostalgie...

                          Posté par . Évalué à 2.

                          Manque une parenthèse : i = prout( (bla,i++) , procedureaveceffetdebord(parametre--,&i) ), i ;


                          Encore pire peut être :
                          i,j = ( prout( (bla,i++) , procedureaveceffetdebord(parametre--,&i) ), i ) , a ;
                • [^] # Re: GOTO : Nostalgie...

                  Posté par . Évalué à 2.

                  Et au passage le "++x" est vraiment moche, et très dangereux. De là où je viens, c'est même formellement interdit !

                  Tu peux argumenter s'il te plaît ? De là où je viens, ++x est moins dangereux que x++, vu que l'incrémentation est d'abord faite, et que du coup, x n'est évalué qu'une fois (en C on s'en fout, en C++, ça a son importance, si x est une instance de classe et que ++ a été surchargé ...).
        • [^] # Re: GOTO : Nostalgie...

          Posté par . Évalué à 3.

          Comme dit précédemment, le goto est très bien lorsqu'il faut gérer des catastrophes. En fait une règle à laquelle il faut se conformer à mon avis est de toujours utiliser goto pour faire des sauts en avant.

          Sinon, utiliser un goto pour créer un 2è point d'entrée dans une boucle n'est pas toujours une bonne idée je pense, car s'il s'agit d'un langage compilé, le compilateur va avoir beaucoup plus de mal à optimiser le code (un compilateur aime bien quand les nœuds de ses graphes sont simples à gérer). Certaines transformations optimisantes sur les boucles nécessitent que celles-ci disposent de certaines propriétés, et le goto casse tout ça. Si la boucle n'est pas souvent prise, on s'en fiche, bien sûr. Mais dans le cas contraire...
      • [^] # Re: GOTO : Nostalgie...

        Posté par (page perso) . Évalué à 1.

        > les langages qui ne supportent pas les exceptions (C, par exemple)

        En bidouillant un peu, il y a moyen de se faire des macros qui font des exceptions presque comme en C++ ou Java : http://adomas.org/excc/

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: GOTO : Nostalgie...

      Posté par . Évalué à 4.

      Goto et ses variantes sont utiles dans les langages qui servent à réaliser des interprètes de code, ou que l'on utilise comme langage cible d'un compilateur. Par exemple, l'interprète d'Objective Caml est nettement plus rapide lorsqu'il est compilé avec gcc qu'avec MS Visual C, parce que ce dernier ne prend pas en charge les goto calculés.

      (/me se rappelle encore avoir appris la subtile distinction entre GOTO et GOSUB…).
    • [^] # Re: GOTO : Nostalgie...

      Posté par . Évalué à 5.

      oui

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: GOTO : Nostalgie...

      Posté par (page perso) . Évalué à 1.

      Si je dis que je simule des goto avec une boucle do ... while et un switch, ça va faire rire ? (en tout cas dans 2 ans j'ai plus besoin de simuler).

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

    • [^] # Re: GOTO : Nostalgie...

      Posté par (page perso) . Évalué à 2.

      il y a une vraie utilité au GOTO ?

      En général c'est employé pour la gestion des erreurs (en C), ça rend le code plus clair en évitant des multiples if imbriqués.

      les pixels au peuple !

    • [^] # Re: GOTO : Nostalgie...

      Posté par . Évalué à 3.

      > mis à part un petit coup de nostalgie, il y a une vraie utilité au GOTO ?

      La gestion d'erreur.
      En C++ on fait une exception, en C un goto (ou un longjmp).

      J'ai fait du code avec des goto pour gérer les erreurs (du moins en sortir), ben sans goto c'est un cauchemard.
      Mais il est clair que le C++ avec les exception c'est beaucoup mieux.
    • [^] # Re: GOTO : Nostalgie...

      Posté par . Évalué à 2.

      Je réponds pas directement à ton commentaire mais au titre GOTO;
      Je me souviens d'un bouquin supra utile sur l'optimisation de code;
      Et le mec disait en gros « Parfois il est plus utile d'utiliser un GOTO bien placé et bien optimisé que des imbrications de if et else qui rendent votre application illisible, non-optimisée, non-optimisable et donne des codes assembleurs de 15 km » (en somme, c'est pas le langage qui fera que votre application sera optimisé mais votre code)
      • [^] # Re: GOTO : Nostalgie...

        Posté par . Évalué à 2.

        C'est assez utile dans les languages qui n'ont pas vraiment d'instruction de structure.
        En robotique, automates programmables ou encore les machines à commande numérique : (l'instruction G79 en language ISO 6983)....C'est pas des GOTO mais ça fonctionne pareil
      • [^] # Re: GOTO : Nostalgie...

        Posté par . Évalué à 5.

        Et le mec disait en gros « Parfois il est plus utile d'utiliser un GOTO bien placé et bien optimisé que des imbrications de if et else qui rendent votre application illisible, non-optimisée, non-optimisable et donne des codes assembleurs de 15 km »

        En même temps, moi je suis assez fan des « if » imbriqués, aussi. En fait, je trouve que l'essence même de la programmation structurée se trouve là-dedans : pouvoir identifier au niveau formel la route suivie par le code.

        Je trouve ça beaucoup plus propre que de tout mettre à plat et de quitter la fonction avec un return (qui est un goto déguisé, quand il ne se trouve pas en fin de fonction) dès que quelque chose cloche. D'abord, parce que quand on élabore un processus complexe où chaque opération est dépendante de la première, il devient très difficile de déconstruire ce que l'on a fait dans les lignes précédentes si une condition vient à ne pas être remplie et qu'il faut avorter le processus, ensuite parce que la prochaine action ne peut être déterminée qu'en connaissant l'état de la machine au run-time.

        À contrario, des « if » imbriqués ne sont pas si illisbles que çà, surtout s'ils sont proprement indentés : en choisissant par exemple une largeur de 4 caractères, on peut descendre jusqu'au dixième niveau d'imbrication − rarement atteint en pratique − sans dépasser la moitié de la zone d'édition sur un terminal ou une vieille imprimante matricielle en 80 colonnes. En travaillant sous X-Window avec un écran plat moderne au format 16:9, j'ai un terminal de 208 colonnes. Je peux en ouvrir deux cotes à cotes et avoir encore de la place dans chacun d'eux.

        En outre, cela structure le code dès le niveau syntaxique : quoi qu'il se passe, tout ce qui est dépendant d'une condition se trouve à l'intérieur d'un bloc. Ça permet entre autre d'utiliser facilement les fonctions de repliement de son éditeur de texte préféré. On pourrait même imaginer combiner cette fonction de repliement à l'état du debugger si on pouvait garantir que tous les programmes sources étaient rédigés de cette façon.

        Ça permet également de poser tout de suite les post-conditions : par exemple, si la première étape d'un long cheminement consiste à ouvrir un fichier, eh bien je teste la validité du handler dans mon if(), j'ouvre le bloc et je place tout de suite le close() à la fin. Ensuite, j'insère la suite de mon code entre le début du bloc et ce close(). De fait, je suis sûr de ne jamais l'oublier, que la suite du programme réussisse ou échoue. Ça permet de maintenir un programme sur de nombreuses années, y compris par plusieurs personnes différentes, qui n'ont pas besoin de savoir a priori que cela a été écrit auparavant. Dans le cas contraire, il faut mettre en place une procédure de sortie anticipée et penser à la remplir au fur et à mesure que le code évolue.
        • [^] # Re: GOTO : Nostalgie...

          Posté par . Évalué à 1.

          J'aime pas les réponses toutes faites et en anglais. Mais là je fais une exception dans le but (illusoire, je sais) d'éviter un flamewar

          http://kerneltrap.org/node/553/2131
          • [^] # Re: GOTO : Nostalgie...

            Posté par . Évalué à 2.

            Si tu remontes le fil et prends le temps de le lire, tu verras que je ne suis pas opposé aux gotos, bien au contraire, et notamment pour les raisons qu'expose Linus.
        • [^] # Re: GOTO : Nostalgie...

          Posté par . Évalué à 7.

          > dans mon if(), j'ouvre le bloc

          Ca laisse supposer que tout le monde utilise un éditeur qui fait des display par bloc;
          Perso dans mon vi, j'ai pas mis l'option et quand je vois des if de plusieurs kilomètres et qu'à la fin, je sais même plus où se trouve le ''if-end'', ca me perturbe beaucoup plus qu'un

          if(!good)
          return(false);

          Les if imbriqués sur plusieurs km me font parfois penser à du HTML/XML: à la fin, on ne sait même plus pour qui est le tag de terminaison (surtout si on a bien fait des div parfout)
  • # J'aime bien PHP

    Posté par (page perso) . Évalué à 10.

    Tout le monde critique PHP, on dirait que je suis le seul à bien l'aimer.

    On le trouve partout et c'est facile à utiliser, tac un index.php et c'est parti.
    Le code ressemble beaucoup au C++, ca m'arrange.
    La doc est accessible facilement, en français et en anglais.
    Beaucoup de tutoriels et d'exemple un peu partout.
    La lisibilité du code dépend vraiment de celui qui l'écrit, et ca c'est pas seulement en PHP, et je n'ai jamais aimé l'indentation forcée en Python.

    Pour Python, j'ai jamais vu des tutoriels simples sur comment l'utiliser pour faire un site, et comment l'interfacer avec le Python.

    Je pense me faire moinsser, mais lisez bien "pertinent", "inutile", il n'y a pas "je ne suis pas d'accord".

    Pourtant Python est pas mal fait, et j'aimerais utiliser Pygments.

    « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

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

      Posté par . Évalué à 1.

      Moi aussi t'inquiète en plus avec Symfony c'est de la bal ;) ... Yahoo l'utilise ...

      Parce que python ou ruby c'est super mais si t'es un ptit webmaster va trouver un hébergement mutualisé pas chère ... bon il y en a mais pas autant que LAMP.

      Laisses les faire ils doivent sûrement préférer ASP ou C#.

      Sinon j'ai installer pentaho et openbravo (appli JAVA), ce sont de ces usines gaz comparés a un vtiger, joomla et consors ...

      De toute façon on peut faire n'importe quoi avec n'importe quel langage ( à part ADA peut être)

      Oh oui moinsser moi ;) !!
    • [^] # Re: J'aime bien PHP

      Posté par (page perso) . Évalué à 10.

      Tout le monde critique windows XP, on dirait que je suis le seul à bien l'aimer.

      On le trouve partout et c'est facile à utiliser, tac un menu démarrer et c'est parti.
      L'interface e code ressemble beaucoup à win98, ca m'arrange.
      La doc est accessible facilement, en français et en anglais.
      Beaucoup de tutoriels et d'exemple un peu partout.
      L'utilisabilité du système dépend vraiment de celui qui est admin, et ca c'est pas seulement avec winxp, et je n'ai jamais aimé l'organisation forcée des macs.





      Bon, tu auras remarqué une ressemblance pas fortuite.
      Le fait que ce soit partout, documenté par jean-kevin, et géré par son petit-frère ne rend pas le truc bien.
      Personnellement, je préfère les trucs obscures qui font exactement ce qu'on leur demande, qui le font bien, et tant pis si je dois faire une entorse à mon indentation habituelle ou à mon paradigme de programmation favori.

      D'ailleurs, pour beaucoup de sites web dynamiques, il serait plus utile de filer un accès à la base de donnée, et de filer les specs des tables pour qu'on code un client au niveau OSI 7 qui récupère et traite les données proprement, sans passer par HTTP(S) qui n'est souvent pas fait pour ça.

      Sur ces entrefaits, je vais coder une interface NNTP en APL pour lire les journaux sur ma chaîne hi-fi.
      • [^] # Re: J'aime bien PHP

        Posté par . Évalué à 1.

        Concernant ton idée, je suis assez d'accord avec toi. "Logiquement", tout ça n'a rien à faire au niveau du serveur, c'est pourquoi je suis pour les applis web "2 tiers": un client web, une base de donnée. Par exemple, persevere (http://sitepen.com/labs/persevere.php) fait ca très bien.
      • [^] # Re: J'aime bien PHP

        Posté par . Évalué à -4.

        Je vois mal la comparaison avec Windows.

        1) PHP est un logiciel libre, donc tu peux le patcher pour qu'il corresponde mieux à tes besoins.

        2) PHP n'est pas en position de monopole, donc tu peux utiliser autre chose sans (passer pour un extraterrestre|être coincé par un problème de driver).
      • [^] # Re: J'aime bien PHP

        Posté par . Évalué à 1.

        > Le fait que ce soit partout, documenté par jean-kevin, et géré par son petit-frère

        WTF ?!!
        T'as craqué là.
      • [^] # Re: J'aime bien PHP

        Posté par (page perso) . Évalué à 2.

        D'ailleurs, pour beaucoup de sites web dynamiques, il serait plus utile de filer un accès à la base de donnée, et de filer les specs des tables pour qu'on code un client au niveau OSI 7 qui récupère et traite les données proprement, sans passer par HTTP(S) qui n'est souvent pas fait pour ça.

        Je penses pas que le monde est prêt à avoir une application à installer à chaque fois qu'il veut voir une site.

        Je suis d'accord avec le fait qu'on est un peu en train de faire passer n'importe quel protocole encapsulé dans du HTTP, mais de là à avoir un client par site web ... (où alors il y a google).

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

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

          Posté par . Évalué à 2.

          Ce que j'ai compris de sa phrase, c'est développer un client web qui fasse ça, et pas le serveur. Le serveur sert des données, point. Tout le reste est sur le client.
      • [^] # Re: J'aime bien PHP

        Posté par (page perso) . Évalué à 3.

        Le fait que ce soit partout, documenté par jean-kevin, et géré par son petit-frère ne rend pas le truc bien.

        Désolé de te le dire à toi personnelement car tu n'es pas le seul, mais tu te crois supérieur !
        Le mec qui a trouvé une astuce pour afficher un tableau proprement, il est content de lui, et alors, pas la peine de l'appeler un kevin.
        Le fait que PHP soit bien documenté et que plein de gens en parlent dans leurs blogs et dans les forums, c'est pas un hasard.

        « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

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

          Posté par . Évalué à 2.

          Le fait que PHP soit bien documenté et que plein de gens en parlent dans leurs blogs et dans les forums, c'est pas un hasard.

          s/php/windows/ comme d'autres l'ont déjà fait.

          s/php/MSOffice/
          s/php/n_importe_quel_produit_pourri_mais_populaire/
        • [^] # Re: J'aime bien PHP

          Posté par (page perso) . Évalué à 8.

          Je pense que si PHP était bien documenté, t'aurais pas des questions partout, ou des bouts de code intitulés "pour faire ce que tu voulais faire mais qui pour une raison étrange ne marche pas, fais comme moi", y compris sur php.net. Ce site contient aussi des commentaires dans la doc du genre "tiens, j'ai remarqué qu'avec un switch, je pouvais simuler un if".

          Je ne crois vraiment pas que PHP soit convenablement documenté −d'une manière officielle, par les gens qui l'ont conçu− et je crois aussi (bien que je ne passe pas mon temps dessus) que les blogs qui parlent de PHP ne volent pas haut, mais j'ai tendence directement à ne pas les lire.

          Le gars qui trouve une astuce pour afficher un tableau proprement, j'appelle ça un jean-kevin, ou un lycéen. C'est un truc par un gars qui sait pas coder pour aider les autres qui ne savent pas coder, mais qui seront heureux de faire pareil. Tant mieux s'il est content de lui. Mais il aurait jamais du en arriver là tant c'est bâteau.

          PHP est *le* langage qui permet à des gens sans compétence de gagner leur vie. Quand tu sais pas coder, tu fais pas du perl, du python ou je ne sais quoi. En revanche, t'as fait ton site en PHP, et ptet même celui de ton oncle accordéoniste.

          Je ne nie pas que des pros fassent effectivement du PHP, et qu'ils en fassent bien, je nie juste le fait que la majorité des gens qui font du PHP soient compétents. On ne compte pas le nombre de métiers du web où le code à été fait par ceux dont ce n'est pas le métier, ni la formation (graphistes, illustrateurs, etc). Et dire que le graphiste peut être un passionné doué n'y changera rien : t'as assez de gens qui font des études d'info sans y arriver pour qu'on se dise qu'il y a des gens qui n'ont aucune connaissance qui n'y arrivent pas mieux. Et ces gens font du PHP car justement, c'est répandu…

          Quant à moi, je ne fais pas de web, ça résout le problème de la partialité pour RoR, python ou autre.
  • # Critiques de PHP

    Posté par . Évalué à 10.

    J'aime beaucoup les critiques hyper constructives de PHP.

    Moi perso, j'aime bien PHP aussi et je ne pense pas que les gens qui l'utilisent soient tous masochistes ou incompétents.
    PHP est ce qui fait que le libre à une grosse visibilité sur Internet.
    Alors oui PHP est très permissif comme langage, mais rien ne vous empêche d'être propre dans votre code.

    Après c'est une question de point de vue, les développeurs python on horreur de PHP, c'est leur choix.

    Il faut aussi à des moments se poser les vrais questions.
    Pourquoi PHP, aussi imparfait soit-il est si utilisé, alors que je n'ai toujours pas vu de pub à la télé pour PHP?
    Ben il est efficace sur plusieurs point:
    - facile d'apprentissage, sa trop grande permissivité aux erreurs n'est pas forcément un handicape pour les programmeurs débutants;
    - facile de déploiement, la majorité des applications qui utilisent ne nécessitent pas de reconfiguration du serveur;
    - adapter à internet;
    - très bien intégré à Apache;
    - facile de maintenance, on redémarre pas un site parce qu'on a changé un fichier;

    Je pense qu'il faut de temps en temps arrêter la branlette cérébrale.

    Si vous voulez faire du code PHP propre vous pouvez.
    Vous pouvez poussez le vice jusqu'à typer les paramètres de vos méthodes, demander l'affichage des notices pour être sure que toutes vos variables ont bien étés initialisées.

    Donc PHP, n'est pas et ne sera jamais le langage ultime.
    Pour certain, il a été conçu pour être un mauvais langage mais personne n'est obligé de l'utiliser.

    Maintenant, les types qui expliquent que si python ou java sont peu utilisés c'est parce que leur super langage a peu d'hébergeurs.
    Je leur donne une astuce pour devenir riche :
    OVH loue des serveurs dédiés http://www.kimsufi.com/ , à partir de 20 euros HT par mois.
    Ils n'ont qu'a en louer 1, ce mettre en auto-entrepreneur pour faire de l'hébergement mutualisé dessus et devenir riche au lieu de pleurnicher.
    Je sais pas, mais si je pensais que les gens n'utilisent pas un truc qu'ils veulent pourtant utiliser, un langage parfait, le rêve des développeurs, juste pour une raison si bête, c'est ce que je ferai et en plus ça me rendrait sûrement riche.
  • # langage pour et langage de

    Posté par . Évalué à 10.

    PHP langage pour mauvais programmeurs ? C'est plutôt le contraire ! Python est un langage pour mauvais programmeur. Un vrai. Python est un langage qui arrive à faire faire des pizzas à un spécialiste des spaghettis. PHP c'est l'inverse.

    La vérité est que si PHP n'est généralement pas aimé des devs c'est qu'il n'est pas bandant. Perl est amusant ; les LISP sont géniaux et excitants ; Python inspire le respect ; Ruby étonne... PHP, lui, ne fait rien, c'est un bidule sans âme.

    PHP partage avec Perl une origine qui ne préfigurait rien de son avenir et une histoire faite d'ajouts successifs aussi inattendus qu'inégaux. Mais il y a une différence de taille. Perl fut pensé par un bordélique pour être bordélique, d'un bordel bien fun. PHP devin bordélique par accident, ou plutôt par inconscience.

    Et ça se sent ! Le bordel de Perl c'est le bordel mi-chic mi-kitsch qui fait de l'oeil aux dandys. Le bordel de PHP c'est juste le bordel d'une chambre d'informaticien boutonneux qui a oublié d'apprendre à passer l'aspirateur et le plumeau.

    Python méprise PHP, il est bien trop sale pour Monsieur Propre ; Perl se rit de PHP, un langage plus jeune que lui qui a fait les même conneries que lui sans prendre son génie ; LISP ne sait pas que PHP existe, il a bien trop à faire avec ses frères, ses cousins, ses petits-fils, ainsi qu'avec tous ces opportunistes qui viennent lui piquer telle et telle idée après s'être moqués de ses jolies parenthèses ; C radote dans son coin et continue de répéter pendant trois heures ce que LISP a déjà dit il y a 10 ans en deux minutes, autant que PHP lui passe à côté de ses pompes ; Ruby rigole avec PHP, il rigole avec tout le monde, Ruby est so coooool ; Java a trop de papiers à remplir ; et .NET se dit que s'il pouvait foutre PHP dans son bazar ça ameuterait une sacré bande de gaillards, ah ? c'est déjà fait ? Ne parlons pas d'Objective-C qui a d'autres tigres à fouetter.

    Miaou !
  • # Dépréciations

    Posté par (page perso) . Évalué à 2.

    A noter des dépréciations qui montrent que le langage se prépare pour le futur (et PHP6) : http://www.php.net/manual/en/migration53.deprecated.php (attention la version française n'est pas à jour).

    Tout ce qui est safe_mode et magic_quotes sont dépréciés. mysql_escape_string, ereg* et split aussi. Et un truc déjà déprécié depuis longtemps jette des erreurs maintenant : $string{5}, à remplacer par $string[5] (renvoie le 6ème caractère de $string, oui on compte à partir de zéro).

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

Suivre le flux des commentaires

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