Discussion :

[Causa Sui]

Je suis pour le php, mais je vais me faire l'avocat du diable

PS : Il existe d'autres concurrents :
...
ASP
Cold FUsion
...

Cela dit ColdFusion semple mois effrayant (ainsi que ASP) pour PHP rien que par le fait qu'ils sont propriétaire (ColdFusion => Macromedia, ASP => MS) et que par la même il sont payant; la gratuité étant pour l'instant un argument de poid.
En plus je crois que les vertions futures de PHP feront taire les mauvaise langues (adèptes d'ASP??? ) qui disent que le PHP n'est pas un language trés "sérieux" (on dit même ca dans les livre sur le PHP, c pour dire). Je crois que ce language va vers une rationalisation et un accroissement des performances.

[Fëanor13]

Il y a un vrai concurent à PHP :

JSP at java sous toutes ses formes.
Celui ci possède à peut de chose près toutes les qualités de php : portabilité, facilité de rédaction, de l'objet (que php ne tardera pas à aquérir), la gratuité...

Mais java possède d'énormes avantages : contrairement à php il est également hors-web (même si c'est un peu lent) et surtout il peut s'utiliser avec JDO et EJB.

Celà signifie qu'un site web écrit en JSP peut être indépendant de la logique métier comme de la base de donnée.

L'un de vous à déjà essayé de passer de MySQL à une autre base de donnée? C laborieux au possible puisqu'il faut changer tous les appels à la base de données...


Pour ce qui est de l'objet, je fais bcp de C++ et je trouve que le choix des concepteurs de ce langage est assez judicieux : Il est possible de faire de l'objet mais ce n'est pas imposé, on fait ce que l'on veut (peut ? ). J'espère que PHP suivra cette idée dans le long terme, ce qui lui permettra de garder son image de langage facile d'approche.

Pour ce qui est du coté client, ce serait bien, mais irréalisable techniquement donc fo pas trop compter la dessus.
Deplus je rappellerai que certains navigateurs peuvent désactiver Javascript et Jscript (exemple : Konqueror)

Il reste un attout à PHP qui est lié au $ : la capacité de géré les noms de variables comme des chaines. Personnellement je ne m'en sert jamais mais faut croire que ça a son utilité

[naholyr]

Mais java possède d'énormes avantages : contrairement à php il est également hors-web (même si c'est un peu lent)

PHP aussi, et en plus c'est pas lent... de plus avec PHP-GTK il est possible de réaliser des applciations graphiques.

et surtout il peut s'utiliser avec JDO et EJB.

C'est une particularité de java. Mais si java ne peut pas utiliser les talents du php, PHP peut utiliser Java ! il n'y a qu'a ecrire la classe qui va utiliser JDO et les EJB, et l'utiliser avec $obj = new Java("MaClasse"); et le tour est joué.

Celà signifie qu'un site web écrit en JSP peut être indépendant de la logique métier comme de la base de donnée.

ca c'est une question de conception. Un site en jsp mal réalisé n'aura pas cette qualité, un site en php bien réalisé aura cette qualité. Ca n'a rien a voir avec le langage.

L'un de vous à déjà essayé de passer de MySQL à une autre base de donnée? C laborieux au possible puisqu'il faut changer tous les appels à la base de données...

la encore il suffit de travailler avec une surcouche. Que crois-tu en java, les appels a mysql ou a postgresql sont différents. Il y a une classe au-dessus, qui fait le tri a ta place, et qui permet de s'adapter a toute base. Ce genre de classe existe en php (et est tres facile a implémenter de toute facon).

Pour ce qui est de l'objet, je fais bcp de C++ et je trouve que le choix des concepteurs de ce langage est assez judicieux : Il est possible de faire de l'objet mais ce n'est pas imposé, on fait ce que l'on veut (peut ? ). J'espère que PHP suivra cette idée dans le long terme, ce qui lui permettra de garder son image de langage facile d'approche.

Entièrement d'accord. J'ai entendu plus haut quelqu'un dire que ce serait une erreur, mais je trouve qu'en effet, apporter le choix offre une grande flexibilité au langage.

Pour ce qui est du coté client, ce serait bien, mais irréalisable techniquement donc fo pas trop compter la dessus.

absolument pas ! il suffit que certaines portions de code soient traduites par l'interpréteur en portions de code Javascript. Ce fonctionnement est tres simple !

Deplus je rappellerai que certains navigateurs peuvent désactiver Javascript et Jscript (exemple : Konqueror)

c'est effectivement la que la bat blesse.

[Fëanor13]

Bon ben je crois que j'ai un certain mea culpa a faire:
Il est vrai que la plupard des reproches que j'ai fais sont contournables par une surclasse ou l'utilisation de Java
De plus il sûr que la capacité de php à se servir de java est un gros plus.

Mais je reste sceptique sur pas mal de points :
La possibilité de se servir de php pour une appli efficace et sa capacité à gérer une structure client/serveur autrement que via HTML et HTTP (je me documenterai là dessus)

L'intéret de ce servir de php et de java simultanément : quel est l'intéret de ce servir de php si de toute façon on gère une grosse partie du site ou de l'appli est en java.

La capacité de php a faire le boulot de EJB et de JDO de manière aussi séparée (sans se servir de java bien sur)

le coté client via javascript : cela dépend trop du client et de son navigateur. Entre les différentes versions de javascript, les versions microsoft de jscript et les navigateurs qui ne comprennent pas certaines fonctions alors qu'ils sont censé comprendre la version de javascript dont elles font parties (et je ne parle même pas de l'interprétation des styles)
-> comment faire une partie client ne soit pas prévue pour IE??

[naholyr]

La possibilité de se servir de php pour une appli efficace et sa capacité à gérer une structure client/serveur autrement que via HTML et HTTP (je me documenterai là dessus)

il y a les sockets qui ont l'air de donner des résultats intéressants, mais je ne m'y suis jamais vraiment intéresser.

L'intéret de ce servir de php et de java simultanément : quel est l'intéret de ce servir de php si de toute façon on gère une grosse partie du site ou de l'appli est en java.

évidemment je compare php et java, en disant simplement que si on fait un site en php, et que malheureusement on se rend compte que tel traitement ne peut vraiment etre fait qu'en java, ce n'est pas grave on a toujours la possibilité de le faire.

La capacité de php a faire le boulot de EJB et de JDO de manière aussi séparée (sans se servir de java bien sur)

ce n'est pas autant integré, mais une bonne pratique de la programmation donne d'aussi bons résultats.

le coté client via javascript : cela dépend trop du client et de son navigateur. Entre les différentes versions de javascript, les versions microsoft de jscript et les navigateurs qui ne comprennent pas certaines fonctions alors qu'ils sont censé comprendre la version de javascript dont elles font parties (et je ne parle même pas de l'interprétation des styles)
-> comment faire une partie client ne soit pas prévue pour IE??

C'est le gros problème inhérent à cette idée. Mais il me semble voir des choses de ce type sur ASP, peut-etre que comme c'est MS ils se basent sur IE...

[nawac]

Bon, j'ai répondu favorablement, mais je regrette déjà...

C'est vrai qu'un langage plutôt rapide (pour de l'interprété), open source, complet gagne facilement face à l'ASP (bouh, l'asp ! ! ! ).
Le Perl(CGI) est beaucoup plus obscur à programmer, mais est plus beaucoup rapide aussi. De plus, on peut programmer de manière complètement orientée objet, avec ce langage de l'âge de pierre ! ! ! ;-)

PHP sera pour moi le meilleur langage (attention, expression subjective !) lorsque la possibilité de programmer de manière objet du début à la fin sera effective. L'absence de notions comme les attributs privés ou publics étant absente (ce n'est qu'un exemple), pousse à la programmation limite spagetti (j'exagère peut-être un peu, quoique...).

Pour l'instant, un bon langage est le JSP, basé sur JAVA bien sûr, mais il reste assez lent et doit s'exécuter sur un serveur spécial (websphere ou autre, il y en a des gratuits).

Une dernière solution, pour les développeurs puristes, pourrait être de faire un CGI à partir d'un code source compilé en C/C++, et là 'tention les perfs ! Mais 'tention les failles de sécurité du même coup.

[iubito]

c prévu pour la version 5, regarde sur http://www.developpez.com y'a un lien pour voir ce que nous réserve PHP5, fabuleux, on dirait du JSP mais écrit en PHP

[Fëanor13]

Perl C rapide : oui et non.

Pour une éxécution seule C plus rapide, vrai.
Cependant, Perl ne propose pas les mêmes capacités multithread que des languages comme JSP ou (je crois) PHP. Cela signifie qu'il y aura une belle file d'attente derrière un site perl très visité et peu peu touffu

Donc rapide : non

[dclink]

PHP a un bon avenir, il est vrai que la future version 5 propose enfin une POO digne de java/C++.
Cependant, j'aimerai, contrairement à certains, que cela ne devienne pas une obligation de programmer en tout OO, parfois il est plus pertinent de programmer en procédural, il ne faut pas faire de l'OO pour faire de l'OO qd même ...
Aussi, l'ASP.net est intéressant même si ils n'ont pas inventé l'eau chaude (ils ont bcp pris de bonnes idées chez les autres), j'attends de voir sa maturation...

[Fëanor13]

euh... php5 digne du C++???

Je suis pas sur du tout. Malgré cette grande évolution très espérée (par moi aussi), je suis septique sur le niveau objet de php5.

polymorphisme, programmation générique ???
je ne pense vraiment pas que le php est proche du niveau du C++

Une question se pose dans mon esprit : n'aurait-il pas été plus simple de faire de php une bibliothèque du C++ ???

[dclink]

J'ai pas dit qu'on pouvait faire des applis php comme en c++ attention sur la méprise, je parlais du style de programmation avec des mots-clés qu'on retrouve...

[shrom]

Je suis du même avis que hachesse : PHP est sans concurents (à part ASP bien sûr mais n'est-ce pas une injure pour PHP que de le comparer à ASP?).

Moi, je lui voit deux concurrents de taille:
- JSP et l'infrastructure J2EE (à réserver aux gros sites)
- Python avec la multitude de serveurs applicatifs pour le web qui existent (Zope, WebWare ...)

Je trouve qu'il manque encore à PHP le concept de serveur applicatif (fourniture de services, persistance des objets ...)

[sweet_smoke]

ha!! enfin, je desesperais de voir quelqu'un parler de zope!

ben je pense que les solutions zope style Plone et CPS on un belle et grand avenirs devant elles.

zope suffit d'y gouter pour l'adopter. enfin bon, moi depuis, je fais (presque) plus de php :-)

a mon avis de ce coté là y'a de la concurence, eme si c pas demain la veille que zope detronera php

[Causa Sui]

a mon avis de ce coté là y'a de la concurence, eme si c pas demain la veille que zope detronera php

Je ne crois pas non plus, vu l'implantation qu'a déja PHP grace aux 60%
(?) de serveurs mondiaux qui tournent avec Apache (a qui s'associe assez vite PHP).

[dante2002]

PHP est puissant, facile à apprendre pour faire des choes simples et permet aux plus expérimenté de faire des choes complexes...

Il a tout pour être l'avenir...

[Neuromancien2]

et perl, tcl, python ?????

[wello00]

PHP a de l'avenir bien sur mais faut pas croire qu'il sera le seul!!
Avec les applications J2EE il aura du mal à s'imposer même s'il est parfait pour les petites applis web

[Mister Nono]

Personnellement, je développe très souvent des applications (ou sites) web avec Java 2EE, certe plus complexes mais avec des possiblités accrues (language 100% objet, fortement typé...).

En fait, quand je développe en php : c'est à cause du fait que les fournisseurs d'accès proposent l'hébergement en PHP à des coûts bien inférieurs aux serveurs en Java 2EE.

Mais si cette contrainte n'existait pas, peut-être que PHP perdrait de la vitesse par rapport à JAVA 2EE.

A+

[berceker united]

Je ne pense pas. Un dev java coute plus chere. De plus, pourquoi faire compliqu" lorsqu'on peut faire simple. Pourquoi utiliser utiliser java pour une newsletter, forum, etc.

[Mister Nono]

Je ne pense pas. Un dev java coute plus chere. De plus, pourquoi faire compliqu" lorsqu'on peut faire simple. Pourquoi utiliser utiliser java pour une newsletter, forum, etc.

D'accord avec toi, mais bien souvent le petit devient grand et là on recommence tout en JAVA 2EE, ou un autre programme : autant faire évolutif dès le début.

Regardes le site IBM, de MICROSOFT, etc... Il ne sont pas en PHP.

A+