Sortie de PHP-GTK 1.0.1 – Blog de Maurice Svay

> pas de compilation

Donc pas de détection d’erreurs autrement qu’à l’exécution, ce qui permet d’être quasiment sûr que ça ne fonctionnera pas partout du premier coup.

En effet, ça semble génial cette technologie 😉

Non franchement, quand je vois déjà le mal qu’il faut se donner pour faire une application correcte en PHP, je vois d’ici les nuits de cauchemar pour une interface graphique… Allez, à quand un OS en PHP.

C’est vrai que ce point est très gênant. Faut être beaucoup plus attentif et tester intensivement chaque morceau de code.

C’est vrai que je me vois mal développer un gros truc avec ça, mais pour des petites applis à faire rapidement, ça peut être sympa.

Et pourtant de grosses applis tournent avec ! Il y a un client imap complet, teak.sourceforge.net/ et tout plein de bonheurs dans le genre… gtk.php.net/apps/ Il y a même une adaptation XUL pour phpgtk !
Ce n’est pas terrible pour programmer, mais pour des petits trucs, c’est intéressant. J’ai même pu compiler des applis en php-gtk à une époque, mais le site du soft qui fabrique le p-code n’existe plus… il faudrait que je retrouve dans mes archives…
hemzeni.poda.cz/phpgtk/co… http://www.nexen.net/news/gen.ph... ou anton.concord.ru/ftp/phpc… sont des miroirs. A noter qu’il utilise une version ancienne de php et que pour distribuer l’appli exe, il faut mettre le php4ts.dll et toute autre dll d’extension (et gtk) si nécessaire.

Ah on peut faire une version compilée !? Mais c’est génial !

Euh… Pourquoi utiliser du PHP alors, si ce n’est pas pour être portable ? Il existe de très bonne bibliothèque C++, Java ou C# pour faire des petits programmes graphiques rapidement.

Non franchement, je vois pas 😉

Anubis> me semble que c’est le meme probleme pour tous les langages de scripts…

Anubis: Là où ça va vite, c’est que je connais PHP mieux que C++ et Java (je ne connais pas C#): je n’ai pas utilisé ces deux derniers langages depuis un moment. Par contre j’envisage d’apprendre un autre langage de script genre Python, Perl ou Ruby, il parait que c’est assez sympathique.

> Donc pas de détection d’erreurs autrement qu’à
> l’exécution, ce qui permet d’être quasiment sûr que ça
> ne fonctionnera pas partout du premier coup.

En quoi une compilation permet d’être certain qu’une application fonctionne comme elle le devrai ???????
Une application peut très bien compilé et être bourré de bug algorithmique, de buffer overflow, j’en passe et des meilleurs.
La compilation transforme une code lisible par l’humain en code machine, en utilisant comme pont entre les deux une grammaire. Donc les seuls erreurs que detectent un compilateur sont les erreurs d’ecritures.

Et pourquoi utiliser PHP pour faire cela ?
1) Si tu connais rien d’autre, t’as pas besoin de perdre du temps à apprendre un autre langage
2) Si tu as besoin de faire un site applicatif et une application cliente qui dialogue tous les deux avec la même base de données, tu utilises un seul langage pour tout faire, ce qui facilite la maintenance et reduit les temps de développement (on utilise les mêmes API/objet pour tout le monde).

Quand à dire que l’on ne peut pas faire de grosses applications en php… Effectivement, pour celui qui n’a jamais fait de php, c’est difficilement faisable. Mais avec de bonnes connaissances du langage, une bonne methodologie et de l’experience, il n’y a absolument aucun problème.

Et tiens, c’est bizarre, ce que je viens de dire vaut pour tous les langages, qu’ils soient interprétés ou compilés.

Anubis, le duel compilé/interprété n’a aucun interet.
Chaque type, et même chaque langage à l’interieur de ces types, ont leurs forces et leurs faiblesses.

La VRAI force d’un developpeur, ce qui fait sa valeur, c’est de savoir utiliser le bon outil pour faire le boulot, donc dans notre cas le bon langage, celui qui lui permettra de faire rapidement un code optimum (pas optimisé, optimum, c’est à dire un code fiable qui est un bon compromis entre performance et facilité de maintenance).

Et pour faire cela, dans le domaine du web, PHP se place très bien, car il est relativement rapide, simple (donc facile à debuggué eet à maintenir), disponible en ligne de commande (CLI), sur le serveur via differentes interfaces (CGI/SAPI/etc) et en mode graphique client avec php/GTK. Ca permet de se concentrer sur un unique langage (en contrepartie, on devient hyperspécialisé), d’utiliser les mêmes methodes de developpement partout, les mêmes API, les mêmes objets, les mêmes environnement de développement, les mêmes outils connexes, d’avoir les mêmes possibilités d’évolution pour toutes les parties du projet et ca facilite donc le debuggage et la maintenance.

Conclusion : contrairement à ce qu’Anubis avance, on obtient une appication plus fiable.

Tout cela contrebalance les defauts de PHP4 (modele object pauvre, mecanisme de gestion d’erreur à chier, i18n, service xml), qui ont d’ailleurs une forte propention à disparaitre avec PHP5 (manque plus que l’I18n).

Il ne reste plus que le fait qu’il soit interprété (et encore, ca depend du point de vue), mais ca, le pauve n’y peut rien, c’est dans sa nature.

A+ FCH

FCH> me semble qu’il y a une extension gettext à php non? jamais utilisé (avec php) mais gettext c’est quand meme pas mal pour l’i18n

Effectivement, il y a une extension gettex.
Mais son utilisation suppose d’identifier la langue choisie par le visiteur via une variable d’environnement.
Donc si deux requetes sont gérés simultanement par un anglais et un chinois, la langue de l’un ecrasera l’autre.
Donc en fait, faut pas utilser l’extension gettext et faire sa soupe soi même (c’est d’ailleur dit qqpart dans les commentaires de la doc que le fonctionnement de cette extension doit être revu justement à cause de ce problème).

A+ FCH

ok, c’est dommage… parait que dans dotclear, le nouveau système d’i18n sera sympa, faudrait que je regarde ce que ca donne dans le svn

>Anubis, le duel compilé/interprété n’a aucun interet

Je ne fais pas ici un duel compilé/interprété, je dis juste que PHP, c’est pas un bon langage (et j’assume).

JavaScript est interprété et est un bon langage, il est facile à débugger, on ne peut pas utiliser les variables non déclarées, la notion de set/unset n’existe pas pour une variable, elle a toujours une valeur.

Pour PHP par contre, j’ai l’impression de revenir à l’antiquité informatique. Un debug printf, les variables non déclarées ne génèrent pas d’erreurs (vive les bugs fautes de frappe) et il faut toujours tester un isset pour accéder à une variable un peu externe… Enfin que du bonheur en boite pour un développeur.

Et encore je ne parle pas de la gestion de la mémoire étrange comme lorsque le parcours d’une chaine caractère par caractère est bien plus lent qu’un strpos ou un strreplace.

Non PHP n’est pas un langage utilisable dans une grande application.

Alors c’est vrai que PHP est pratique parce qu’il est gratuit et disponible chez tous les hébergeurs, mais au delà, je ne vois pas en quoi il supplante un Java ou un C# (si vous voulez rester dans l’interprété).

@FCH: Il est en effet très étrange de se reposer sur une var d’environnement pour la langue d’une application Web, mais le problème que tu cites n’est réel QUE pour un serveur web multi-thread. C’est à dire qu’il n’apparait ni sur un Apache 1.3 (ce qui représente déjà une grosse moitié des serveurs) ni pour un Apache 2.x en préfork (ce qui est le défaut sous Linux par exemple). Plus exactement le problème a des chances de surtout survenir sous MS Windows (ce qui ne représente pas beaucoup de serveurs, et encore moins si on ne considère que ceux sous PHP).

@Anubis: – PHP dispose de plusieurs debuggueurs tout à fait fonctionnels et complets, auxquels il ne manque rien. Activestate en a un (+ un opensource en préparation), Nusphère en a un, Zend en a un, il y en a un de Derrick en opensource (+ la nouvelle version en préparation à destination d’Activestate). Si tu utilises des debug à coup de printf ce n’est pas la faute du langage.

– Effectivement on déclare les variables, maintenant tu peux très bien demander à PHP de t’envoyer un message d’alerte à chaque fois que tu utilises une variable non initialisée, ça compense 90% du problème. La plupart des dev ne s’en servent malheureusement pas mais ça n’est pas la faute du langage.

– Quant au isset c’est comme dans toute application : dans les autres langages tu utilises des variables sans savoir si elles existent ? je ne pense pas. C’est pareil en PHP, si tu structures correctement ton appli et que tu *sais* qu’une variable existe tu n’as pas besoin de isset. Simplement PHP te fournit ici *en plus* une fonctionnalité permettant à ceux qui ne savent pas d’obtenir la réponse. Si tu le veux tu peux(devrais) continuer à programmer comme dans ton langage favori et éviter le "je ne connais pas mon code donc je vais tester". C’est une fonctionnalité supplémentaire, qui ne change rien à la prog si tu ne l’utilises pas.

– Le parcours caractère par caractère est plus lent que les fonctions built-in dans *tous* les langages de haut-niveau. Et même dans les langages de bas niveau, si ce n’est pas au moins identique c’est que ta librairie est mal foutue (ou que tu as trouvé l’algo révolutionnaire plus rapide que celui de la lib). Si tu utilises du caractère à caractère là où une fonction intégrée existe désolé mais c’est plutot toi qui est en tort (et c’est un peu dommage de faire ça sur un langage de haut niveau). Puis bon, c’est logique aussi, le strpos est fait en C en interne tandis que le caractère par caractère c’est du byte-code PHP. Ca n’a rien à voir avec la gestion de la mémoire.

Personnellement moi tu sais c’est plutot quand je vois du C que j’ai l’impression de revenir en arrière : on gère manuellement la mémoire (oups, j’ai oublié de désallouer), on peut faire des erreurs de pointeur ou de mémoire partout si on ne fait pas gaffe (et c’est vite délicat à débugguer), on est souvent obligé de faire du caractère par caractère ou de recoder des trucs simples par manque de fonction de base, les parties dynamiques comme les tableaux à taille variable …
Les memory leak, les violations d’accès mémoire et autres segfault-like .. tout ça ce sont des choses qu’on évite en utilisant un langage de haut-niveau et que malheureusement on retrouve dans presque toutes les applis en C. Dans un code PHP l’avantage c’est justement de pouvoir se focaliser sur l’algo et la structure, pas sur les détails d’implémentation. En général les quelques fautes de frappe et d’implémentation sont vites corrigées et les bugs restant sont généralement un manque de réflexion ou une mauvaise conception … pas un problème de codage.

Certes PHP n’est pas Le langage révolutionnaire (loin de là), certes ce n’est pas adapté à tout et n’importe quoi, certes ça sera plus lent que le C … mais bon … si tu veux disqualifier PHP il faudra te baser sur autre chose, ces arguments là ne sont pas très bons.
Des applis en python ou en PHP il y en a quelques unes .. qui marchent très bien. Il y a même un IDE PHP fait uniquement en PHP ( http://www.akbkhome.com/wiki.php... )

Je ne dis pas que PHP est adapté (il a des défauts à la pelle, comme tous), mais à mon avis tu devrais revoir les raisons qui te font tant écarter PHP. Là ça me semble beaucoup d’à priori et mauvaises connaissances (debug, isset, déclaration, …)

Eric : bravo pour l’argumentation, je n’aurais pas mieux dit. Si, une chose : le isset à pour vocation essentiel de tester l’existence de variable qui sont fournis par le client ($_GET et $_POST dans 90% des cas). Vu que le client est libre d’envoyer ce qu’il veut, il faut bien un mécanisme pour verifier l’existence des variables que le programme attend du client.

A+ FCH

Interessant tout ça moi je débute en php seulement mais peux t’on creer avec php gtk une appli pour gestion des stocks par exemple, ce qui est tout à fait possible en php4 d’ailleurs c’est même tout à fait indiqué pour ça si on veut l’utiliser en ligne.

Je vous ajoute une pierre dans le jardin de php-gtk. Cela fait 2 ans que je l’utilise en entreprise et c’est merveilleux.
Simple, facile à dépanner, portable : aucun problème !
Je crois que ce qui fait la grande force de php c’est sa simplicité. Php-gtk c’est trés simple. D’autant plus simple avec GUL, the " phpGtk User Language " dévellopé en moins de 15 jours.
Vive php !

I use Firefox in Ubuntu!

16 replies on “Sortie de PHP-GTK 1.0.1”