Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
hors sujetmoi le midi je vais à la boulangerie acheter mon pain, et sinon je prendrai un truc tout fait à mettre au four.
si un médecin ou un boulanger veut un site web il chope un template ou va sur wordpress faut pas qu'il commence à coder.
si je commence à soigner des gens un médecin va pas forcément trouver ça correct
Y'a le pire mais aussi le meilleur chez PHP. Enfin, quand je dis "le meilleur", je veux dire qu'il est possible de faire les choses correctement en programmant avec PHP5. Et j'ai programmé avec d'autres langages, comme Java, Python et C.Envoyé par deadalnix
Keep it simple, stupid !
Oui, c'est une grosse partie du problème.
Par contre je ne dirai pas mauvais programmeur. Je pense que la plupart sont plein de bonnes volontés mais n'ont tout simplement pas les bases suffisantes pour être programmeur. Je pense que cela est plus dû à de l'ignorance qu'à de la bêtise. Pour avoir parcouru plusieurs forum PHP, je trouve même que le développeur PHP est bien plus curieux et moins feignant que pour d'autres langages :p Un développeur PHP qui entend POO ou MVC aura envie de savoir ce que ça signifie (enfin, c'est mon ressenti)
Une autre chose aussi, il y a plein de personnes qui critiquent le langage sans vraiment savoir ce dont il est capable. Et, c'est surtout ça que je condamne !
Mis à part ça, Tesing, +1 pour le pragmatismed'ailleurs je me considère souvent comme quelqu'un de pragmatique. Je ne fais pas des trucs beaux, je fais des trucs qui fonctionnent. Je dis ça parce que des fois au boulot j'ai l'impression de parler à des philosophes
PHP on peut difficilement faire pire niveau scaling...
La preuve Facebook est obligé de modifier completement PHP pour le faire fonctionner convenablement, et le principe de tout re-éxécuter a chaque requête est une perte de temps, donc non PHP ne scale pas...
et Oui java scale, la preuve, Twitter est en train de larguer Ruby on Rails pour passer sur du Java/Scala qui scale très bien
Il y a plus grave. Un langage compilé comme java peut détecter une foule de problèmes à la compilation, utilisation de variables non existantes, comparaisons de variables de type distincts, transtypage abusif etc...
Ces choses que les programmeurs PHP trouvent merveilleuses par rapport aux langages plus typés, mais qui sont du bricolage.
Les facilités offertes par PHP font qu'il y a trop de choses à mon goût qui peuvent être fausses mais fonctionner par bol. Et vous ne savez qu'un code est faux que si vous l'exécutez et que vous passez précisément sur la ligne criminelle. Donc si vous avez pas une couverture de test unitaire proche des 100% vous pouvez rien garantir. Vous ouvrez le code dans votre éditeur, vous faites une frappe malencontreuse, vous avez tout flingué et rien ne vous met en garde.
Pour avoir conçu les librairies d'utilisation de nos services en .Net, java, C++ et PHP (env 60 classes par langage), je dois dire que c'est de loin PHP qui me demande le plus de rigueur et de prudence. Côté maintenance, c'est aussi celle qui demande le plus de boulot car j'ai sans arrêt des clients qui constatent des comportements bizarres sur leur installation de PHP (style les références en 5.2 qui avaient pas le même effet qu'en 5.3).
Bref c'est le langage le plus facile en terme de programmation, et pourtant ça finit par être celui qui coûte le plus cher en maintenance.
PHP on peut difficilement faire pire niveau scaling...
La preuve Facebook est obligé de modifier completement PHP pour le faire fonctionner convenablement, et le principe de tout re-éxécuter a chaque requête est une perte de temps, donc non PHP ne scale pas...
et Oui java scale, la preuve, Twitter est en train de larguer Ruby on Rails pour passer sur du Java/Scala qui scale très bienun peut de lecturePHP scales. There, I said it. The word on the street is that "Java scales and PHP doesn't." The word on the street is wrong, and PHP needs someone to stand up and tell the truth: that it does scale.
http://onjava.com/pub/a/onjava/2003/...alability.html
Là tu confonds scaling et efficacité d'exécution et d'exploitation des ressources disponible par la la solution déployée.PHP on peut difficilement faire pire niveau scaling...
La preuve Facebook est obligé de modifier completement PHP pour le faire fonctionner convenablement, et le principe de tout re-éxécuter a chaque requête est une perte de temps, donc non PHP ne scale pas...
et Oui java scale, la preuve, Twitter est en train de larguer Ruby on Rails pour passer sur du Java/Scala qui scale très bien
L'efficacité d'exécution influe sur la taille du scaling à effectuer, pas sur la capacité de la solution à scaler.
Après plus la taille du scaling est grand, plus c'est compliqué à maintenir, plus ça coûte cher ect.
Maintenant tous sont scalable, le problème c'est plutôt le comment.
Et éventuellement comme dis plus haut, le comment c'est développé, mais bon c'est une affaire de développeurs d'application ça.
En java je ne connais pas, mais bon sachant qu'il faut déjà passer un certain nombre d'heure pour setup un environnement de dev...
installer un nouvel esclave doit relever
soit de l'exploit,
soit de la simplicité la plus parfaite.
<troll>
Mais bon pour ce que j'ai cotoyé de java je dirais que cela relève de l'exploit .. ou en tout cas d'une belle démonstration de ces connaissances des environnements web java.
</troll>
En php, tu déploies tes fichiers tu configures ta nouvelle instance pour utiliser les bonnes ressources, tu t'assures d'utiliser les bonnes versions de binaire sur la nouvelle machine, tu lances le serveur web, et plouf c'est fini.
c'est simple.
Par ailleurs, comment cela se passe en java, avez-vous une demo en lien ou quelque chose ?
@_skip, c'est certain que faire de la maintenance entre php5.2 et php5.3 est très couteux, ces deux versions réagissent très différemment, php5.3, est d'ailleurs, à mon avis, un raté.
Mais un raté qu'il fallait faire avaler à la communauté pour les frameworks, les investisseurs, ect.
C'est surtout une préversion de PHP6.
C'est bien pour commencer un nouveau développement, mais je ne vois pas pourquoi porter une appli PHP5.2 vers PHP5.3 .
Bah, quand tu es en SSII, l'important c'est de vendre des solutions. Si passer de PH5.2 à 5.3 peut te permettre d'avoir des contrats, ça peut le faire.
Regarde, dans ma boite, le service info facture des milliers de jours homme pour passer de php4 à php5 sur 5applis, ok, c'est pas vraiment la même évolution, mais quand même, quelqu'un de débrouillards et un peu vendeur pourra vendre une migration 5.2 vers 5.3 pour plusieurs milliers d'€ !
Rejoignez la communauté du chat et partagez vos connaissances ou vos questions avec nous
Mon Tutoriel pour apprendre les Agregations
Consultez mon Blog SQL destiné aux débutants
Pensez à FAQ SQL Server Ainsi qu'aux Cours et Tuto SQL Server
Un peu poussiéreux ce lien...
A mon humble avis, c'est un peu un non-sens de dire qu'un langage tient ou pas la montée en charge (ou scale, pour les anglicistes).
Je dirais que c'est une question qui se pose plutôt pour une solution applicative.
Pour moi ce post résume tout.
A savoir que le php est beaucoup trop permissif et n'oblige pas le programmeur a se documenter en terme de technique de programmation ou meme de methode de travail. Pour le programmeur qui n'a codé qu'en PHP il sera toujours plus dur de fournir du code propre PHP que celui qui a touché a des languages plus structurés comme le JAVA, le Python ...
Pour preuve regardez les framework PHP célebres en ce moment et vous verez que les créateurs de ses Framework ne sont pas que des codeurs PHP mais des gens avec un certain niveau dans d'autre language.
Le vrai problème de PHP ce sont les programeurs qui ne font que du PHP ou comme je les appelles les adeptes de bidouille (ou bidouillons).
Pour ma part tout ce qui est gros projet, je préfere éviter le php. En clair tout les projets ou la mise en place ou l'écriture d'une Framework PHP, s'avere nécessaire je préfere éviter de le faire en PHP.
La variation des performances lorsque la charge augmente c'est la montée en charge.
La scalabilité c'est la capacité qu'à un système à changer de taille. C'est-à-dire : comment peut-il être étendu pour absorber une charge plus importante, ou au contraire réduit lorsque la charge diminue.
Ça se mesure en terme de gain/coût.
C'est surtout une question d'architecture. Prenons un cas simple : Un serveur web.
Lorsque le serveur arrive à saturation, dans les grandes lignes il suffit d'ajouter un deuxième serveur en load balancing pour pouvoir absorber une charge double. Tu doubles les coûts, tu doubles la capacité.
A l'inverse, si on considère un SGBDR, il est très peu scalable : Une fois le serveur arrivé à saturation, tu ne peux pas en mettre un deuxième en load-balancing, qui attaquerait les mêmes données. La seule façon d'étendre le système, c'est étendre le serveur lui-même (disques plus performants, ajout de mémoire...) mais on est vite limité.
Si tu essaies de mettre un deuxième serveur, il faut également que tu mettes en place un mécanisme de réplication/synchronisation des bases, qui sera couteux et entraînera une dégradation des performances.
Au final, tu doubles les coûts et le gain est plus minime.
C'est pour ça qu'on voit apparaître les mouvances NoSQL avec des architectures distribuées qui renoncent à la sécurité et la fiabilité transactionnelle pour avoir un système scalable et donc pouvoir absorber de très fortes charges.
Maintenant la scalabilité peut aussi s'évaluer dans l'autre sens : Comment réduire le système si la charge est faible. Comment avoir une architecture capable de ne gérer qu'un seul utilisateur à moindre coût (cas de l'application monoposte) mais qui pourra ensuite être étendu pour gérer des miliers d'utilisateurs. Comment n'avoir qu'un demi ou un quart de serveur si on a juste quelques petits services à faire tourner ?
Scalabilité et montée en charge sont deux notions différentes.
Tu aurais un exemple de système qui ne scalle pas mais monte bien en charge ?
Un SGBDR est un très bon exemple.
Il monte très bien en charge, mais avec une mauvaise scalabilité.
Il monte en charge jusqu'à une certaine limite : celle d'une machine. Vient ensuite de sérieux problèmes de réplications.
Il me semble que c'est précisement ce qui vient d'être dit.
En Java c'est à peu près pareil... Tu installes ton serveur d'application, tu configures 2 ou 3 trucs, tu balances ton .war et c'est fini, après évidement ça dépend de comment l'application est codé.
VOILA !
En java si tu veux un truc scalable, faut en sorte que ça le soit. En PHP non.
voila ta reponse
aucune technologie en soi ne scalle, ni php ni java ni autre.
J'entrerais dans ce débat en vous collant ici juste une citation tiré de du livre PHP IN ACTION. Désolé pour ceux qui ne seraient pas à l'aise avec l'anglais. Je pense qu'il a tout dit.One thing I like about PHP is the attitude of the people who use it. PHP has always
been a pragmatic solution to real problems. It’s only natural that PHP programmers
tend to be pragmatic rather than dogmatic, humble and open rather than conceited
and pretentious. They like PHP, but they know that there is no perfect technology, no
perfect programming language. Everything has its pros and cons, its advantages and
disadvantages. PHP programmers tend not to start language wars. That’s fortunate;
often arrogance on behalf of a programming language—or any other software—is
based in ignorance. You know all the things your favorite language can do, and you
don’t know how to do the same things in other languages. It’s easy to assume that
these things can’t be done. But that’s rather like assuming that your car is the only one
in the universe that has air conditioning.
Finding faults with a programming language is easy. If it lacks a feature you desperately
feel you need, you can use that as a reason to put it down. If it has a feature
you think is totally unnecessary, you can frown upon that. PHP 4 had no visibility constraints
such as private methods; this of course was a Bad Thing to programmers who
were used to languages such as C++ and Java. PHP 5 has visibility constraints, and I'm
sure there are others—who are accustomed to other languages that lack these features—
who find this appalling.
The fact is you don’t know how a feature or the lack of it works in real life until
you’ve used it for a while. PHP has been criticized for having too many functions, in
contrast to Perl, which has fewer. I’ve used both languages extensively, and I happen
to prefer the way lots of functions are easily available in PHP. Someone else may feel
differently, but the most important point is that the difference is much less dramatic
than some people think. Language wars are too often fought over differences that may
have a marginal impact on overall productivity.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager