Discussion :

[ABCIWEB]

@Aizen64 c'est vrai que dans ton dernier message tu as fait dans le grandiose, pourquoi donner autant de bâtons pour te faire battre ?

Je ne reparle pas de tes dernières connaissances en php qui décrivent à peu près php4 (11 ans déjà...) et auxquelles on a déjà répondu.

Mais en plus tu parles avec le "même sérieux" du monde du libre pour tenter de tout mettre dans le même sac. M'étonnes pas que Nightfall ait été estomaqué, moi pareil, faut oser quand même !

C'est quoi ton problème ? T'es un bébé clone microsoft élevé en milieu stérile sans porte ni fenêtres ? Faut aérer un peu, regarder le monde à l'extérieur et voir comme ça bouge ! Jamais entendu parler par exemple que bon nombre d'administrations européennes y compris françaises migraient vers openOffice ou libreOffice ? T'as pas dû chercher bien loin avant de répondre... si tu cherchais un peu plus je suis certain que tu pourrais même trouver d'autre exemples de logiciels libres qui ont un aspect fini comme tu dis.

Je n'ai pas mis -1 sur ta réponse puisque tu écris dans ta signature qu'il vaut mieux argumenter. Après il y a aussi la pertinence des arguments qui rentrent en jeu et avec ceux que tu donnes on dirait quand même bien que tu cherches une belle récolte

Sinon "Le typage fort permet de forcer d'avoir une structure surtout" c'est plus une rengaine qu'un argument, non ? Toujours est-il qu'avec tout ce code bordélique non structuré, et à t'entendre sans doute conçu par des amateurs, certains autres amateurs ont réussis à faire des petits sites comme facebook ou wikipedia... pas finis ? Pourquoi à ton avis ont-ils choisis php ? Par méconnaissance de son faible typage ou parce qu'ils ont pensés que ce n'était pas rédhibitoire ? J'irai pas jusqu'à dire que dans le contexte du web cela peut avoir plus d'avantages que d'inconvénients parce que je voudrais pas que tous les rigoristes tombent d'une crise cardiaque comme des mouches

Enfin pour satisfaire le plus grand nombre PHP7 a encore fait une avancée dans cette direction. Pas assez, pas assez vite, dépend des priorités/besoins de chacun. Mais bon le slogan php c'est caca parce que faible typage, on dirait une armée de boot spammeurs et puis ça aussi ça commence à devenir obsolète.

[Aizen64]

OK, je vais faire en sorte de poser des arguments.

Pour l'accès aux données et mon argument précédent sur PDO, erreur de ma part, c'est une classe bien pratique.

Pour le côté amateur du language. Non, il n'a pas été créé par un amateur, je trouve juste que l'organisation des fonctions qui ne sont pas rassemblées dans des classes rend les choses plus difficiles à retrouver.

Mon opinion sur l'open source, tout dépend de quoi on parle. Pour avoir utilisé OpenOffice, j'ai eu quelques bugs bien étranges avec Calc et de nombreux plantages. OpenOffice Basic ? Utilisable ? oui. Pas de débugger, des fonctions type getCellRangeByPosition... c'est lourd. Soit dit en passant, ça pose toujours problème à des organisations comme des administrations publiques pour réécrite des grosses macros.

Pour revenir sur les outils MS, VS et l'intellisense est bien pratique et permet de développer dans de nombreux langages. Pourquoi j'apprécie un language comme C# ? Si je met à part le framework, c'est bien l'outil, VS qui fait la différence. C'est un mastodonte de 9Go mais qui est très puissant.

Revenons à PHP, effectivement il y a des améliorations concernant le typage pour les paramètres de retour de fonctions documenté ici.

Si effectivement les signatures de fonctions peuvent être : mafonction(int entier, float virgule), en est-il de même pour la déclaration de variables ailleurs dans le code ? Si c'est le cas, ce serai bien pratique.

Je l'ai dit et redit, ce qui me pose problème dans le langage c'est de faire du débug, au moins un compilateur hurle à la mort si tu ne lui fourni pas le type attendu avant l’exécution.

[Tsilefy]

Pour le côté amateur du language. Non, il n'a pas été créé par un amateur, je trouve juste que l'organisation des fonctions qui ne sont pas rassemblées dans des classes rend les choses plus difficiles à retrouver.

C'est une opinion, donc purement subjective. On peut dire la même chose de C, de C++, de Javascript et de quantités d'autres langages.

Si effectivement les signatures de fonctions peuvent être : mafonction(int entier, float virgule), en est-il de même pour la déclaration de variables ailleurs dans le code ? Si c'est le cas, ce serai bien pratique.

Pas sûr. Ça a des avantages et des inconvénients. En PHP, tu manipules essentiellement (uniquement?) du string: requêtes et réponses HTTP, requête et réponse de base de données, lecture et écriture de fichiers... Avec un typage strict, il faudrait caster en permanence les données. C'est pratique dans les signatures parce que ça permet d'imposer des contraintes et donc d'avoir un code plus sûr, mais ailleurs je suis partagé.

Mais rien ne t'empêche quand même d'opter pour un typage strict si tu veux. La beauté des langages c'est que tout n'est pas obligé d'être dans le core. Tu peux installer une extension pour en profiter: https://github.com/nikic/scalar_objects. Installer une extension est très simple, et tu peux faire confiance en celui-là, il est écrit par l'un des principaux contributeurs de PHP.

Je l'ai dit et redit, ce qui me pose problème dans le langage c'est de faire du débug, au moins un compilateur hurle à la mort si tu ne lui fourni pas le type attendu avant l’exécution.

Un seul mot: PhpStorm et Xdebug (je sais ça fait 3 mots). PhpStorm fait même une analyse statique de ton code et hurle quand tu ne passes pas le type attendu. Pas besoin de compilation :-)

[Aizen64]

Oui, c'est une opinion, pour information, mes messages ne sont rien de plus, je ne suis pas là pour faire de prosélytisme.

Le typage, je comprends ton argument bien que je préfère le typage fort pour la raison que j'ai indiqué. Merci pour le lien. Ça ne répond pas à ma question concernant le typage fort des variables et PHP 7. Pour les autres langages cités, C/C++, j'ai pas le niveau pour m'y intéresser et JS est très loin d'être selon moi un langage bien conçu, c'est juste qu'on a rien inventé d'autre pour bosser sur la machine cliente.

XDebug, pas réussi à l'installer sous Linux, pas évident pour l'installation à mon humble avis, l'IDE a également besoin de config pour le prendre en charge non ?

PHPStorm ? Le hic est le prix. Surtout que c'est pour un usage pro et que je devrai le payer de ma poche. J'envisagerai l'option à l'avenir.

Merci pour ta réponse.

[Tsilefy]

Tous les IDE prennent xdebug en charge. Pour l'installation j'utilise PuPHPet qui installe pour moi tout ce dont j'ai besoin pour mes environnement de dev dans une machine virtuelle sous Vagrant.

Je peux comprendre le prix, sauf que tu prends en exemple Visual Studio, qui n'est pas gratuit. Encore que pour un usage pro, le prix n'est pas excessif, et tu peux te le faire payer par ta boîte si t'es en entreprise.

Sinon, tu peux choisir la version EAP, c'est ce que j'ai fait pendant plusieurs mois pour tester. C'est une preview de la future version de PHPStorm, censée être instable mais en plusieurs mois je n'ai jamais eu de problème de stabilité. C'est une version complète et gratuite avec une licence de 30 jours mais il y a des nouvelles versions au moins une fois par mois, et chaque mise à jour réinitialise la licence, donc en réalité c'est une licence perpétuelle.

Sinon, Netbeans est très bien aussi. Un peu moins "fini" que PHPStorm, mais pendant des années je m'en suis servi sans problème.

[ABCIWEB]

Mon opinion sur l'open source, tout dépend de quoi on parle. Pour avoir utilisé OpenOffice, j'ai eu quelques bugs bien étranges avec Calc et de nombreux plantages. OpenOffice Basic ? Utilisable ? oui. Pas de débugger, des fonctions type getCellRangeByPosition... c'est lourd. Soit dit en passant, ça pose toujours problème à des organisations comme des administrations publiques pour réécrite des grosses macros.

Oui c'est mieux de faire des nuances Perso j'utilise OpenOffice mais de façon très ponctuelle, je ne peux donc rien en dire en milieu professionnel. J'observe simplement que la plupart des administrations européennes s'y mettent, ils ont donc dû faire un audit qui apparemment a donné de bons résultats...

[Jarodd]

C'est dingue comme certains n'actualisent pas leurs préjugés.

[Aizen64]

Dois-je me sentir visé ?

On s'y fait au langage avec le temps. Que mes arguments ne plaisent pas aux aficionados de l'open source est une chose, on ne peux non plus, du moins je pense, nier une part de vérité dans mes arguments.

Pour les préjugés, je n'étais pas fan du tout de Linux au premier abord et aujourd'hui, si on me demande si un particulier lambda veut installer Linux sur sa machine, je lui dirai d'y réfléchir à deux fois. Par contre, j'admets volontiers que le terminal est un outil puissant et sous certains aspects plus pratique qu'une interface graphique. La gestion des services m'est nettement plus aisée sous Linux que sous Windows, sudo service monservice restart est bien plus pratique que de faire l'équivalent en interface graphique sous Windows, tail est bien utile et Git est de loin la référence actuelle pour gérer des dépôts logiciels.

Si après, tu trouves que je fais preuve d'étroitesse d'esprit, je trouverais ça discutable.

[Tsilefy]

Pour moi c'est simple: je ne me vois pas utiliser Linux sur mon PC, et je ne me vois pas utiliser Windows sur mon serveur :-)

[Olivier Famien]

La date de sortie de la version stable de PHP 7 pourrait être repoussée
pour améliorer la qualité du code, qu’en pensez-vous ?

Le 29 octobre dernier, PHP 7 RC 6 a été publié. Cette nouvelle version constitue la 11^e du genre parmi la série des préversions publiées jusqu’alors. Dans cette préversion, 10 nouveaux bogues ont été corrigés.

Au menu des erreurs corrigées, l’on notait, entres autres, qu’une exception déclenchée lors d’une comparaison identique engendrait une boucle infinie. Le gestionnaire d’exceptions ne fonctionnait pas comme prévu. Un débordement de la mémoire de la pile a été détecté dans le parser du langage Zend. Le client SOAP générait Segfault. Un défaut de segmentation a été observé dans le client SOAP. Une sérialisation incorrecte de l’objet ArrayObject pointait du nez si la fonction unset était appelée dans la fonction serialize().

Tous ces éléments et bien d’autres encore ayant été corrigés dans cette 6e Release Candidate de PHP7, la prochaine étape selon le planning devrait être la sortie de la version finale le 12 novembre.

Toutefois, Anatol Belski, développeur du noyau de PHP et gestionnaire de la publication de PHP 7.0, a annoncé depuis peu « qu’après les dernières évaluations dans le cercle des gestions de versions précédant l’orientation vers les préparations pour la version 7.0 RTM, nous sommes parvenus à la conclusion que l’état actuel ne parait pas raisonnable pour être utilisé comme la version finale ».

« Les versions Release Candidate avant la version RC6 apparaissaient acceptables, ce qui nous a donné des motifs pour annoncer la date de la version RTM programmée pour le 12 novembre comme finale. À partir de la perspective d’aujourd’hui, la plupart des problèmes découverts et corrigés depuis la version RC6 sont encore mineurs en raison de leurs caractéristiques – 7 crashes (le bogue #70805 plutôt critique) et 3 régressions de fonctionnalité. Toutefois, étant donné la quantité et la combinaison de tous ceux-ci, l’état est à notre avis impropre pour le démarrage du cycle de vie de la prochaine version majeure ».

« Ainsi, la reprise du cycle des préversions semble de notre point de vue la chose appropriée à faire pour l’instant. D’où cette adresse pour informer la communauté sur l’intention et recueillir les avis. PHP 7 est toujours dans la dernière ligne droite et est très proche de l’achèvement. La prochaine version RC sera peut-être bien la dernière. Bien que nous préférions nous assurer d’abord de la qualité autant de fois que possible au lieu de fournir un mauvais service aux consommateurs ».

À la lumière de cette annonce, il ne serait pas incongru de conclure que la date du 12 novembre pour la sortie de la version RTM de PHP 7 sera repoussée afin que le produit une fois sorti ne souffre aucunement de défaut de qualité.

Certaines personnes trouvent cela raisonnable de repousser cette date si la qualité actuelle n’est pas optimale pour l’instant. Et d’ajouter que ce serait nul de publier une chose qui une fois sortie serait remplie de bogues.

D’autres par contre ne trouvent aucune objection à ce que la date initiale soit respectée en dépit de la qualité du produit qui pourrait être reprochable. Des corrections d’erreurs pourraient suivre à mesure que les découvertes de bogues seront faites, soutiennent ces derniers.

Source : PHP News

Et vous ?

Que pensez-vous de cette annonce ?

Que pensez-vous de ce report probable ?

Voir aussi

Forum langage PHP

[ABCIWEB]

Salut,

Je suis de l'avis du premier groupe qui préfère retarder la sortie. Pourquoi sortir une version alors que des bugs récents ont été découverts ? Même corrigés mieux vaut prendre le temps de vérifier qu'ils n'ont pas d'autres impacts, et que les corrections proposées soient testées dans toutes les combinaisons possibles.

En plus les dernières versions de php depuis 5.3 ont notablement amélioré les performances, ce qui à mon avis permet d'attendre encore quelques semaines dans de bonnes conditions sans trop d'impatience.

Et puis php commence à perdre son aspect amateur, qui en fait n'était pas dû au langage lui-même mais à la grande diversité de niveau des utilisateurs puisqu'étant le langage le plus accessible c'est aussi celui qui attire le plus de débutants.

L'équipe php a augmenté les contrôles minimum pour récupérer des variables, fourni un bon cadre pour le développement objet, des nouvelles classes bien pratiques, des gains en performances pour les dernières versions etc. sans oublier les nombreux framework construits autour qui se sont eux aussi améliorés. De quoi satisfaire le plus grand nombre.

Pourquoi prendre le risque de contrarier cette montée globale qualitative en sortant une version buggée qui cette fois-ci ramènerait le problème non plus à la maladresse de certains débutants mais au moteur du langage lui-même. Ce serait une bien mauvaise publicité
Tout ça pour respecter une date ? Nan franchement, sauf à donner le bâton pour se faire battre, quel intérêt ?

[RyzenOC]

J'ai tester la dernière RC est je n'ai pas découvert bugs.

Mais je préfere avoir un produit en retard mais de qualité, je suis plutôt pour un report.

[Zefling]

Je suis impatient de voir cette version sortir, mais je préférais que ça soit une vrai stable. Et on n'est plus à quelques jours/semaines près, depuis l'échec de la 6, on a appris à être patient.

[Grimly]

Il vaut mieux attendre un bon produit qu'un ramassis de bugs.

A la vue des bugs je pense que c'est justifié. Même si des fonctions avancées de zend sont utilisés, je n'aimerais pas tomber sur un segfault alors que mon application n'a pas changé.

Pour les impatients, il y a toujours les RC.

[Pierre Louis Chevalier]

A ce propos c'est très impressionant le score PHP sur : Quel est votre langage serveur préféré pour le Web en 2015 ?

Ca fait un moment que pierre paul jacques essaient de lancer le nouveau langage révolutionnaire pour le web et au final c'est les bons vieux PHP et Javascript qui restent au top

[koyosama]

GTA IV ou Assassin's Creed hum ?!?

Mouais, la patience est une qualite comme on dit ^^.

[air-dex]

PHP 7 doit être la version de PHP qui le consacrera. Qu'ils reportent sa sortie s'ils le jugent nécessaire afin de ne pas transformer cette consécration en braconnage d'éléPHPants.

[CoderInTheDark]

Je penche un peu vers le deuxième groupe, je me sens un peu seul.
Je vais me faire lyncher.

Mais voila, il faudra bien se lancer un jour.
De toute façon des bugs, on trouvera toujours

Même si on me dit que il s'agit d'une version stable.
Je pense pas l'utiliser en production avant un moment.Je penche un peu vers le deuxième groupe, je me sens un peu seul.
Je vais me faire lyncher.

Mais voilà, il faudra bien se lancer un jour.
De toute façon des bugs, on en trouvera toujours.
Mais ceux énoncés, sont quand même graves.
Repousser cette fois d’accord.
Mais depuis le temps qu’on l’attend, il faudrait qu’elle arrive avant la fin de l’année.In ne faudrait pas nous refaire le coup encore une fois.

De toute façon, je ne pense pas l'utiliser en production avant un moment.

[SurferIX]

Je n'ai jamais compris que l'on ne maintienne pas un code, même vieux de plus de 12 ans.
Dois-je comprendre que le propriétaire de ce code, ne sait pas comment le faire évoluer car il n'a pas la connaissance ?
Ou bien, tant que l'hébergeur offre encore une version php4, il n'est pas nécessaire de faire cette migration ?
A moins que tout cela ne soit qu'une question de budget.

Ouf. Merci pour ta dernière ligne, j'ai cru à un moment donné que tu n'avais jamais travaillé en entreprise !

Il arrivera un moment où la migration coûtera plus cher que la refonte de l'application.
Donc toujours remettre au lendemain ce que l'on peut faire aujourd'hui est une très mauvaise stratégie, surtout en terme de coût.

Ah eh bien au vu de cette remarque : tu as travaillé en entreprise, mais pas encore assez longtemps !
Aujourd'hui c'est du consommable qu'on vend, le code y compris, et Php permet (malheureusement) de faire cela : du code rapide, difficile à maintenir, mais jetable.
Donc il arrive toujours un moment où la ré-écriture coûte moins cher que la maintenance, mais ce moment n'est jamais "clair" et c'est toujours dur de convaincre un patron, voire pire : une équipe d'anciens qui ne veut pas changer.

---------------------------------------------------------------------
Dans tous les cas : maintenir du code, le faire évoluer pour proposer au clients exactement les mêmes choses, c'est juste impensable en termes de budget, car il n'y a rien de nouveau à vendre.
Donc du code qui n'évolue pas, c'est compréhensible, point à la ligne.
Après, mon application de plus de 32000 lignes de codes est passée de Php 4 à Php 5 sans aucune modification. Absolument aucune . Je croyais même que je m'étais trompé et que j'étais pas sous Php5. Donc là aussi ce n'est pas qu'une question de Php, c'est aussi une question de développeurs : pour un salaire de débutant on a du code de débutant, c'est clair.

Mais arrêtez de critiquer les développeurs qui ne font pas évoluer leur code. Du point de vue de l'entreprise, c'est compréhensible, et normal, end of story.

Depuis que je code uniquement en Python et que j'ai abandonné le C, je vois la vie en rose

Je dis pareil mais avec Php : depuis que je code uniquement en Python je vois la vie en rose

@Artemus et @Tsilefy : pfffouuu... que répondre. Y aurait pas un dév C# par là , je sais plus quoi leur dire....

C# c'est comme C++ : on peut absolument tout faire, et tout faire proprement. C'est génial. Héritage, héritage multiples, promise, typage fort, statiques, privées, publiques, etc etc, bref, la totale du kamasutra et plus.
Seul hic : on peut absolument tout faire, et tout faire proprement... si on a tous la même façon de fonctionner. Je peux te montrer des codes source C++ qui ressemblent presque à deux langages différents ! Bref.

L'autre chose qui me fait sourire c'est Php : tout le monde en a tellement marre du code pourri que Php permet de faire (dernier en date qui m'a fait perdre 2 heures. Pour résumer façon directe, essayez : php -r '$b = 15; $a = "45".$b=15;' aucune erreur, aucun warning, le code fait juste n'importe quoi (enfin c'est logique mais façon Php)) qu'on commence à essayer le typage fort... vraiment n'importe quoi, on est en train d'enlever ce pour quoi Php est né...

Bref, Python est resté sur le duck typing, qui est à la fois du typage fort et faible : une variable est typée lorsqu'elle est initialisée. Ici aussi je vends pas du Python, je parle d'une pratique qui a plus d'une trentaine d'années, et qui tourne très bien, donc autant que les autres s'en inspirent.... allez j'arrête de perdre du temps avec Php, j'en ai déjà perdu assez depuis 12 ans...

[Artemus24]

Salut SurferIX.

Ouf. Merci pour ta dernière ligne, j'ai cru à un moment donné que tu n'avais jamais travaillé en entreprise !

Tu es du genre à croire que tu es le seul à travaillé dans le monde de l'informatique. Et bien non, il n'y a pas que le web !
Je te confirme que j'ai fait toute ma carrière dans les SSII, dans le milieu bancaire. Donc je sais de quoi je parle.
Sauf que j'ai fait du gros système BULL et IBM et non du web.

Croyez-vous que tout est une question de budget ? Non !
Le fond du problème concerne aussi la compétence pour venir mettre son nez dans un vieux machin dont plus personne ne comprend rien.

Aujourd'hui c'est du consommable qu'on vend, le code y compris, et Php permet (malheureusement) de faire cela : du code rapide, difficile à maintenir, mais jetable.

Je comprends surtout que c'est votre façon de travailler dans le monde du web.
Aucune méthodologie, que du bidouillage et après vous vous étonnez le manque de rigueur dans vos développements.
Tout ce que vous savez faire, c'est du copier/coller.

Vous avez des clients qui vous demandes un travail, et vous êtes en mesure d'accepter ou de refuser leur proposition.
Vous faites que du neuf, et jamais de la maintenance car cela ne vous intéresse pas.

Dans le monde bancaire, on fait à plus de 80% de la maintenance et parfois dans des langages que l'on doit apprendre sur le tas.
Et je ne parle même pas des contraintes imposés par le client (la banque) pour développer, faire les tests, la mise en production et le versionnage.

Donc il arrive toujours un moment où la ré-écriture coûte moins cher que la maintenance, mais ce moment n'est jamais "clair" et c'est toujours dur de convaincre un patron, voire pire : une équipe d'anciens qui ne veut pas changer.

C'est faux ce que vous dites ! En réécrivant une application, vous risquez d'introduire de nouveaux bugs alors que la vieille application à déjà été testé maintes fois.
Vous ne tenez pas compte du temps nécessaire pour refaire une batterie de tests avant de la mettre en production. C'est cela qui coute cher !
Le but d'une maintenance est de corriger les bugs que l'on rencontre. Donc en terme de bugs, un existant est bien plus efficace qu'une refonte totale d'une application.

La nécessité de tout réécrire vient quand la question de la performance est soulevée, ou encore quand on change de système d'exploitation ou quand elle ne correspond plus à ce que l'on attend d'elle.
J'ai en tête la migration de Bull vers IBM, en gros système, car en changeant de base de données (IDS II vers DB2), la performance était désastreuse.
Et pourtant, le langage commun entre ces deux système d'exploitation (BULL et IBM ) est bien le cobol.
Sauf que il y a de grosses différences dans la façon de représenter les données et de les gérer.
Passez d'une base de type réseau à une base de type relationnel modifie grandement la façon d'accéder aux données et par voie de conséquence les temps d'accès.

Oui, mais voilà, vous ne connaissez pas ce genre de problème car vous travaillez toujours avec les mêmes langages, dans le même environnement.
Et comme vous dites, vous n'avez aucune contrainte car vous faites du jetable.
C'est plutôt à moi d'émettre des doutes sur votre compétence professionnel.

@+