Reprise du message précédent :
 

 
Joomla rox c'est bien connu  

   
 
Tout ce qu'il dit est vrai  (sauf que les mecs faisant simplement du montage HTML CSS peuvent toucher plus de 25k€ net/an si ils savent aussi faire du JS, et ça c'est sans faire de graphisme càd sans concevoir les pages/maquettes)

 
 
C'est pour ca que j'ai rajouté : " il y a des limites ".
 
Se retaper PEAR est certainement une perte de temps on est bien d'accord.  

Ouais mais pear c'est trop chiant à installer

sauf qu'il n'y en a pas, ou plutôt qu'elles varient pour chaque projet, donc non il n'y a pas de limites, il y a des contraintes et de la réflexion.
 
Accessoirement tu devrais relire ton argumentaire, parce que tu commences à te contredire.

Comme toujours, c'est une recherche de tradeof.
 
PEAR pour son site perso de 3 pages sur laquelle PHP est utilisé pour afficher une photo de chat différente sur chaque page c'est de l'over-kill, PEAR sur un site projet de 6 mois à 3 personnes ça tient plus du minimum.

On parle toujours de site pro là ?
 
Edit: 25K€ pour html et css == LE CHOC DU MOIS apres youtube

Bof bof bof... Vu le merdier qu'est PEAR

Bien sûr, la meilleure solution reste de ne pas utiliser PHP, mais on a pas toujours le choix hein

Attention, ne confond pas PHP et PEAR qui sont totalements séparés

Bah ca revient un peu au débat sur les templates et ci.  
 
Le choix d'utiliser PEAR DB devient intéressant pour les applications "portables" ! D'ailleurs ils le disent bien sur leurs site non ?? !
 
Enfin c'est que j'ai pu comprendre ...
 
 
Ensuite le caillou sur lequel je tombe a chaque fois que je regarde du coté d'une collection de script, c'est la quantité de code.
 
Enfin faites un wc sur PEAR ou smarty, puis lisez le code => De quoi ai-je réellement besoin  ?
 
5% 10 % 100% ?
 
Pour moi c'est plutot 0 % !
 
D'ailleurs le SQL tue mes benchmark : c'est décidé j'arrete
 
Edit: Café !

Nan mais PHP c'est de la daube, le but de PEAR c'est juste de rendre PHP un peu moins pourri

PEAR est codé en PHP non ?
 
++

Tes propos tombent dans l'hérésie avec une pointe de prosélitisme

Spa possible, php c'est trop de la merde, l'utiliser que sous la torture du client  

Il a pas tort non plus ...

.

star'ac moi ?
 
Bouuuuuh  
 
Je travaille en freelance, plus exactement pour personne. Avoir la pression d'un chef bourré au vin chaud j'aime pas trop ...
 
A la différence de toi je ne suis pas un designer HTML CSS ( mon dieu quelle insulte ! ). La mise en page est une formalité ...  
A la différence de toi je n'ai pas la prétention d'étaler mon salaire sur un forum public.
 
Je n'ai pas non plus la prétention de dire que je suis un pro.
 
A vrai dire je ne comprends STRICTEMENT rien à tes propos.
 

   
 
Ca ça m'a toujours fait marrer, sous prétexte qu'on se considère pro on serait de meilleur conseil/parole d'évangile qu'un amateur très averti    
 
Je comprends que ça puisse faire mal de dire qu'on est pro et de se rendre comtpe que ça apporte rien à part d'en vivre, et que d'autres qui se revendiquent pas pro soient peut être plus efficaces...
 
Enfin c'est pas le débat

C'est quoi le probleme de PHP, en quelques mots accessibles pour un noob?

Il y en a pas mal en fait
 

• Typage faible, donc PHP essaie de se débrouiller pour résoudre implicitement les opérations impliquant des types différents. C'est gentil, mais ça génère parfois (souvent) des comportements très bizarres, et ça rend le débugging ou la détection d'erreurs beaucoup plus compliqué
• Laisse passer beaucoup de choses bizarres et ne fournit pas de mode "strict" (à la Perl), donc le code est souvent crade
• Pas de namespaces, donc toutes les fonctions sont dans le namespace global et ont des noms à rallonge
• De même, pas de namespaces donc pas de notions de packages, modules, mixins, ...
• Aucune cohérence dans le nommage des fonctions standard
• Et douze zillions de fonctions quasi-identiques (besoin de deux choses quasiment identiques? Création de deux fonctions différentes au lieu de mettre un paramètre sur une fonction unique)
• C'est moche, le préfixe "$" ne sert à rien, la syntaxe est laide, ...
• Enormément de conneries dans l'API, et pas assez de fonctions dangereuses/stupides/inutiles dépréciées

En gros

Le PHP permet de faire de bons scripts, c'est tout ce qu'on lui demande point barre

Pas réellement non

Par réellement non plus, à part si pour toi la Wikipedia est un script

Apprendre par essai et erreurs, il y a pas mieux, surtout en programmation!

 
Je ne vois pas le rapport avec PHP

Sauf qu'en PHP tu passes plus de temps à chercher pourquoi ça merde que d'apprendre réellement. Si certaines bizarerries sont directement signalées dans certains langages, PHP lui s'amuse à arranger les choses de manière à satisfaire le débutant.

Fondamentalement, le laxisme de PHP ne serait pas gênant si seulement il existait l'équivalent du "use strict" de Perl. L'inférence de type n'est pas nécessairement une faiblesse en soi, c'est surtout que quand on veut serrer un peu les boulons l'interpréteur permet pas de le faire.
 
Encore qu'il y a eu du progrès dans ce sens avec PHP 5 et le type hinting, mais c'est pas encore tout à fait ça, puisqu'on ne peut pas imposer un type scalaire.
 
Après, ça n'empêche pas d'écrire de bons programmes, mais quand on délègue de la rigueur au programmeur, on prend des risques.

C'est parce qu'il n'y a pas de type scalaire au sens strict...

 
Hum, qu'est-ce que tu entends par "type scalaire au sens strict" ?

C'est à dire que PHP s'en fout si t'as une variable de type string, si elle se retrouve dans une addition, il va prendre tout ce qu'il y a de numérique au début de la string pour le convertir en int.
 
Aussi, t'as des fonction du type is_int(), mais qui parse la variable, alors que ça devrait juste tester le type...

 
J'aurais bien dit gettype(), sauf que:
 

 
Figure 1: teh mighty funney

Ni PHP ni Perl ne font de type inference, merci de ne pas confondre typage dynamique et inférence de type merci.

Ce qui n'a aucun rapport avec la notion de type scalaire, PHP a des types scalaires (et parler de "types scalaires au sens strict" n'a aucun sens, un type est scalaire ou pas point barre), ce qu'il n'a pas c'est un système de typage fort qui affirme les différences entre les différents types (y compris scalaires) et demande des conversions explicites de l'un à l'autre.

Ouais enfin si quand-même. Corrige moi si j'me trompe, mais quand je parle "au sens strict", c'est que PHP émule un peu ce genre de type. En php, le seul vrai type est zval. Après si c'est int ou string dépend du contexte

 
Je vais réviser mes classiques
Putain de job de merde que je suis en train d'y oublier les bases à bosser sur des progiciels de con.
 

 
J'ai pas encore tout perdu ça fait plaisir
 

Ben zval est un type scalaire et c'est tout  
 
Que ce soit le seul type scalaire de PHP ou pas n'a aucune importance, un scalaire est un conteneur ne pouvant comporter qu'une valeur à la fois par opposition à un composite pouvant en contenir plusieurs (array, record, list, map/hash, set, ...), ça va pas plus loin.

ptite question parait qu on peut faire des procedures stockees (ou un truc comme ca je suis encore etranger au concept) avec mysqli alors pourquoi utiliser pear  ?

Ok ! Je commence à mieux piger

 
Quel rapport entre PEAR et les procédures stockées ?
Enfin je veux dire, en quoi le support des proc stoc avec mysqli rend PEAR inutile ?

 
 
c est pas la meme chose ?