Discussion :

[clem_alain]

Bonjour,
Une curiosité, je travaille actuellement sur PHP après bien d'autres langages (COBOL, RPG, Pascal, C, C#, Java ...) et je me demande pourquoi il n'y a pas de compilateur PHP !
Est-ce consubstantiel au langage, une volonté délibérée, une impossibilité technique, un manque de savoir faire (là ce serait étonnant vu la richesse de ce langage) bref si quelqu'un pouvait éclairer ma lanterne )
Merci d'avance

[azertyman]

je me demande pourquoi il n'y a pas de compilateur PHP

parceque c'est un langage intéprété.

Est-ce consubstantiel au langage

oui

une volonté délibérée

oui

une impossibilité technique

dans quel but compileraient-on du php ? (vitesse ?)

[loka]

Le code etant interprété, il n'a aucun besoin de compilateur.

[leodi]

Et gagnerais t'on réèlement en rapidité ?

[alain31tl]

La rapidité n'est pas l'objectif en soi.
Mais, de pouvoir concevoir des exécutables, à partir d'un cd par exemple, entr'autre.
Et contrairement à ce que pense azertyman, nombreux pourtant se sont penchés sur son développement.
Le dernier à ma connaissance (phpcompiler) dont le projet semblerait abandonné.
Mais pourquoi pas dans le temps...(?), car c'est vrai, PHP is rich !

[chaced]

Et gagnerais t'on réèlement en rapidité ?

Car tu prends eaccelerator (ou truc du meme genre) qui fait donc du bytecode des pages, il y a un gain de vitesse allant de 2 à 10fois... Ce n'est nullement négligeable.

[Yogui]

Salut

As-tu pensé aux possibilités offertes par PHP::GTK ?

[clem_alain]

Bonjour,
L'aspect vitesse est en effet non négligeable mais de plus on pourrait diposer de :
- déclaration des variables (donc contrôle d'existance à la compilation),
- typage des variables,
- analyse syntaxique à la compilation et non à l'exécution,

A+

[Mr N.]

Juste pour jouer sur les mots, php est compilé avant son execution.

Quant à perdre le typage dynamique, je dis non merci !
Pour l'analyse syntaxique, utilise un vrai éditeur qui te donnera les erreurs de syntaxes lors de l'édition de ton fichier.

L'un des avantages aussi d'un langage interpreté est sa portabilité. Pas besoin de le compiler pour une machine ou pour une autre... Combien de développeurs développent leur tests au chaud chez eux sur windows et le mettent en production chez un hébergeur qui tourne sur *nix ?

[Yogui]

L'aspect "temps d'exécution du code", dans le contexte "exécutable sur CD" (voire même simplement "exécutable"), me semble absurde... Surtout si on prend en compte le temps d'accès au périphérique, assurément plus long que le temps d'exécution à partir de la RAM.

Verras-tu la différence entre une appli lancée en 1/100 de seconde et une autre lancée en 1/1000 de seconde ?

Dans le contexte Web, si le site en question a une grosse fréquentation (plusieurs centaines de visiteurs qui chargent des pages en même temps), alors le code précompilé a un intérêt. Dans tous les autres cas, c'est davantage une contrainte (le serveur doit disposer du logiciel pour exécuter le code compilé).

Exemple
Un client de ma boîte nous a appelés il y a quelques semaines en s'étonnant que le backend de son site ne fonctionne plus... Puisque je ne suis dans cette boîte depuis peu de temps, je ne connais pas leurs projets antérieurs. J'ai donc regardé le message affiché, il disait que le Zend Optimizer n'était pas installé :/
En gros, le client n'avait pas utilisé la partie administration de son site depuis plusieurs mois (rappelle-toi mon histoire de centaines d'utilisateurs simultanés) : précompiler le code avait-il réellement une utilité, dans ce cas ? Non, car la contrainte (installer l'optimiseur) était trop grosse, à tel point que le client était tout perdu.

[Kioob]

j'ai l'impression qu'on s'égare... mais je tenais à préciser un truc : Kirkis je suis globalement d'accord avec ce que tu dis, à un détail pres : ton exemple.

Si le "backend" nécessitait Zend Optimizer, c'est certainement parce que le code était encodé... histoire d'éviter que le "client" n'ait pas accès au code en question ; rien à voir avec les perfs.
Je précise que de toutes façons PHP pré-compile le code. Donc que ce soit réellement utile ou non comme tu le dis, n'y change rien, il le fait.
La seule chose que font ces "caches d'opcode" (apc, zend optimizer, eAccelerator, etc), c'est éviter la recompilation systématique du code en conservant en mémoire le résultat de cette compilation.

[Yogui]

éviter la recompilation systématique du code en conservant en mémoire le résultat de cette compilation

Oui, c'est justement là-dessus que l'on gagne du temps dans le cas d'une application PHP compilée (si tant est que l'on puisse en produire une).

Je ne crois pas que la digression soit très éloignée du sujet de départ. Je considère la discussion actuelle comme des arguments qu'il faudra ensuite peser pour déterminer si, oui ou non, la compilation préalable d'une appli PHP vaut le coup. Je ne parle pas de bytecode mais d'exécutable, i.e. binaire.

Je ne suis pas familier de Zend Optimizer mais je suis à peu près persuadé que mon prédécesseur dans la boîte, celui qui a développé l'application encodée dont j'ai parlé, n'avait pas la license de Zend Safeguard.
Cependant, tu as raison, je n'ai pas pris le meilleur exemple.
Pour me rattraper, je fais juste remarquer que cet encodage n'était pas nécessaire si on considère l'attention et la fréquence de mise à jour que le client en question accordait visiblement à son site. Finalement, la problématique est la même : compiler le code n'a ni accéléré le chargement des pages (visite du back end une fois tous les je ne sais combien de semaines) ni empêché le client d'accéder au code source (s'il a besoin d'une modif, il nous appellera de toute manière).


Histoire de ne pas trop faire hors sujet quand même : Alain, as-tu pris des renseignements sur PHP-GTK, comme je te l'ai proposé plus haut ?
C'est la solution que tu cherches, à cela près que l'application sera compilée à la volée (comme toujours).
De manière générale, tu peux utiliser PHP pour exécuter un script sans avoir de serveur Web.
PHP-GTK est simplement une bibliothèque permettant de créer une interface graphique.

[Kioob]

Pour me rattraper, je fais juste remarquer que cet encodage n'était pas nécessaire si on considère l'attention et la fréquence de mise à jour que le client en question accordait visiblement à son site. Finalement, la problématique est la même : compiler le code n'a ni accéléré le chargement des pages (visite du back end une fois tous les je ne sais combien de semaines) ni empêché le client d'accéder au code source

Justement, c'est là que j'ai l'impression que tu mélanges : il n'y a pas de gain de performances à utiliser la version "bytecode" de PHP.
Arrêtes moi si je me trompe, mais tu dis que le client a accès au code source... alors qu'à ma connaissance le seul cas où un code necessite Zend Optimizer, c'est justement lorsqu'il est "encodé"... Donc : le code était "encodé" ou non ?

(s'il a besoin d'une modif, il nous appellera de toute manière).

bah justement, tout l'interêt est là : si le code est "encodé", le client est obligé de passer par vous s'il veut la moindre modif dans l'appli. Prestation certainement facturée (ou du moins incluse dans un "forfait").



Et c'est justement là qu'une version compilée pourrait y gagner : la rapidité du programme (pas son démarrage hein) pourrait grandement être accrue... à condition que le programme en question ne se serve que peu des fonctions prédifinies de PHP (car elles sont déjà en C)...

Pour ce qui est de la portabilité pour une application "standalone", une version compilée ne serait évidement pas portable... Mais une version script ne l'est pas non plus : pour la faire tourner il faut installer sur la machine en question une "machine virtuelle" (le moteur zend).

[Yogui]

Ai-je laissé entendre que le client a accès au code source ? Si oui, j'en suis désolé, ce n'est pas le cas. Le code était bel et bien encodé avec l'optimiser de Zend. Le seul moyen pour le client d'avoir le code source est de faire appel à nous.

J'entendais par ma parenthèse (celle que tu as citée à part) que le client n'a certainement aucune envie d'avoir 50 prestataires de services. Il nous a, nous, donc il ne va pas faire appel à un autre tiers pour effectuer une modification du code existant (a priori, ça lui coûterait plus cher que de nous appeler, dans la mesure où nous sommes à l'origine de ce code).
Vu qu'il n'est pas lui-même développeur, il est obligé de passer par un prestataire de services pour faire la moindre modif de code.
À partir de là, je ne pense pas me tromper en affirmant que le client en question fera appel à nous s'il a besoin de modifier son code PHP, qu'il y ait accès ou non (pour cause d'encodage, par exemple).


Concenant la portabilité d'une application distribuée sur CD, je ne crois pas que de soit un problème ici, dans la mesure où un CD est de toute manière très rarement cross-platform.

[clem_alain]

Bonjour,
Tout d'abord je n'imaginais pas que ma question suscite un tel débat !
Kirkis, je suis allé faire un tour du côté de PHP::GTK, cela semble intéressant (merci pour l'info). Mais ma question était plus une question de fond qu'un réel problème à résoudre.
Je connais (malheureusement depuis trop longtemps) les langages interprétés (basic, gwbasic, asp ...) qu'est-ce qu'on a pu en baver avec les variables dynamiques et je peux vous dire que ceux qui ont connu ça apprécient de disposer de compilateurs.
Mais finalement la question n'est pas vraiment là, mais plutôt pourquoi n'existe-t-il pas de version compilée de PHP comme pour Java par exemple ?
Pourquoi ne pourrait-il pas exister une version interprétée, disons (sans condescendance) pour les "petits" sites et une version compilée pour les sites "professionnels" ?
Et encore merci à tous pour la qualité de l'échange, :-)
Alain

[djnos]

Salut à tous !

Je me permet d'intervenir par rapport à la volonté d'avoir un exe pour réaliser un autoexec sur CD. il est possible de mettre un autorun à la racine du CD, de spécifier le exe à lancer ainsi que des paramètres... Il ne faut pas oublier que PHP peut fonctionner en mode CLI. Il suffit de copier le rép de PHP complet compilé pour win32 sur le CD (ça mange pas plus de 20 MB), configurer le php.ini correctement et appeler php.exe depuis l'autorun avec en paramètre le chemin vers votre script PHP stocké lui aussi sur le CD.

Cela fonctionne, je l'ai déjà réalisé.


Plus

[Kioob]

À partir de là, je ne pense pas me tromper en affirmant que le client en question fera appel à nous s'il a besoin de modifier son code PHP, qu'il y ait accès ou non (pour cause d'encodage, par exemple).

C'est là que tu te trompes : certains clients préféreront toujours être "libres"...
J'ai assisté a pas mal de projets où justement la SSII à l'origine du code d'origine a été remplacée par une autre... Si le client n'a pas accès au code source, il y réfléchira à deux fois avant de le faire ; ce qui ne veut pas dire qu'il ne le fera pas.



clem_alain : commence par nous dire pourquoi d'après toi il faudrait un compilateur pour les sites "professionnels" ? Et surtout, qu'est ce que tu appelles "site professionnel" ?

[Yogui]

@clem_alain
Dans le cas d'une application écrite en Java, le bytecode est exécuté par la machine qui le demande et qui en a besoin.
Dans le cas d'une application écrite en PHP, le code source est compilé puis exécuté par la machine qui le demande et qui en a besoin.
Dans le cas d'un site écrit en PHP, le code source est compilé puis exécuté par le serveur, c'est-à-dire généralement par une machine différente de celle qui le demande (sauf dans le cas de CRON et assimilés).

Comme on peut le voir dans ce petit résumé, il y a une étape de "compilation" qui est ajoutée à chaque exécution, dans le cas de PHP. Pour y palier, nous pourrions par exemple utiliser une solution Zend pour compiler ce code à l'avance en bytecode PHP. Cependant, nous serions alors contraints à disposer de la solution Zend correspondante pour lire ce bytecode.
Je pense que cela répond à ta question : compiler PHP à l'avance à la manière de Java n'est pas impossible (cf. la discussion ci-dessus, qui n'est finalement pas aussi hors-sujet que cela). Ne crois pas que cela n'existe pas, ce serait une erreur.


@Kioob
En règle générale, je suis d'accord avec toi, le client aura certainement une préférence pour la SSII qui lui laisse le contrôle du code. Dans ce cas précis, cependant, je ne pense pas me tromper (mais c'est toujours possible).
Pour rappel, il y a quelques petites différences de mentalité entre l'Espagne et la France...

[clem_alain]

Bonjour,
Tout d'abord vous (le vous du pluriel) avez pu constater que j'ai pris certaines précautions de langage, j'ai mis "petits et professionnels" entre guillemets.
Par professionnels j'entends, sites ayant une finalité en laison directe avec une activité professionnelle (vente, gestion, administration, représentation... ) d'un organisme (entreprise, administration, association...).
Ce genre de site aux contraire des sites personnels engagent les organismes qui en sont les maîtres d'ouvrage et les conséquences d'une défaillance possible sont sans commune mesure avec celle d'un site personnel.
D'autre part je ne suis pas certain qu'un éditeur faisant de la complétude syntaxique puisse réellement se subsituer à un compilateur.
Ensuite j'en reviens à la notion de variables fortement typées (donc déclarées), une erreur de saisie peut parfaitement ne jamais être détectée, par exemple dans n'importe quel langage interprété :
$mavariale = 12;
$mavariabl = mavariabl + 3;
ne provoquera aucune erreur alors que dans un langage compilé si $mavariabl n'a pas été déclarée et en plus avec le bon type cela ne passera pas à la compilation.
Ceci dit en objet avec les références tardives, on est à la merci d'une classe non déployée, compilateur ou pas, mais c'est un autre problème !
Les problèmes de rapidité d'exécution sont souvent (pas systématiquement) de faux problèmes par contre ceux concernant la qualité et la maintenabilité sont le pain quotidien des développeurs et font de l'activité de développement une activité encore au stade de l'enfance, imaginez nos voitures, télévisions, ascenseurs ... de la même qualité que celle des applications développées actuellement !
L'absence de compilateur confine souvent PHP (me semble-t-il) aux yeux de beaucoup de "professionnels" au rang de langage de second ordre, alors que sa richesse fonctionnelle ne le situe pas vraiment si loin de ce qu'était Java ne serait-ce qu'il y a 3 ou 4 ans, du temps où J2EE n'était encore qu'une réalité de laboratoire (là je vais me faire flinguer par les buveurs de café ;-)).
A+
Alain

[Yogui]

D'autre part je ne suis pas certain qu'un éditeur faisant de la complétude syntaxique puisse réellement se subsituer à un compilateur.

:
Qui a parlé d'éditeur de code ?
Peut-être m'as-tu mal compris lorsque je parlais de Zend... Zend est ue entreprise, pas un éditeur. Certes, ils ont un (très bon, au passage) éditeur de code PHP mais ils ont d'autres logiciels. C'est ce que j'entendais pas "suite". L'un de ces logiciels est le compilateur que tu affectionnes tant.

Sais-tu qu'il est possible de demander à PHP d'afficher toutes les erreurs du code ? Sais-tu également qu'il existe des débogueurs de code PHP ?