Articles précédents : Articles
- [6] Quand les PGI libres entrent à l'université
- [7] Campagne de soutien aux formats ouverts en Europe
- [96] Apple rachète CUPS
- [6] Le groupe de travail sur l'interopérabilité répond à l'appel à commentaires sur le RGAA
- [5] PhpMyObject 0.06 vient de sortir
- [76] Enquêtes publiques probatoires de l'AFNOR concernant OOXML et ODF
- [17] Pôle de Compétitivité Ouverture : reconnaissance de l’importance du logiciel libre
- [4] Sortie du framework PRADO en version 3.1
- [20] Une émission grand public sur les logiciels libres
- [10] Syllable Server, du Linux dans Syllable
Liens connexes
- Le site de PHP et l'annonce (432 hits)
- Là où tout a commencé... (350 hits)
- L'initiative GoPHP5 et son compte à rebours (600 hits)
- Guide de migration de PHP4 à PHP5 (805 hits)
- Guide de migration de PHP5 à PHP5.1 (313 hits)
- Guide de migration de PHP5.1 à PHP5.2 (344 hits)
Dépêche modérée par
Dépêche éditée par
Il n'y aura donc pas de PHP 4.5, mais le PHP Group continuera à effectuer des mises à jours de sécurité jusqu'au 8 août 2008 si toutefois des failles majeures étaient trouvées d'ici là.
Espérons que cet arrêt du support de PHP 4 encouragera les hébergeurs qui ne l'on pas encore fait à migrer, mais aussi et surtout les développeur d'applications libres écrites dans cette version de PHP à mettre à jour leur code !
Certains diront que la migration d'applications PHP 4 vers PHP 5 ne nécessite pas un gros travail pour le peu que l'on aie codé proprement. Le PHP Group a d'ailleurs mis à disposition des développeurs des guides de migration de PHP 4 à 5, de PHP 5 à 5.1, et de PHP 5.1 à PHP 5.2 (oufff).
Cette annonce coïncide à peu de jours prêt avec la mise en ligne du site GoPHP5, un regroupement de plusieurs grand projets open source PHP visant à pousser les hébergeurs à adopter PHP5 par défaut (sans avoir à passer par diverses manipulation comme l'utilisation de fichiers .htaccess).
Bref, pour les retardataires il reste tout juste un peu plus de 200 jours pour (dé)bogger vos vieux scripts...
![[en]](../../../images/en.png)
Le site de PHP et l'annonce (432 hits)-
Là où tout a commencé... (350 hits)
-
L'initiative GoPHP5 et son compte à rebours (600 hits)
![[fr]](../../../images/fr.png)
Guide de migration de PHP4 à PHP5 (805 hits)-
Guide de migration de PHP5 à PHP5.1 (313 hits)
-
Guide de migration de PHP5.1 à PHP5.2 (344 hits)
> Lire les commentaires (108 commentaires, moyenne: 2,1).
Incompatibilités ?
Je suis étonné des incompatibilités au sein du langage. Je veux dire, est-on obligé d'en arriver là ? Pourquoi ne pas avoir renommé l'extension, si le code diffère entre les versions (je parle de compatibilité ascendante : si on ajoute des possibilités, c'est normal et sein, pas besoin de renommer)
ça fait pas un peu "branleur" de devoir changer les scripts d'un même langage pour suivre les évolutions ?
n'est-ce pas mauvais pour l'image de PHP ? Des décideurs pressés ne vont-ils pas trouver ça bizarre ? Cela ne va-t'il pas à l'encontre de "if it's not broken, don't fix it ?"
IMHO, c'est mauvais pour l'histoire de PHP, ce changement.
Ce message n'est pas un troll : je me demande juste si MARKETING-MENT parlant, ils ont pensé que le marché allait en pâtir...
Je n'arrive pas à trouver de graphs sur l'utilisation du C# Vs PHP... mais je pense que Microsoft saisira l'opportunité pour critiquer les langages "libres".
-
[^]Re: Incompatibilités ?
Posté par Laurent J (page perso, ) le 19/07/2007 à 11:23. (lien). Évalué à 6.>Je suis étonné des incompatibilités au sein du langage.
En même temps, elles sont minimes... Et puis c'est pas plus mal de gommer les erreurs de jeunesses non ?
>Pourquoi ne pas avoir renommé l'extension
Ouai, et quand on aura PHP 11.0, il faudra se taper des .php11 ? n'importe quoi.
>ça fait pas un peu "branleur" de devoir changer les scripts d'un même langage pour suivre les évolutions ?
"branleur" ? Donc pour toi, une application, ça ne se maintient pas ? Et ceux qui les maintiennent et qui les font migrer vers d'autres versions du langage ce sont des branleurs ??
>Ce message n'est pas un troll
si si. Y a bien des incompatibilités entre les différentes versions de Java, c'est pas pour ça qu'il est resté dans un placard ou qu'il a mourru hein !
Et puis ce ne sont pas des régressions en passant de PHP4 et PHP5, mais des fortes améliorations. Le modèle objet de PHP3 est totalement pourri, Le modèle objet de PHP4 est limite, et le modèle objet de PHP5 commence vraiment à être bien. Faudra que tu m'expliques, comment, en passant de pourri à vraiment bien, c'est marketing-ment pourri.
>IMHO, c'est mauvais pour l'histoire de PHP, ce changement.
Moi je dis que c'est plutôt une bonne chose, puisque les nouveautés de PHP5 ont permis l'essor de frameworks et autres applis plus robuste et mieux codées.
> mais je pense que Microsoft saisira l'opportunité pour critiquer les langages "libres".
Si ça c'est pas du troll
Franchement ton analyse vaut même pas deux balles.-
[^]Re: Incompatibilités ?
Posté par Stéphane TRAUMAT (page perso, ) le 19/07/2007 à 11:42. (lien). Évalué à 3.Pour java, ayant vécu la plupart des versions Java, on ne m'a jamais demandé d'une version à l'autre de modifier mon code.. des deprecated apparaissent mais ça tourne toujours.
Mais bon, je peux me tromper :)-
[^]Re: Incompatibilités ?
Posté par Laurent J (page perso, ) le 19/07/2007 à 11:51. (lien). Évalué à 5.>des deprecated apparaissent mais ça tourne toujours.
ouai enfin, si c'est deprecated, il faut s'attendre à ce que cela n'existe plus à partir d'une certaine version (enfin en toute logique, je ne suis pas expert java non plus). Donc il faut bien que tu le retouches ton code un jour ou l'autre. En tout cas, j'aime pas laisser des trucs "deprecated" dans mon code, ça fait un peu sale...-
[^]Re: Incompatibilités ?
Posté par fatypunk (Jabber id, ) le 19/07/2007 à 11:59. (lien). Évalué à 5.Les dev java élèvent la compatibilité ascendante au rang de dogme, si des méthode sont déprecated, c'est à titre d'information, dans du nouveau code tu ne devrait pas les utiliser car il y a aujourd'hui une meilleure façon de faire, mais ces méthode ne sont jamais retirée (enfin je ne suis pas sur à 100% que ça n'ai jamais été fait mais je ne suis jamais tombé dessus...).
Ceci non pas dans le but de te permettre de coder avec d'ancienne méthodes, mais de pouvoir utiliser d'ancien programme sans devoir les recoder... Ensuite si le programme est maintenu tu peux le mettre à jour simplement en ramassant la liste des "deprecated warning" du compilo mais sans jamais provoquer une rupture de validité du code.-
[^]Re: Incompatibilités ?
Posté par Julien Portalier (page perso, ) le 19/07/2007 à 12:40. (lien). Évalué à 2.Ah. Donc JRE va continuer à grossir à chaque version ?
-
[^]Re: Incompatibilités ?
Posté par Stéphane TRAUMAT (page perso, ) le 19/07/2007 à 12:46. (lien). Évalué à 3.Oui ... parce que ça te fait peur de télécharger 30 MO sur internet aujourd'hui ? ou que 30 MO de disque dur, ça coute super cher ?
Honnêtement, je pense que ça vaut rien du tout par rapport à une solution pour les problèmes de compatibilité.-
[^]Re: Incompatibilités ?
Posté par baud123 (Jabber id, page perso, ) le 19/07/2007 à 15:04. (lien). Évalué à 4.Pour le faire tourner sur un PDA, oui c'est gênant 30 Mo quand il y a 64 Mo pour faire tourner le système + les applis + le stockage (heureusement ça monte plutôt à 128 Mo maintenant voire cela peut-être mis sur une SDCard de 1 Go).
-
[^]Re: Incompatibilités ?
Posté par windu.2b (Jabber id, page perso, ) le 19/07/2007 à 15:30. (lien). Évalué à 4.Java en embarqué ne fait pas 30Mo. Il existe des version bien plus petites[1]:
JamVM est quant à elle une extraordinaire petite machine virtuelle Java dont la taille d'exécutable frise le ridicule (110ko sur une plateforme Intel).
Bon, les 110ko ne tiennent compte que de la JVM, mais vu qu'il existe J2ME pour l'embarqué, on peut penser que là aussi il y a un gain de place par rapport au J2SE, non?
[1] http://artisan.karma-lab.net/node/61
-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 07:34. (lien). Évalué à 1.Sur PDA, t'utilise generalement la version embarquee J2ME, qui est une version ultra allegee (beaucop moins de classes, moins de methodes par classes, + classes specifiques aux telephone/pda).
J'ai pas connaissance de devices embarquant le JRE.
Et oui, meme jre6 sur un pc actuel, c'est peanuts :)-
[^]Re: Incompatibilités ?
Posté par baud123 (Jabber id, page perso, ) le 20/07/2007 à 11:33. (lien). Évalué à 2.J2ME est-il prévu d'être disponible en libre comme java7 ? (c'est une vraie question : àmha cela peut beaucoup aider pour la modularité et la sélection du strict nécessaire pour les environnements contraints en mémoire comme de l'embarqué).
Sinon, je suppose que ce que tu appelles "PC actuel" ne recouvre pas ceux qui ont encore 256 Mo de RAM (ni même 512) ? C'est tout de même dommage, cela correspond à ce vers quoi tendent les PDA actuellement, avec un processeur encore un peu poussif par rapport aux double/quadruple coeurs "actuels" mais pas forcément par rapport aux processeurs de ce début de siècle, si tu compares http://fr.wikipedia.org/wiki/Pentium_III et http://fr.wikipedia.org/wiki/XScale pour ne citer qu'un constructeur... (je suis ouvert à d'autres comparaisons mais http://fr.wikipedia.org/wiki/N%C3%A9o1973 par exemple évoqué dans la dépêche https://linuxfr.org/2007/07/09/22714.html ne donne pas - actuellement - assez d'éléments de comparaison).-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 12:29. (lien). Évalué à 2.Concernant ta premiere question, je n'en ai absolument aucune idee.
De ce que j'en vois sur les devices qui me sont passe dans les papattes au taff, j'ai l'impression (et je dit bien l'impression) que le runtime pour midlet est fourni par le constructeur du telephone et pas par sun.
Ce qui me fait dire ca, c'est les implem' divergentes des differents jsr (sony m'a particulierement emmerde a ce sujet) suivant les telephones et le fait que les gui sont tres differentes d'un telephone a l'autre.
Donc dans cette hypothese, je pense qu'on peut se brosser pour avoir un runtime libre.
Pour la deuxieme question, non, pc actuel ne recouvre pas un P3 256Mo de ram.
Ca c'etait une machine milieu de gamme en 99 (la mienne :-) ).
L'informatique, ca evolue, tres vite et vouloir supporter du matos qui a presque 10 ans au detriment des fonctionnalites me parait une enorme erreur vu la progression du materiel.
Sinon, on est vendredi, donc je glisserai innocemment que java n'est pas gourmand en proco, mais que c'est un vrai gouffre a ram en revanche :-)
J2ME est relativement lourd sur un telephone tout de meme ('fin le temps de chargement de l'appli est assez long je trouve). Cela dit, apres ca se passe plutot pas mal. On fait tourner un triple des dans nos applis, ca se passe tres bien et c'est instantane.
Apres le truc c'est que tu n'utilise pas une appli sur un telephone comme sur un pc: un telephone ca reste (pour l'instant) monotache a l'utilisation, donc en pratique ca marche plutot pas trop mal.
Et puisqu'on est toujours vendredi: quelqu'un veut bien m'expliquer quel est l'interet d'un site https avec un certificat auto signe? (cf tonlien sur linuxfr)
Passque bon, le concept du certif' c'est de le faire signer par une autorite de confiance, si tu signes toi meme ton certificat, ca sert plus a grand chose...-
[^]Re: Incompatibilités ?
Posté par PLuG () le 20/07/2007 à 12:57. (lien). Évalué à 2.on peut activer le chiffrement (ssl) sans avoir de certificat ?
je pense que la plupart des sites autosignés veulent activer la crypto.-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 13:09. (lien). Évalué à 1.ben meme question, du ssl pour un site de news et de troll, mis a part participer conjointement a gentoo au rechauffement de la planete, je vois pas l'interet :)
-
[^]Re: Incompatibilités ?
Posté par baud123 (Jabber id, page perso, ) le 20/07/2007 à 15:39. (lien). Évalué à 3.préserver mon cookie de relecteur, mon mot de passe aussi ?
-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 16:00. (lien). Évalué à 0.Ton password est envoye a https://linuxfr.org/2007/07/09/22714.html ?
baleze :-)
Quand au cookie de relecteur, je doute que les moyens a deployer soient en rapport avec le gain :)
Et si t'en es rendu a ce niveau de parano, le certif auto signe, bof bof quoi.
'fin bref j'arrete de troller ma curiosite est satisfaite, merci pour ta reponse. :)
-
-
[^]Re: Incompatibilités ?
Posté par Benoît Sibaud (Jabber id, page perso, ) le 20/07/2007 à 18:17. (lien). Évalué à 5.- préserver mon cookie de session (d'administrateur du site dans mon cas)
- préserver les infos personnelles associées au compte (dont les IP de sessions, l'adresse de courriel, etc.)
- garder l'anonymat ou plutôt le pseudonymat, vis-à-vis de son entreprise ou de son FAI ou du lieu public où l'on se trouve
- préserver le mot de passe utilisé pour ouvrir la session
- éviter que le compte soit utilisé pour des activités illégales (diffamation, propos raciste, etc.)
- parce que faire passer toute l'information non confidentielle en clair, c'est indiquer clairement que tout ce qui n'est pas clair est intéressant
- parce que les intermédiaires techniques entre le site et le visiteur n'ont pas besoin d'en savoir plus sur une visite, sur les goûts du visiteur, sur ses préférences, etc.
- parce que le visiteur peut le faire
- parce que le visiteur est parano
- pour ne pas qu'on sache quel choix le visiteur a fait dans des sondages extrêmement sérieux sur DLFP
...
-
-
-
-
[+] [^]Re: Incompatibilités ?
Posté par François B. () le 20/07/2007 à 14:02. (lien). Évalué à -1.S'il vous plait, qu'on arrête de dire que Java est un glouton à mémoire. La semaine dernière, je suis parti en voyage et j'ai ressorti mon vieux portable pour pouvoir assouvir mon besoin de code. J'ai donc téléchargé la dernière version d'Eclipse (Europa). Il y a maintenant une option qui donne en temps réel la quantité de mémoire utilisée... et celle-ci n'a pas dépassé 50Mo. Bien sûr, c'était moins réactif que sur mon amd64, mais mon PIII 650 épaulé de "seulement" 384Mo de RAM était largement utilisable.
A mon avis, Java paye sa facilité d'accès : il est très facile de coder quelque chose qui est lent et qui utilise beaucoup de mémoire.-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 14:37. (lien). Évalué à 3.Java EST un glouton a memoire.
rien que le modele de synchronisation te mange de la ram pour rien.
Ca plus diverses autre choses.
Je suis dev java, j'aime java, java me fait manger le soir, java me paye mes loisirs, java rend mon poil soyeux et mon sexe plus long.
Et pourtant, objectivement, java bouffe de la ram.
Quand a eclipse europa:
http://farm2.static.flickr.com/1003/859185544_dc9fc0ea45_o.p(...)
perso, en 4 ans de dev java intensif, jamais vu eclipse sous la barre des 100mo mini.
Apres, si t'as 3 classes de 20 lignes dans ton projet, aucun plugin, desactive la compile auto etc, je veux bien te croire :)
Cela dit, vu le boulot effectue, j'ai rien a redire la dessus.
Mais pour avoir deja fait de l'eclipse avec 512 de ram... ben tu fais rien tourner a cote.-
[^]Re: Incompatibilités ?
Posté par François B. () le 20/07/2007 à 15:19. (lien). Évalué à 1.Euh... en effet, je n'utilise pas la compilation auto, mais vu la vitesse du compilateur, ça ne sert à rien, et je préfère choisir le moment où mon paquet de modifications est compilé (je fais souvent des Ctrl+S) !
De plus, en réaction à la capture d'écran, mon portable ne tourne pas sous windows !
Enfin, non, je n'ai pas installé tous les plugins à la noix et développés avec les pieds qu'on trouve n'importe où sur le net.
Je réitère, eclipse avec moins de 512Mo de RAM c'est faisable. J'avais 192Mo avant, et c'était vraiment trop juste (eclipse 3.0 et 3.1). J'ai remarqué une accélération dans les dernières versions...-
[^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 15:29. (lien). Évalué à 2.heu le plugin WST, JST, j2me, c'est pas franchement ce que j'appelle des "plugin a la noix".
Si tu connais autre chose pour faire du dev web et debugger une midlet, tu me fait signe.
De plus, en réaction à la capture d'écran, mon portable ne tourne pas sous windows !
Ah ouais? Et alors?
Les objets java prennent moins de bytes sous linux? Marrant, parce que c'est le meme bytecode.
Surtout que vu les perf respectives des jvm linux/windows, j'ai comme qui dirait un gros doute vois tu.
Pour avoir fait tourne la meme version d'eclipse sur la meme machine et les memes projets sous linux et windows, je te garantit sur facture que le plus rapide est tres loin d'etre celui que tu penses.
Sinon, oui, techniquement, c'est faisable.
Pas pour autant que c'est reellement utilisable.
Je suis un grand fan d'eclipse, je l'utilise tous les jours et ne concoit pas de bosser avec autre chose, mais dire qu'eclipse tient raisonnablement dans 50Mo de ram me parait un peu trop partisan :)
-
-
[^]Re: Incompatibilités ?
Posté par Antoine () le 27/07/2007 à 13:06. (lien). Évalué à 3.java rend mon poil soyeux et mon sexe plus long.
Marrant, chez moi c'est l'inverse.-
[^]Re: Incompatibilités ?
Posté par Guillaume Rossignol () le 27/07/2007 à 14:12. (lien). Évalué à 3.java rend ton sexe soyeux et ton poil plus long ?
-
-
-
-
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 19/07/2007 à 12:51. (lien). Évalué à 4.Bah, avec PHP ça marchera toujours : si t'as *vraiment* besoin de faire tourner un truc en PHP4 et pas PHP5, ben suffit d'installer PHP4, qui sera toujours disponible, même si plus maintenu.
C'est même possible de faire cohabiter les deux dans un même apache. Là par contre tu auras peut-être intérêt à renommer tes fichiers .php qui doivent tourner en PHP4, en fichiers .php4 (et les liens internes aussi), mais c'est un assez moindre effort. Et pas besoin de regarder comment marche l'appli.
Ou alors de configurer apache pour lui dire que dans tel répertoire les fichiers .php sont à envoyer au module PHP4, et là, ya plus rien à changer à ton appli.
Bref, pour répondre au tout premier message, ça semble plus une bonne qu'une mauvaise idée. C'est aussi ça la force du libre : on n'est pas *obligé* de se traîner les boulets des erreurs de jeunesse des logiciels. On le voit bien avec le noyau Linux, il bouge énormément, cassant allègrement des vieilles compatibilités, au final on y gagne bien plus qu'on y perd.
Yth.-
[^]Re: Incompatibilités ?
Posté par astero () le 19/07/2007 à 14:23. (lien). Évalué à 0.Voilà tout a été dit... les applis php4 tournent avec php4 point.
Faut comprendre que les pauvres dev sont souvent surchargés et ont autre chose à faire que de se replonger dans des trucs qu'ils n'ont parfois même pas codés.
Et faut aussi comprendre qu'il y a *beaucoup* de situation où la mise à niveau php5 est strictement inutile.-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 19/07/2007 à 15:05. (lien). Évalué à 3.Ouhlà, prend pas mes propos pour parole d'évangile au sujet du PHP, moi je dev en Python sur le grand nain ternète. Et si j'ai du PHP à faire, il doit probablement être compatible PHP1 à PHP5 tellement je ne fais pas des choses complexes...
Je n'ai *aucune* idée de la réalité, et de l'importance, de cette incompatibilité entre PHP4 et PHP5. Globalement, ça marche pareil. Si on n'a pas de dev sous la main et que ça ne marche pas pareil, on peut bidouiller assez aisément avec apache pour avoir les deux.
Et je pense que dans la majeure partie des cas, il n'y a certes aucun besoin de passer de PHP4 à PHP5, mais aussi aucune difficulté, et que ça marche tout seul...
Alors je dis juste qu'il faut relativiser le problème, je ne crois pas qu'il y ait quoi que ce soit de dramatique...
D'un point de vue personnel, je n'aime pas le PHP, s'il est capable d'évoluer et de se débarrasser de ses défauts, je réviserait peut-être mon jugement, donc j'accueille la nouvelle plutôt bien !
Yth, qui retourne à son python, parce que le python, c'est bon !-
[^]Re: Incompatibilités ?
Posté par astero () le 19/07/2007 à 15:21. (lien). Évalué à 1.> Ouhlà, prend pas mes propos pour parole d'évangile au sujet du PHP (...)
Je ne faisait que confirmer vu que quelqu'un a osé te moinsser :)
Par contre je suis pas vraiment sûr que toutes les migrations soient si faciles... par exemple j'ai une appli codée avec register_globals (en gros ça influe la manière dont tu vas récup les données POST/GET) et reprendre tous les scripts un par un serait assez difficile... :/-
[^]Re: Incompatibilités ?
Posté par Kouenny () le 20/07/2007 à 07:21. (lien). Évalué à 1.Par contre je suis pas vraiment sûr que toutes les migrations soient si faciles... par exemple j'ai une appli codée avec register_globals (en gros ça influe la manière dont tu vas récup les données POST/GET) et reprendre tous les scripts un par un serait assez difficile... :/
Pour ce cas précis, tu peux toujours appeler extract($_GET) et extract($_POST) en tout début de script. D'accord, c'est sale, ça ne résoud pas le fait que "register_globals" c'est une chose horrible, mais ça marche !
-
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par Stéphane TRAUMAT (page perso, ) le 19/07/2007 à 12:42. (lien). Évalué à 2.ça fat un peu sale certes, mais au moins ça fonctionne et au moins en Java, tu as le choix de corriger maintenant ou plus tard.
C'est le principe des deprecated, on vous bloque pas mais on vous prévient que c'est dépassé ce que vous faites. C'est quand même plus sympa que de flinguer des programmes. PHP aurait du prendre exemple pour le coup.-
[^]Re: Incompatibilités ?
Posté par Laurent J (page perso, ) le 19/07/2007 à 13:44. (lien). Évalué à 2.Ça fait 3 ans que PHP5 existe. Je pense que ça a laissé quand même suffisament de temps pour corriger :-p
-
[^]Re: Incompatibilités ?
Posté par jarodender () le 20/07/2007 à 07:27. (lien). Évalué à 3.Même si je suis d'accord que PHP5 est meilleur que PHP4, beaucoup de grandes entreprises restent encore sous PHP4 car lorsqu'un site a été développé et fonctionne bien sur un intranet, les budgets sont alloués pour corriger des bugs, rajouter des évolutions visibles par les utilisateurs. Il faut toujours justifier le besoin de faire une migration pour un budget et dire que PHP5 est meilleur que PHP4, les décisionnaires ils trouvent ça un peu juste comme argument.
De plus d'après mes souvenirs, on associe souvent une version PHP à un ensemble LAMP enterprise, donc cela impose de faire une migration apache, php et mysql, ce qui implique : soit de changer de machine, soit de faire évoluer tous les projets en même temps, car on essaie de faire de la mutualisation sur les serveurs car la virtualisation n'est pas toujours au point. (ou validée)
Donc résumer en disant que PHP5 est sorti il y a 3 = cela a donné le temps de se mettre à jour, ne me semble pas un argument valable pour des décisionnaires d'entreprise qui recherchent à limiter les budgets à tout prix.
Donc pour moi aussi il serait plus agréable de savoir que PHP5 garde la compatibilité avec PHP4, malheureusement ce n'est pas le cas.
J'ai récemment dû faire une migration de ce type (LAMP enterprise), pour un changement de version mineur (pour MySQL je ne suis plus trop sûr des versions) :
- Apache 1.2
- PHP 4.2
- MySQL 4.0
vers
- Apache 1.3
- PHP 4.3
- MySQL 4.1
Et bien ça a pris un certain temps en terme de jours/hommes pour vérifier que tout allait bien se passer (notamment à cause du changement de version de MySQL qui avait des répercussions entre autre sur le type date ...) pour toutes les applications.
J'imagine donc sans mal des problèmes équivalents s'il faut changer Apache 1.3 en 2.0, PHP 4 en PHP 5 et MySQL 4.1 en 5.0, bref y'a de quoi bien s'amuser !!-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 20/07/2007 à 09:41. (lien). Évalué à 3.Oui, mais, il n'y a que le support PHP4 qui est arrêté.
Le service LAMP avec PHP4 et tout un tas d'applis PHP4 dessus, il suffit de le laisser en place, et tout va continuer à fonctionner. Les sources sont (et seront) toujours disponibles. On pourra encore installer un PHP4 dans dix ans, même s'il faudra un Apache 2.2 maxi par exemple, il sera aussi disponible...
Les gens ne sont pas *obligés* de migrer !
surtout s'il s'agit d'un serveur entièrement géré par une entreprise et qu'elle n'a rien à demander à qui que ce soit.
L'idée là c'est plus que les services d'hébergements de pages web, sont incités à passer à PHP5. Dessus il y a majoritairement (j'insiste sur ce mot) des sites persos. Donc des forums, blogs, et cie, qui souvent vont très bien fonctionner en PHP5, pour peu éventuellement qu'une mise à jour soit faite.
En fait, je doute que cette annonce change vraiment grand chose pour les entreprises...
Je peux me tromper.
Yth.-
[^]Re: Incompatibilités ?
Posté par jarodender () le 20/07/2007 à 12:22. (lien). Évalué à 2.En entreprise, comme partout ailleurs, il y des configurations "supportées" et d'autres qui deviennent obsolètes, la différence c'est que dans le monde entreprise, le "retard" est largement au delà des 3 ans. Dans l'entreprise où j'ai fait ma migration, les projets (étude) qui voulaient programmer en PHP5 devaient demander une dérogation pour le faire. Et cette entreprise envisage de passer à PHP5 vers 2008/2009 pas avant. Donc le problème de migration existe bel et bien tôt ou tard, car lorsque la version 6 sera validée, je pense qu'ils ne supporteront plus PHP4.
C'est un peu comme les systèmes d'exploitation, en entreprise il reste encore des AS400 / MVS / UNIX, mais ces systèmes évoluent encore (je suis pas sûr pour l'AS400) et essaient justement de garder une compatibilité avec les anciennes versions (surtout MVS) pour que les migrations se fassent en douceur (vive IBM)
Donc pour moi dans l'idéal il faudrait :
- soit une version PHP5 compatible PHP4,
- soit fournir les outils pour transformer tout code compatible PHP4 en code PHP5
De toute façon, le problème n'est pas d'améliorer le langage, au contraire c'est une excellente nouvelle, il faut juste trouver le moyen pour que les migrations se fassent en douceur, sinon PHP va avoir une mauvaise réputation (si ce n'est déjà fait). Par exemple quand je discute de PHP avec des experts en sécurité, en général on me rit au nez car pour eux le langage est trop laxiste et de ce fait n'encourage pas à écrire du code sécurisé par défaut (don't feed the troll surtout un vendredi).-
[^]Re: Incompatibilités ?
Posté par Raphaël Gertz (Jabber id, page perso, ) le 28/07/2007 à 18:07. (lien). Évalué à 4.Par exemple quand je discute de PHP avec des experts en sécurité, en général on me rit au nez car pour eux le langage est trop laxiste et de ce fait n'encourage pas à écrire du code sécurisé par défaut (don't feed the troll surtout un vendredi).
Tout dépend comment tu code ton site en php...
Si tu as :
- register_global
- non filtrage des données users
- upload de fichier .php dans un répertoire où le php peux être interprété
- eval a gogo
ton site sera une passoire et fera un très bon shell sur internet.
Par contre si tu code proprement en utilisant :
- register_global off (par défaut depuis php5)
- $_GET $_POST correctement nettoyées, peu de globales
- vérification de type sur les fichiers envoyé (vérifier que ça contient pas .php a la fin, mais ton type demandé)
ton site sera correct et ne devrais pas avoir de soucis niveau sécurité.
Bon après on laisse toujours une faille quelque part, selon le nombre de ligne écris...
-
-
[^]Re: Incompatibilités ?
Posté par Zenitram (page perso, ) le 21/07/2007 à 08:52. (lien). Évalué à 2.Le service LAMP avec PHP4 et tout un tas d'applis PHP4 dessus, il suffit de le laisser en place, et tout va continuer à fonctionner.
Ah bon?
Laisser une tonne d'applis avec plein de trous de sécurité (puisque PHP4 sera aussi arrêté coté patch de sécurité...)?
Voila un drôle de conseil...-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 21/07/2007 à 14:17. (lien). Évalué à 0.* Ca ne sera pas moins sécurisé qu'aujourd'hui.
* Si tu as des gens pour faire des audits de sécurité, et coder des patchs pour tes applis, alors tu as des gens pour les migrer en PHP5 pour raisons de sécurité. Ce n'est qu'un patch de plus, pas forcément plus difficile à faire qu'un autre (ça reste globalement pareil PHP).
* Si tu ne développes pas l'appli toi-même, mais que tu te contentes de la maintenir à jour, pour raisons de sécurité, c'est elle qui passera à PHP5, pour raisons de sécurité.
Le seul argument qu'il te reste sont les patchs de sécurité PHP4.
Qui sont encore maintenus pour pas mal de temps, un an.
Ca laisse le temps de trouver une solution, si c'est vraiment critique, non ?
Et les problèmes de sécurité de PHP4 sont justement une des raisons de l'existence de PHP5. Donc, si c'est vraiment critique, alors, tu fais l'effort de migrer, non ? Et si ça ne l'est pas et que comme la plupart des gens tu as un PHP4 pas super à jour avec les tout derniers patchs, ça ne changera pas grand chose...
Yth.-
[^]Re: Incompatibilités ?
Posté par Zenitram (page perso, ) le 21/07/2007 à 16:42. (lien). Évalué à 1.Ca, c'est trop gros pour laisser passer :
* Ca ne sera pas moins sécurisé qu'aujourd'hui.
Ca dépend : si une faille est découverte (et ça arrive quand même souvent), l'appli sera sacrément moins sécurisé qu'aujourd'hui, faute de patch de sécurité.
Dire qu'on garde une ancienne appli sur le web non maintenue coté sécurité (non maintenu coté évolution, oui on s'en fout, mais coté sécurité...), c'est pas mal offrir un grand boulevard pour le futur aux crackers.
Oui, il reste un an, mais donc il faut y penser maintenant. Ou alors jouer avec la roulette russe. C'est un choix, faut toutefois en être conscient plutôt que dire un "Ca ne sera pas moins sécurisé qu'aujourd'hui" dépendant de ce que sera le futur...-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 22/07/2007 à 00:06. (lien). Évalué à 1.Le « trou » existe déjà, il peut déjà être exploité, garder strictement la même configuration ne rend pas avec le temps ton appli mon sécurisée.
Le trou, il est là, ou il n'est pas là, c'est quand même assez binaire...
Ce n'est pas parce qu'une faille est découverte six mois après la sortie d'un logiciel, qu'elle n'était pas déjà présente au début.
"Ca ne sera pas moins sécurisé qu'aujourd'hui" dépend strictement de comment c'est aujourd'hui.
Yth.-
[^]Re: Incompatibilités ?
Posté par Thomas Douillard () le 22/07/2007 à 08:54. (lien). Évalué à 3.Oui, mais non, ça c'est dans l'absolu.
En pratique il y a des trucs qui changent avec le temps, la connaissance de l'appli par les attaquants potentiels, les technos d'attaques, l'environnement logiciel autour, des trucs que tu peux pas forcément imaginer qui font qu'apparaitrons des failles au cour du temps, ou plutôt des moyens d'attaquer ton appli. Peut être même si ton appli pouvait à la base considérée comme sécurisée à la base.
Le tout amha :)-
[^]Re: Incompatibilités ?
Posté par Yth (Jabber id, ) le 22/07/2007 à 11:35. (lien). Évalué à 2.Ouais, ça sera mieux connu, donc plus facile d'exploiter les failles.
Pas moins sécurisé, mais plus aisé d'accès...
Mais ce problème reste plus large, non ? Je veux dire, si une boîte veut assurer la sécurité de son appli, et réagir à toutes les failles trouvées, elle doit entretenir des développeurs pour faire ce travail ?
Ces développeurs peuvent migrer l'appli en PHP5, finalement c'est aussi une correction de failles multiples, non ?
Et si la boîte ne veut pas avoir de devs qui se chargent du bidule, c'est qu'implicitement elle accepte le risque que des failles soient trouvées, mais qu'il sera bien temps de réagir à ce moment là, d'ici là il y a le fameux : « ça marche, on ne touche pas. »
Et si on ne touche pas parce que ça marche, on ne touche à rien, on conserve le serveur sans rien changer, le même apache, le même PHP4, et tout fonctionne comme avant.
En gros l'entreprise elle a deux alternatives : focaliser sur lasécurité et toujours tout mettre à jour, patcher, et corriger. Je pense que là la migration PHP4->PHP5 rentre dans la politique de sécurité, ça fait juste un patch de plus, à mon avis pas extrêmement complexe à faire.
Ou alors se dire « ça fonctionne on ne touche à rien », et là, que le PHP4 soit ou non encore supporté n'a aucune importance : quand on ne touche à rien, on ne touche à rien...
Me trompé-je ?
Y'a-t-il vraiment un cas pratique où l'arrêt du support de PHP4 va réellement causer des problèmes ?
Yth...-
[^]Re: Incompatibilités ?
Posté par Thomas Douillard () le 22/07/2007 à 15:02. (lien). Évalué à 1.ça fait juste un patch de plus, à mon avis pas extrêmement complexe à faire.
Ben ça dépend surtout de la taille du patch, une migration vers une version sensée être compatible ça se passe déjà pas toujours bien, alors une migration vers une version incompatible, c'est pas forcément léger.
Après j'ai pas touché à PHP depuis un bail, donc je sais pas trop ce que ça peut représenter.
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par tcheuck () le 19/07/2007 à 12:02. (lien). Évalué à 1.Je pense surtout que ça viens de la manière dont certains ont appris à coder: comme des porc.
Mais c'est pas forcement leurs fautes. Par exemple il n'est pas rare de voir sur des forums des gros malin suggérer de remplacer la balise d'ouverture "<?php" par "<?" pour gagner 0,0000001 sec d'exécution sur un code hyper crade...
C'est en grande partie pour ça que je suis plus ou moins pour la disparition du style "procédural" dans PHP, ce qui obligerais pas mal d'utilisateurs de PHP à réapprendre a coder proprement, et ça serait pas plus mal...
De toutes façons, plus on va monter dans les versions de PHP, plus les scripts codées avec les pieds seront inutilisables.-
[^]Re: Incompatibilités ?
Posté par louis perrier () le 19/07/2007 à 12:31. (lien). Évalué à 4.et beaucoup de dev vont devoir se mettre à niveau ...
-
[+] [^]Re: Incompatibilités ?
Posté par Julien Portalier (page perso, ) le 19/07/2007 à 12:44. (lien). Évalué à -2.J'espère que tu n'inclues pas la forme <?= $foo ?> qui permet de remplacer <?php echo $foo ?> dans ton propos, si ? Parce que si ce n'est pas plus rapide pour l'interprète, c'est plus rapide et agréable à lire pour le programmeur.
> plus on va monter dans les versions de PHP, plus les scripts codées avec les pieds seront inutilisables.
Tant mieux.-
[^]Re: Incompatibilités ?
Posté par tcheuck () le 19/07/2007 à 16:36. (lien). Évalué à 6.J'espère que tu n'inclues pas la forme <?= $foo ?> qui permet de remplacer <?php echo $foo ?> dans ton propos, si ?
Si. C'est tout simplement déconseillé, car si y pète a l'administrateur du serveur de basculer "short_open_tag" a "Off", bah du jour au lendemains toutes tes pages qui utiliserons les "short_open_tag" (<?) verrons leurs code source (PHP) affiché à l'écran...
Quand au fait que ce soit plus rapide, peut être pour le dev, oui. Mais c'est comme ne pas échapper ses requêtes SQL, ou utiliser $argument à la place de $_POST['argument'] parce que "register_globals" est activé: ça s'appelle coder avec les pieds.-
[^]Re: Incompatibilités ?
Posté par windu.2b (Jabber id, page perso, ) le 19/07/2007 à 17:18. (lien). Évalué à 3.Sans oublier que le "short_open_tags=on" chie dans la colle en cas de prologue XML...
-
[+] [^]Re: Incompatibilités ?
Posté par Gniarf () le 20/07/2007 à 08:25. (lien). Évalué à -6.faudrait savoir si tu fais du PHP ou du XML, toto...
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Incompatibilités ?
Posté par François B. () le 20/07/2007 à 09:46. (lien). Évalué à 2.<bloc mode="sarcastique">Ah ? PHP est tellement nul qu'il est impossible de générer du XML avec ? Comme du XHTML par exemple ?</bloc>
-
[+] [^]Re: Incompatibilités ?
Posté par Gniarf () le 20/07/2007 à 12:57. (lien). Évalué à -1.je dis surtout que du PHP c'est du PHP et du XML c'est du XML et que certains neuneux ont du mal avec cette séparation de base.
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Incompatibilités ?
Posté par windu.2b (Jabber id, page perso, ) le 20/07/2007 à 13:50. (lien). Évalué à 2.Et qui a dit le contraire? Moi?
J'ai dit que quand on a dans une page HTML (comme un squelette), un prologue XML sur la toute première ligne, et des balises PHP à certains endroits (pour afficher certaines infos: menus, zone principale, header & footer...) mais que les balises courtes sont tolérées, ben tu peux être sûr d'une chose: tu vas te faire jeter par l'interpréteur PHP!
Tout simplement parce qu'il a aura essayé de lire la toute première ligne de ta page (qui est le prologue) car il aura cru que c'était du PHP, mais n'aura pas su comprendre tout ce qui suit la balise...-
[^]Re: Incompatibilités ?
Posté par Gniarf () le 20/07/2007 à 16:24. (lien). Évalué à 2.je comprends très bien et partout où je passe je mets short_open_tag à off. mais c'est pas la question.
là tu parles d'un fichier PHP, un squelette, qui donnera du XML en sortie du processeur PHP, enfin tu l'espères... mais tu considères que ce squelette est lui-même un fichier XML et doit donc forcément comporter ton prologue magique. à part des cas triviaux, c'est rarement vrai.
te faire jeter par l'interpréteur PHP est donc normal et surtout considérer que ton fichier d'entrée est (ou doit ou devrait être) un fichier XML même s'il est plein de balises et de code PHP (ou pire) est une aberration.--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Incompatibilités ?
Posté par François B. () le 20/07/2007 à 18:56. (lien). Évalué à 1.Ca sert à quoi alors que XML spécifie les processing instructions si PHP ne les utilise pas correctement. Se baser sur un processeur XML pour faire un éditeur PHP est simplement du bon sens... enfin, c'est mon avis. Si l'éditeur impose une certaine rigueur dans la structure, c'est tant mieux pour coder proprement et ainsi avoir une chance d'avoir une page valide au final.
Spécification des processing instructions : http://www.w3.org/TR/2006/REC-xml-20060816/#sec-pi-
[^]Re: Incompatibilités ?
Posté par Gniarf () le 21/07/2007 à 09:19. (lien). Évalué à 2.Ca sert à quoi alors que XML spécifie les processing instructions si gcc ne les utilise pas correctement.
oops, gcc il bouffe du C, pas du XML
c'est pareil avec PHP et ce setting préhistorique, il n'est pas fait pour manipuler du XML ainsi.
(et au passage, à l'origine PHP ne pouvait même pas interpréter du HTML, alors croire qu'il a été conçu pour travailler en bonne intelligence avec XML... bref. limite si c'est pas un accident s'il a choisi <? et pas [? ou autre (* ... tant mieux si ça permet des bidouilles, hein, c'est pas la question)--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Incompatibilités ?
Posté par tcheuck () le 21/07/2007 à 17:16. (lien). Évalué à 1....et au passage, à l'origine PHP ne pouvait même pas interpréter du HTML, alors croire qu'il a été conçu pour travailler en bonne intelligence avec XML... bref.
De la version 1 à la 5, le "moteur" de PHP à été réécrit deux ou trois fois quand même...
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par François B. () le 20/07/2007 à 13:55. (lien). Évalué à 1.Mais dans le cas où notre script PHP génère un flux XML comme par exemple du XHTML, il est de bon ton de mettre un <?xml version="1.0"?> au début du script. Or cet entête casse tous tes scripts si un abruti d'admin chez ton hébergeur active les tags courts.
On n'a pas toujours la maitrise totale de ce qui se passe sur le serveur...-
[^]Re: Incompatibilités ?
Posté par Gniarf () le 20/07/2007 à 15:46. (lien). Évalué à 3.dans le cas où notre script PHP génère un flux XML comme par exemple du XHTML, il est de bon ton de mettre un <?xml version="1.0"?> au début du script.
non. il est de bon ton que ce <?xml version="1.0"?> se retrouve au début de ta sortie de PHP, nuance. ça peut se faire autrement qu'en plaçant <?xml version="1.0"?> en début de script.
abruti d'admin chez ton hébergeur
problème isolé, plus qu'à agir \o/--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008
-
-
-
-
-
-
[+] [^]Re: Incompatibilités ?
Posté par pw00t () le 20/07/2007 à 07:56. (lien). Évalué à -3.d'un autre cote, si tu veux pas coder avec les pieds, tu commences par eviter php.
Rien que cet exemple d'avoir 2 balises pour marquer ton code, ca laisse pas augurer du meilleur..
Apres, php a l'air de vouloir se debarrasser de cette image de langage bourrin pour faire toutes les conneries de la planete, tant mieux :)-
[^]Re: Incompatibilités ?
-
-
-
-
[^]Re: Incompatibilités ?
Posté par Antoine () le 27/07/2007 à 13:08. (lien). Évalué à 3.C'est en grande partie pour ça que je suis plus ou moins pour la disparition du style "procédural" dans PHP, ce qui obligerais pas mal d'utilisateurs de PHP à réapprendre a coder proprement
Oui, parce que si on fait de l'objet c'est forcément propre et bien codé (tm).
La brigade idéologique des javalâtres a encore frappé.
-
-
-
[^]Re: Incompatibilités ?
Posté par Camille_B (Jabber id, page perso, ) le 19/07/2007 à 12:05. (lien). Évalué à 4.N'étant pas un spécialiste en programmation la question que je vais poser est vraiment une question.
La rétrocompatibilité est-elle si rare dans le monde des langages de programmation ?
Faut-il nécessairement que le langage passe par une phase de standardisation pour qu'il gagne une certaine stabilité lui permettant de traverser les âges sans demander au développeur de récrire son code tous les 4 ans ?
Si je lis les autres commentaires, apparemment la plupart des langages, sauf modifications majeures dans la conception même du langage (on citait python3000 mais je pense aussi au prochain perl), sont rétrocompatibles avec leur anciennes versions ...-
[^]Re: Incompatibilités ?
Posté par Julien Portalier (page perso, ) le 19/07/2007 à 12:58. (lien). Évalué à 3.Bonne question. Concernant PHP il a débuté sur du pur procédural (avant PHP3) pour implémenter de l'objet au fur et à mesure. Bref le language lui-même est passé du procédural à l'objet, tout en restant compatible avec le procédural. Je pense que c'est justement cet héritage procédural qui fait de PHP un language difficile à faire évoluer sans tout casser. Il faudrait (presque) le forker et tout transformer en profondeur pour fonder un PHP6 où tout serait objet, et non fonctions et, ou objets (comme l'extension SQLite 2), etc.
Je n'ai pas suivi l'évolution de PERL, mais il me semble que c'est ce qu'ils ont choisi de faire pour la version 6 : repenser tout le language. D'ailleurs après avoir lu quelques trucs, il a l'air pas mal du tout ce PERL 6.
PHP intégre les changements graduellement. C'est pratique, car si on programme de manière propre, l'évolution du code est simple. Il suffit de lire les guides de migration, et on passe sans trop de difficultées d'une version à sa suivante. Mais c'est aussi un très gros inconvénient en ce que le language est inconstant.
D'autres languages, comme Ruby, ne devraient pas avoir ce problème à mon avis. Ils ont été conçus pour un style de programmation (pur objet), et ne mélangera pas plusieurs formes en un seul language (ce serait contraire à sa philosophie).-
[^]Re: Incompatibilités ?
Posté par Camille_B (Jabber id, page perso, ) le 19/07/2007 à 13:32. (lien). Évalué à 7.Je comprends mieux. En réalité mes connaissances en programmation tournent surtout autour de LISP. Le langage pouvant être récrit à l'intérieur de lui-même de manière dynamique (je ne sais pas si je suis très clair), l'implémentation de l'orienté objet (ou n'importe quel autre paradigme) ne pose pas vraiment de problèmes de compatibilité ascendante. Le langage n'a pas besoin d'être repensé pour changer de forme.
Finalement, pour en revenir à PHP, il s'agit d'une bonne chose Mais n'aurait-il pas été plus simple de 1) repartir de presque zéro et créer un PHP orienté objet à côté du PHP procédural ? ou 2) ne pas s'orienter vers l'OO et peaufiner le procédural ?
J'avoue ne pas avoir beaucoup d'atomes crochus avec l'OO. Comme je l'ai dit plus haut je ne suis pas un spécialiste en programmation. J'apprends la progra devant mon ordinateur avec LISP (sous plusieurs formes) et frôlant quelques autres langages. Autant le procédural ne me pose pas trop de problèmes et le fonctionnel m'excite au plus haut point, autant l'OO me semble apporter beaucoup de complexité pour un gain relativement faible. J'ai lu que l'OO facilitait la programmation en équipe et était plus adapté au jeu vidéo et au interfaces dites "graphiques".
N'ayant jamais programmé en équipe, ni créé de jeux vidéos, ni écrit d'applications pour un environnement de bureau quelconques, j'avoue ne pas pouvoir apprécier l'OO à sa juste valeur (un jour peut-être ...(j'ai d'ailleurs des doutes quand à la prétendu supériorité de l'orienté objet dans le monde des interfaces graphiques. Il est vrai que certaines excellentes fonctionnalités de NeXTStep/MacOSX/GNUstep ne seraient pas sans la capacité de l'Objective-C à gérer le typage et le chargement dynamique. Il est vrai que des environnements de bureaux, voire de simple gestionnaires de fenêtres, écrit dans des langages impératifs (je pense à Gnome et E17 écris majoritairement en C, si mes souvenirs sont bons) semblent plus "statiques" qu'un Kde ou un GNUStep. Pourtant ils fonctionnent, et plutôt bien. Mais je pense surtout à un gestionnaire comme Sawfish qui tire de LISP une très grande flexibilité, et la capacité à être modifié "dynamiquement" (désolé je n'ai pas les mots permettant de m'exprimer plus convenablement) grâce à l'interpréteur rep fournit.)).
Après cette longue introduction ma question est : l'Orienté Objet est-il vraiment indispensable à la programmation web côté serveur, ou s'agit-il ici de la conséquence de l'effet de mode entourant l'Orienté Objet dans le monde de l'entreprise ?-
[^]Re: Incompatibilités ?
Posté par Thomas Douillard () le 20/07/2007 à 09:22. (lien). Évalué à 5.L'orienté objet, c'est intéressant quand tu manipules des données complexe, quand tu fais de la modélisation, quand tu fais des architectures logicielles, cf les "design patterns" qui fournissent des solutions génériques en objet à des problèmes communs et qui évitent de réinventer la roue.
Ce qui est particulièrement intéressant en objet c'est le côté : tu modélise tes données, tu as déja une partie de ton appli architecturée. Le modèle de données est écrit dans le code, c'est structuré : tu as les données et le code qui permet de les manipuler dans une seule classe. Tu me diras tu fais un package en procédural c'est la même chose. Mais quand tu codes avec un IDE, quand tu tapes le nom de ton objet, l'ide connait son type et te propose les méthodes que tu peux appeler c'est bien agréable. En bref ça facilite la vie du modélisateur/concepteur, du mec qui veut rentrer dans le code, des générateurs de code à partir de modèles, des codeurs d'ide, des codeurs tout court, etc. Tout ça parce que le code est plus "informatif" sémantiquement que du code procédural.
Et le fait que ce soit une appli web côté serveur n'influe pas beaucoup, ça dépend surtout de à quoi sert l'appli.
Le truc des interfaces graphiques c'est que l'objet colle parfaitement : un "bouton" <-> un objet. Un clic sur le bouton, ou sur un autre objet graphique <-> appel de la méthode dédiée. Mais ça veut pas dire que l'objet ne sert à rien sur des modèles moins "visuels" : une usine avec des employés, des machines, des salaires, des employés qui sont affectés à des machines, tu as facilement les classes de ton modèle.
Un truc pas mal aussi à mon avis : dans certaines API genre l'API java, la cohérence quand c'est bien conçu : n'importe quelle collection d'objet hérite de la classe collection, que tu manipule un vecteur d'objet, une liste d'objet, ou autre. Les méthodes sont les mêmes, les collections sont interchangeables.
Tu aimes bien le fonctionnel, un des points forts du fonctionnel selon moi c'est la généricité : fonctions d'ordre supérieur, etc.
En objet, tu as de la généricité aussi, de manière différente, plus évidente à capter question utilisation : l'héritage, l'implémentation de méthode virtuelle, par exemple. Entre autre.-
[^]Re: Incompatibilités ?
Posté par Camille_B (Jabber id, page perso, ) le 20/07/2007 à 18:42. (lien). Évalué à 3.Merci pour toutes ces informations. N'ayant pas une forte pratique de la programmation, il m'est difficile d'opposer quoi que ce soit à ton discours ;)
Je vais jeter un ½il sur la modélisaition des données et les design patterns, domaine que je ne connais que de nom, raison pour laquelle je dois avoir manqué l'intérêt de l'OO.
En fait ma question était plus simple. Il est certain que l'orienté objet a beaucoup d'avantages, mais sa quasi omniprésence est-elle justifiée ?
J'ai l'impression, corrigez-moi si je me trompe, que l'OO est particulièrement populaire car il facilite la gestion de données complexes de plus en plus présente de nos jours via l'informatisation massive des infrastructures et la numérisation massive des données.
En réalité je n'ai pour l'instant jamais eu à traiter des données complexes dans le cadre de mon apprentissage strictement autodidacte de la programmation. Aussi l'OO m'apportait un surcroît de complexité qui me paraissait inutile.
Cependant je révise en partie mon jugement, je suis en train de m'initier à Ruby, et je dois avouer que pour une fois (après Objective-C, C#, et dans une moindre mesure Java) l'OO me paraît naturel !
En fait je crois que ce que j'aime par-dessus tout ce sont les langages sobres. Java ou C# sont bien trop verbeux à mon goût ;)
En tout cas merci pour toutes ces précisions qui viennent nourrir allégrement ma réflexion sur le sujet !
-
-
[^]Re: Incompatibilités ?
Posté par Moonz () le 20/07/2007 à 17:44. (lien). Évalué à 3.> autant l'OO me semble apporter beaucoup de complexité pour un gain relativement faible.
Un article plutôt intéressant: http://www.etoile-project.org/etoile/blog/2007/07/road-to-co(...)
C'est quelque chose AMHA difficilement réalisable en procédural (et certainement pas élégamment)-
[^]Re: Incompatibilités ?
Posté par Camille_B (Jabber id, page perso, ) le 20/07/2007 à 18:51. (lien). Évalué à 2.Merci beaucoup.
Je suis régulièrement le développement d'Étoilé et de GNUStep. C'est d'ailleurs GNUStep qui m'a poussé à apprendre Objective-C. Langage définitivement trop obscure (je pense particulièrement aux implémentations de méthodes absolument hallucinantes) pour un débutant habitué à LISP. Et surtout, c'est un langage trop peu documenté.
L'apprentissage (ou plutôt le survol), m'a appris une chose : sans certaines de ses fonctionnalités (comme le chargement dynamique si je ne me trompe pas) une fonctionnalité comme le menu Services (bien connu également des utilisateurs de MacOSX) serait, sinon impossible, du moins très complexe à réaliser en C (par exemple).
Donc je suis tout à fait d'accord pour dire que l'OO apporte pleins de bonnes choses ;)
Mais ma question est toujours la même, son utilisation massive est-elle toujours justifiée ?
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par CrEv (page perso, ) le 19/07/2007 à 15:27. (lien). Évalué à 1.Ouai, et quand on aura PHP 11.0, il faudra se taper des .php11 ? n'importe quoi.
C'est pas si "n'importe quoi" que ça... (attention, je suis pas forcément pour non plus...)
Il n'y a pas si longtemps (bon en fait si) on avait des fichiers .php3 et des .php4 qui étaient souvent des .php
Donc oui, dans ce cadre de transitions et surtout de mélange de php sur un même serveur je trouve ça normal et pratique d'avoir des extensions différentes (mais pour moi .php doit toujours rester la version courante, et .php#{oldversion} pour les autres)
(troll) ps : saurez-vous reconnaitre le langage que j'utilise actuellement ? ;-)-
[^]Re: Incompatibilités ?
-
-
-
[^]Re: Incompatibilités ?
Posté par defdrek () le 19/07/2007 à 11:50. (lien). Évalué à 2.Je n'arrive pas à trouver de graphs sur l'utilisation du C# Vs PHP... mais je pense que Microsoft saisira l'opportunité pour critiquer les langages "libres".
Vu les problèmes causés par la transition "forcée" de VB6 vers VB.NET, je pense que ça serait donner la bâton pour se faire battre :)-
[^]Re: Incompatibilités ?
Posté par Camille_B (Jabber id, page perso, ) le 19/07/2007 à 11:57. (lien). Évalué à 1.VB6 et VB.NET sont deux langages différents. Qui oserait dire qu'entre C++ et C#, qu'entre Common Lisp et L# il y a juste un saut de version ?
La vérité c'est que Microsoft en conseillant de passer à VB.NET a tout simplement mit fin au langage Visual Basic "standard".
Comme VB6 et VB.NET sont tous les deux des produits Microsoft, il était plus facile de faire croire à une mise à jour du langage.-
[^]Re: Incompatibilités ?
Posté par defdrek () le 19/07/2007 à 12:27. (lien). Évalué à 2.On pourrait faire la même remarque pour PHP qui est passé d'un langage procédural (non, pas un langage syntaxique :) ) à un langage orienté objet. Par exemple le fait que par défaut les objets soient passés par référence et non plus par valeur peut avoir beaucoup de répercussions sur le fonctionnement de l'application.
-
[+] [^]Re: Incompatibilités ?
Posté par astero () le 19/07/2007 à 14:33. (lien). Évalué à -1.Houla... php5 un langage objet ?!
Bizarre, j'ai pourtant l'impression d'utiliser un paquet de fonctions quand je code PHP.
Rien à voir avec du Java ou du C# en tout cas... qui eux sont des langages objets je pense.-
[^]Re: Incompatibilités ?
Posté par tcheuck () le 19/07/2007 à 16:46. (lien). Évalué à 0.Bizarre, j'ai pourtant l'impression d'utiliser un paquet de fonctions quand je code PHP.
C'est ce qu'on appelle la rétrocompatibilitée...-
[^]Re: Incompatibilités ?
Posté par astero () le 19/07/2007 à 17:00. (lien). Évalué à 6.ah bon...
Tu m'expliques alors comment on fait pour avoir la longueur d'une chaine sans passer par une fonction ?
str_length($foo) aurait pu être qualifié de rétro compatibilitée si il ya avait un $foo.length() mais il n'y en a pas. Pareil pour les tableaux et tous les types de bases.
Désolé mais quand même les string et les tableaux ne sont pas de objets, bah on code pas objet...
Comment tu manipules les fichiers ? avec des objets ? nan... bref, en PHP pratiquement rien n'est objet, s'il y avait les équivalent alors OUI on pourrait parler de rétro compatibilité
Au passage cite moi des libs STANDARDS qui sont orientées objets... alors il y a déjà PDO et euh... euh...
-
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par Julien (page perso, ) le 19/07/2007 à 11:57. (lien). Évalué à 4.C'est une des nombreuses raisons pour lesquelles j'aime Python. A l'exception de Python 3000 qui sera vraiment la première version qui sera backward incompatible, un script écrit il y a 10 ans tournera toujours sans problèmes (ou alors avec des corrections vraiment mineures) sur les versions d'aujourd'hui.
Sans vouloir troller, je pense que PHP occupera de moins en moins de part de marché dans le futur, quand on voit tout les problèmes et les incohérences de ce "langage" ...-
[^]Re: Incompatibilités ?
Posté par tcheuck () le 19/07/2007 à 12:09. (lien). Évalué à 5.Sans vouloir troller, je pense que PHP occupera de moins en moins de part de marché dans le futur, quand on voit tout les problèmes et les incohérences de ce "langage"
Tu te trompe, pour deux raisons:
- C'est un langage très facile à apprendre, avec une communauté énorme,
- Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.-
[^]Re: Incompatibilités ?
Posté par √λιi () le 19/07/2007 à 12:43. (lien). Évalué à 5.- Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.
Et tout ca fait beaucoup de mal a l'informatique ... parce que ces gens apprennent mal, et propagent leur mauvais savoir faire au sein de leur communauté. Ca me fait penser a l'actionscript (jusqu'au 2 au moins), ou des graphistes en viennent a dire que la programmation c'est de la merde, parce que le moindre truc leur demande des heures de boulot, ils en arrivent a faire une mosaique de code variant entre mauvais et catastrophique pioché ici ou la sur le net, sans se rendre compte que cette techno est un truc immonde, ou même un dévelopeur aguerri peut avoir beaucoup de mal a faire du code propre.
Quoiqu'il en soit tu as raison : ces deux points son la garantie que l'on est pas pret de voir php disparaitre mais j'espère que php ne fera pas autant de mal a la programmation de serveur web que le COBOL a fait a l'informatique d'entreprise.-
[^]Re: Incompatibilités ?
Posté par Stéphane TRAUMAT (page perso, ) le 19/07/2007 à 12:48. (lien). Évalué à 0.Moi je trouve le PHP aussi très bien. J'espère juste qu'il ne va pas devenir comme Access :) C'est à dire un truc que tout le monde utilise n'importe comment, n'importe où, à tort et à travers... et surtout dure à maintenir étant donné les différences de niveaux qui existent parmis les gens qui dont du PHP
-
[^]Re: Incompatibilités ?
Posté par CrEv (page perso, ) le 19/07/2007 à 15:21. (lien). Évalué à 6.parce que c'est pas déjà le cas ?
-
-
-
[^]Re: Incompatibilités ?
Posté par Stéphane TRAUMAT (page perso, ) le 19/07/2007 à 12:45. (lien). Évalué à 3.Sur le deuxième point, cela a sa limite quand même... Il y a justement tellement de CMS que les gens vont avoir de moins en moins à coder des options dedans, ce seront des logiciels prêt à l'emploi.
C'est comme de dire que de plus en plus de gens vont connaître le C car beaucoup se mettent à Linux. Non, ils se contentent d'utiliser linux comme les gens se contentent de plus en plus d'utiliser un CMS
Pour ce qui est de la communauté, c'est vrai que PHP a su crée une communauté énorme grâce à ses qualités. Maintenant, il y a vraiment de tout dans cette communauté....
-
[^]Re: Incompatibilités ?
Posté par Julien Portalier (page perso, ) le 19/07/2007 à 13:47. (lien). Évalué à 5.Je pense qu'il ne se trompe pas.
Je code en PHP depuis longtemps, en PHP 5 depuis au moins deux ans. J'ai même codé un framework MVC l'an dernier pour me faciliter la tâche (n'aimant pas ceux existants) et apprendre la forme objet de PHP 5.
Curieux, j'ai jeté plusieurs fois un ½il à Ruby. Je ne l'ai pas aimé les premiers temps, car la forme me rebutait. Cependant ces dernières semaines, j'ai lu les livres Why's (Poignant) Guide to Ruby et Programming Ruby (The Pragmatic Programmer's Guide)[2]. J'ai alors pris conscience de la vétusté (et de la staticité) de PHP ! Ruby est un language élégamment pensé, dans sa conception comme dans sa syntaxe et ses possibilités.
Je n'ai pas encore lu les livres sur Ruby on Rails que je saisi déjà toute sa puissance, et pourquoi Rails ne peut pas exister dans un autre language (moi aussi j'étais sceptique... avant). Je sais déjà que lorsque je serai au point sur Ruby, je passerai à Rails ; et lorsque je serai au point sur Rails, je laisserai tomber PHP, sans regrets (juste de la nostalgie). Ce qui me retient d'y passer de suite c'est que je suis efficace en PHP et qu'il va me falloir encore un peu de temps pour vraiment l'être en Ruby. Quoiqu'en fait il me faut juste lire un bouquin sur Rails, et me lancer.
Le seul truc qui m'embête c'est que la doc librement accessible de Ruby on Rails est assez spartiate -- seule la réf. est vraiment complète, ce qui est un peu abrupt pour découvrir le framework. Il faut donc acheter les livres. C'est dommage. En attendant les livres pour Ruby sont librement accessibles, notamment sur http://ruby-lang.org/fr/
[1] http://qa.poignantguide.net/
[2] http://www.rubycentral.com/pickaxe/
> C'est un langage très facile à apprendre
Ruby n'est pas dur. Vraiment. Sa syntaxe est pensée pour arranger le développeur, pas l'interprêteur (qui finalement y trouve très bien son compte). Cependant pour bien saisir Ruby, il vaut mieux avoir une bonne connaissance de la programmation et une connaissance solide de l'objet au préalable. J'avais déjà été impressionné par le modèle objet de PHP 5. Celui de Ruby est incomparable.
> Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.
C'est justement là le problème de PHP. Des tas de CMS et de frameworks dans tous les coins. Tellement de diversité qu'on ne sait plus vers quoi se diriger. Du coup on finit par coder ses propres outils, ce qui ne règle rien au problème.-
[^]Re: Incompatibilités ?
Posté par Slainer (Jabber id, page perso, ) le 19/07/2007 à 14:28. (lien). Évalué à 2.je suis entièrement d'accord !
pour ma part ça a été l'inverse. J'ai découvert Rails directement après quelques années de PHP sans passer par Ruby. Et ça a été le paradis. ça l'est encore aujourd'hui.
Effectivement pour s'y mettre il faut acheter un bouquin. Mais quel bouquin (je parle de Agile Web Development with Rails/Ruby on Rails chez Eyrolles en VF) ! J'ai rarement lu un bouquin aussi bien écrit, on sent la passion derrière. Plus que vouloir transmettre des connaissances, ce bouquin donne aussi envie d'utiliser ce framework, de s'y attacher. C'est limite de l'endoctrinement :).
Pour moi le meilleur bouquin de développement Web de ces 2 dernières années.
Je pense qu'avec un minimum de bagage en programmation objet, on a pas besoin de commencer à apprendre Ruby pour se mettre à Rails. J'ai commencé avec Rails et progressivement j'ai appris Ruby sans problème.
Comme dit, ce que j'adore avec Rails c'est la communauté de trolleurs passionnés autour. Contrairement à d'autres langages avec des centaines de bibliothèques, frameworks, etc, on avec Rails un ensemble homogène de qualité et une énorme communauté derrière.
Si vous ne connaissez pas, testez :).
Nicolas.
-
[^]Re: Incompatibilités ?
Posté par baud123 (Jabber id, page perso, ) le 19/07/2007 à 15:15. (lien). Évalué à 3.tu as une version en français en cours de traduction du Why's (poignant) guide
http://fr.poignantguide.net/
la version draft est là : http://fr-draft.poignantguide.net/ sous licence CC-by-sa
-
[^]Modèle objet de Ruby
Posté par Arthur Accroc () le 19/07/2007 à 16:40. (lien). Évalué à 0.J'avais déjà été impressionné par le modèle objet de PHP 5.
Je ne dirai rien, je ne le connais pas (encore; si je retrouve mon hors série PHP 5 de Linux Mag, j'y jette un coup d'oeil cet été).
Celui de Ruby est incomparable.
J'avais pensé ça aussi, quand j'avais essayé Ruby, et puis j'ai eu besoin d'un destructeur.
Je sais, s'il n'y a pas de destructeur, c'est dû au choix du garbage collector (alors peut-être est-ce un mauvais choix) et il y a moyen de contourner (mais c'est plus lourd et j'aime les langages qui supportent ma façon de penser et non pas qui m'imposent la leur).-
[^]Re: Modèle objet de Ruby
Posté par Camille_B (Jabber id, page perso, ) le 19/07/2007 à 16:54. (lien). Évalué à 5.Tous les langages imposent leur façon de penser. Il y a ceux compatible avec toi et les autres qui ne le sont pas.
Le langage compatible avec ta façon pensée impose tout autant sa façon de pensée, mais comme elle colle avec la tienne tu ne t'en rend tout simplement pas compte.-
[+] [^]Non
Posté par Arthur Accroc () le 22/07/2007 à 02:55. (lien). Évalué à -1.Tous les langages imposent leur façon de penser.
Mettons que je t'accorde qu'un langage fait forcément des choix pour ses grandes orientations : principalement impératif ou purement fonctionnel (sans parler d'autres principes comme le moteur d'inférences de Prolog), à typage statique ou dynamique, verbeux ou concis,etc..
Au delà, je ne suis pas d'accord avec toi, parce qu'il y a au moins un contre exemple à tous les langages qui imposent la façon de penser de leur(s) auteur(s). Larry Wall a conçu Perl avec comme devise "There Is More Than One Way To Do It". Et comparé aux langages qui partagent les mêmes orientations principales, comme Ruby ou Python, il n'y a pas photo.
Si je veux utiliser des destructeurs, j'en ai. Si je préférais utiliser des fermetures à tout va comme l'absence de destructeurs l'impose en Ruby, je pourrais, ça marche, je l'ai fait une fois (une seule) où ça me semblait réellement approprié.
Si je veux une vérification rigoureuse que j'ai bien initialisé toutes les variables que j'utilise, c'est possible. Si je préfère qu'il m'initialise tout seul les variables auxquelles je fais référence, c'est possible aussi.
Je peux programmer en orienté objet (au moins, je dispoise du paradigme object complet, avec les destructeurs (pourvu que ça résiste au GC de la version 6)), mais si je préférais me cantonner à un style impératif, je pourrais aussi...
Alors je reprendrai ta phrase en disant que la plupart des langages imposent leur façon de penser. À part certains dont l'intérêt est justement une façon de penser profondément originale et particulièrement appropriée à certains types de problèmes, ce sont en général les langages que je n'aime pas.-
[^]Re: Non
Posté par Antoine () le 27/07/2007 à 13:13. (lien). Évalué à 2.Larry Wall a conçu Perl avec comme devise "There Is More Than One Way To Do It". Et comparé aux langages qui partagent les mêmes orientations principales, comme Ruby ou Python, il n'y a pas photo.
C'est vrai qu'il n'y a pas photo : Perl est une merde sans nom.-
[^]Re: Non
Posté par Arthur Accroc () le 30/07/2007 à 16:58. (lien). Évalué à 1.Tu me fais penser à une caractéristique que j'avais oubliée : les buses n'y comprennent rien.
Pour moi, c'est un avantage : je me vois déjà bien trop souvent obligé de travailler avec des buses (j'ai même un collègue dont le boulot consiste en bonne partie à faire du PHP, à qui j'ai dû expliquer comment faire un truc en PHP, alors que je ne connais pas le PHP), donc toute occasion de l'éviter est bonne à prendre.
-
-
-
-
-
-
-
[^]Re: Incompatibilités ?
Posté par Laurent J (page perso, ) le 19/07/2007 à 13:47. (lien). Évalué à 3.>je pense que PHP occupera de moins en moins de part de marché dans le futur, quand on voit tout les problèmes et les incohérences de ce "langage" ...
Moi ça fait des années que j'entends ça, et pourtant....-
[^]Re: Incompatibilités ?
Posté par astero () le 19/07/2007 à 14:57. (lien). Évalué à 2.A ce niveau là je pense que c'est les hébergeurs qui tiennent les rennes. Tant qu'il sera plus facile et moins cher d'héberger son site sous php il dominera le web.
Après faut quand même avouer que pour un dev qui ne soucie pas de ça (appli interne par exemple), php a de moins en moins d'arguments... surtout quand on regarde ce qui se fait à coté (ruby, python, .net pour ne citer qu'eux)-
[^]Re: Incompatibilités ?
Posté par Gniarf () le 19/07/2007 à 22:40. (lien). Évalué à 2.faudra quand même que niveau perfs certains s'améliorent un peu beaucoup...
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: Incompatibilités ?
Posté par astero () le 20/07/2007 à 03:43. (lien). Évalué à 2.Niveaux perfs ? qui s'en soucie ?
Peut être 1% des intéressés et encore !!
Mais c'est vrai que niveau perfs j'ai cru lire que les challengers (ruby et python par exemple) avaient quelques détails à revoir... mais c'est un autre troll :)-
[^]Re: Incompatibilités ?
Posté par vieuxshell () le 20/07/2007 à 11:37. (lien). Évalué à 1.
Niveaux perfs ? qui s'en soucie ?
Peut être 1% des intéressés et encore !!
Ben en fait tout ceux qui utilisent un langage pour développer une application (bien faire la différence entre écrire une applie et faire un script web).
-
[^]Re: Incompatibilités ?
Posté par baud123 (Jabber id, page perso, ) le 20/07/2007 à 11:47. (lien). Évalué à 3.Niveaux perfs ? qui s'en soucie ?
les hébergeurs aussi peut-être justement ? :D (en plus des mécanismes de sécurité disponibles).
cf. http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...)
php a beau être un trou de sécurité béant, il a les mécanismes autour (suphp, safe_mode) qui permettent de le déployer en protégeant a minima les données des autres utilisateurs, du système... ce que n'ont pas (encore ?) les autres.
Puis bon côté conso RAM/CPU, python, ruby et consors n'ont qu'à faire leurs preuves, c'est particulièrement important sur un hébergement mutualisé (balancez les benchmarks si vous avez).-
[^]Re: Incompatibilités ?
Posté par Antoine () le 27/07/2007 à 13:14. (lien). Évalué à 3.balancez les benchmarks si vous avez
http://shootout.alioth.debian.org/
-
[+] [^]Re: Incompatibilités ?
Posté par Antoine () le 27/07/2007 à 18:20. (lien). Évalué à -1.cf. http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...)
Ils sont rigolos les guignols de chez TuxFamily. Je cite :
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc).-
[^]Re: Incompatibilités ?
Posté par Sylvain Rochet (Jabber id, page perso, ) le 27/07/2007 à 21:05. (lien). Évalué à 3.Ils sont rigolos les guignols de chez TuxFamily. Je cite :
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc)
C'est toujours agréable ces gentils mots... mais bon passons
Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque (même sur des disques SCSI à 10K). Ce n'est pas vrai si le bytecode est stocké en mémoire en shared memory, mais pour cela en mutualisé il faut plusieurs giga de mémoire sur chaque serveur web, ou alors distribuer les sites sur les noeuds, mais ce n'est pas dans la philosophie de TuxFamily de brider un site sur un seul serveur web (service équivalent pour tout le monde, n'importe quand).-
[+] [^]Re: Incompatibilités ?
Posté par Antoine () le 27/07/2007 à 21:50. (lien). Évalué à -1.Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque
Ca ne change rien : soit le cache de bytecode sert à quelque chose et Python fait aussi bien en standard que PHP+eaccelerator, soit il ne sert à rien et ce n'est pas la peine de prétendre qu'eaccelerator rend PHP plus rapide.
Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
ou alors distribuer les sites sur les noeuds
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.-
[^]Re: Incompatibilités ?
Posté par Sylvain Rochet (Jabber id, page perso, ) le 28/07/2007 à 12:42. (lien). Évalué à 5.Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
C'est juste qu'il n'est pas a jour... d'ailleurs c'est un wiki tu peux te loguer puis le modifier et contribuer utilement !
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
Si le stockage n'est pas centralisé, cela complique la gestion. Deja l'architecture décentralisé est plus complexe, il faut donc plus de gens pour la gérer (et oui). Ensuite, il faut plus de matériel, car cela sous entend d'avoir du stockage sur chaque serveur web, et de le dupliquer (et j'imagine même pas comment gérer simplement le basculement d'une panne d'un serveur web sur un autre en cas de problème, les solutions libres ne sont vraiment pas encore au point, et TuxFamily n'utilise que du libre, par principe). Un problème final s'ajoute à cela, le cout, si tu as 10K Euros à nous donner pour qu'on mette cela en place, on les prend sans problème et on le met en place ! Et pour finir, actuellement on a très peu d'accès disque, on a déplacé la grosse consommation d'accès disque (aka les gros fichiers statiques, iso, ...) sur une 2ème architecture et on a énormement de cache sur le serveur NFS (et oui, payer plusieurs GB de mémoire une fois on peut se le permettre, 10x on peut pas).
Ah oui aussi, même si le service web est le plus consommateur, ca fait juste parti d'un des services qu'on fournit, ca complique légérement la décentralisation (sans oublier la gestion des quotas) :-)
Et pour la croissance on gère, aujourd'hui ça va, demain, on verra !, le problème n'est pas technique, il est de temps et d'argent ! :)
-
-
-
-
-
-
-
-
-
Quand ça marche, pourquoi changer ?
J'ai écrit sur commande pour pas cher une demi-douzaine de petites applis PHP dont les clients sont à priori contents puisque je n'en entends guère causer.
Une chose est certaine : je ne les ré-écrirai pas en PHP5 pour rien. Et je doute qu'on me le demande : la valeur ajoutée de la chose serait nulle pour le client.
-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par Victor STINNER (Jabber id, page perso, ) le 19/07/2007 à 17:44. (lien). Évalué à 1.« la valeur ajoutée de la chose serait nulle pour le client. »
Et les patchs de sécurité ? PHP4 finira pas ne plus du tout être mis à jour.
Je pense que la màj PHP4 => PHP5 fait chier tout le monde car tout le monde code comme un porc avec PHP4 et que ça marche plus avec PHP5 qui est un légèrement (*) plus strict.
En tout cas : http://maurus.net/work/php-sucks/
(*) On peut toujours écrire « $foo=null; echo $foo->bar[0]->foo["bar"]; » en PHP5. Ouf, on peut encore gruiiiiker comme des sagouins.-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par astero () le 20/07/2007 à 03:32. (lien). Évalué à 1.Et les patchs de sécurité ? PHP4 finira pas ne plus du tout être mis à jour.
Hmm... ça serait vraiment pas sympa de leur part ça !! en tout cas ils précisent bien que ce sera fait pour l'instant.
Et je suis d'accord avec le premier post, la valeur ajoutée est strictement nulle dans 99% des cas, alors pourquoi investir dans une mise à niveaux ? sachant qu'un dev coute quand même relativement cher !!
-
-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par PierreJ () le 20/07/2007 à 09:38. (lien). Évalué à 1."J'ai écrit sur commande pour pas cher une demi-douzaine de petites applis PHP dont les clients sont à priori contents puisque je n'en entends guère causer."
"Une chose est certaine : je ne les ré-écrirai pas en PHP5 pour rien. Et je doute qu'on me le demande : la valeur ajoutée de la chose serait nulle pour le client."
je me demande quelle ta valeur ajoute pour le client concernant PHP. Si tu prends 2.5 min pour lire les guides de migrations, tu te rendras compte qu'il n'est absolument pas necessaire de reecrire une applie... Dans le pire des cas, tu te retrouves avec un warning ou une notice.
-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par keke () le 20/07/2007 à 13:23. (lien). Évalué à 0.Dans tout les cas, les vrais programmeurs PHP font comme Chuck norris : ils ne lisent pas la doc, ils l'impriment et la mettent sous leur oreiller.
-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par zlnix () le 20/07/2007 à 22:22. (lien). Évalué à 1.Je reste convaincu que le langage (si celui-ci est dit de haut niveau) devrait guider le programmeur à ne pas faire (trop hmmf !) de boulettes de conception , mais force est de constater que PHP se limite au strict minimum,.
J’aime ce langage pour faire de petites choses, je voterais même pour qu’il soit utilisé plus souvent pour de l’administration système, petit automates etc... mais à faire de trop gros projets non !
Car l’implication suivante devrait être respectée
si gros projet -> grosse conception
Et encore une fois, force est de constater que le codeur PHP n’est pas un adepte de ces méthodes.
Ou plutôt l’on nous a fait croire que nous n'en avions plus (ou pas) besoin (re hmmmf) . Donc à mon humble avis, au lieu de pleurer sur ce que fait ( ou pas ) un langage il faudrait voir déjà ce que peut déjà faire le codeur ... c’est les codeurs qu’il faudrait migrer en mode projet :-)--
:-)-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par tcheuck () le 21/07/2007 à 17:18. (lien). Évalué à 1.Alors PHP n'est pas un bon langage pour créer un gros projet web par ce que les devs ne savent pas l'utiliser !?
Ca serait pas plutôt l'inverse ?-
[^]Re: Quand ça marche, pourquoi changer ?
Posté par Guillaume Rossignol () le 22/07/2007 à 11:29. (lien). Évalué à 2.il me semble que c'est bien le sens de : au lieu de pleurer sur ce que fait ( ou pas ) un langage il faudrait voir déjà ce que peut déjà faire le codeur ... c’est les codeurs qu’il faudrait migrer en mode projet :-)
.
Fondamentalement c'est la majorité des codeurs PHP qui ne savent pas écrire un projet et ils faudrait les passer en version projet (les codeurs)
-
-
-
Cette page a été générée par Templeet en 0.3573s (dont 0.0617 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.