Yann Kerhervé a écrit 188 commentaires

oui c'est plus compliqué aucun doute la dessus.
Cependant au niveau de la RAM consommée j'ai entendu tout et le contraire.
En effet de par mon expérience, en général les process sont gros (même si ca peut venir de mauvais choix d'implémentation) en plus on met en général beaucoup de process apache :)

Pourtant j'ai entendu à plusieurs reprises que mod_perl est plutot économe en ce sens que certains site switchent sous mod_perl pour éviter de faire des upgrade matériels

combien consomme linuxfr en RAM ?

je ne vois pas en quoi "php qui génère du xml" c'est une fusion. Ce n'est qu'une utilisation normale du XML.
maintenant, je n'oserais pas m'avancer autant sur le fait que php sera un "standard" loin de la.
Et au niveau des comparaisons de puissance, je pense que tout dépend de l'usage.
Je crois que les perfs mod_perl (et pas perl/cgi bien évidemment) sont supérieures à php

de ce que j'ai vu de php et de ce que je connais avec perl. JE ne vois pas pkoi perl serait plus délicat à interfacer à une bdd que php

http://www.cpan.org/modules/by-module/DBI(...)
perldoc DBI
perldoc Apache::DBI (mod_perl powa)

Personne n'a parlé de mod_perl jusqu'à présent. Pourtant c'est extrêment souple, flexible et performant. sa seule tare est peut-être d'etre moins accéssible, moins connu.
Mais le dev en mod_perl est un réel plaisir (et là on pose la main sur la carrosserie et on sent le moteur (Apache) qui ronronne en dessous... whaou :)

XML et php ne peuvent pas fusionne comme cela.
XML est un language à part, autonome et complet (et pas maintenu par n'importe qui).
Par contre ils peuvent très bien 'collaborés'. Mais c'est le cas de nombreux autres languages (notamment ceux qui sont skillés pour traiter du texte).
Moi ce que j'attends ce sont les petits modules comme AxKit de Matt seargant, qui permettent grace a des données XML et les feuilles de style associées de produire du HTML (ou autre format). D'ailleurs ca fait longtemps que j'ai pas regardé ou ça en est :]
je vais allez jeter un coup d'oeil :)

... raison. Je ne vois absolument pas comment php pourrait être le successeur du HTML. D'autant qu'on parle de sites dynamiques. S'il doit y'avoir un successeur au HTML, il faudra regarder du côté de XML. Et encore la révolution XML touche bien plus de domaines que le WEB.
PHP n'est pour moi qu'un autre language côté serveur, simple, efficace, rapide, plus ou moins puissant. Mais il y en aura d'autres et certainement des meilleurs.
Ce qui m'inquiete (plus ou moins) ce sont les environnements intégrés qui permettent de générer du code sans s'en rendre compte, qui font de l'intégration bdd, intégrent des plugins propriétaires etc .. Des choses que l'on ne controle pas bien. bref, vous l'avez compris du windows.
Et ce qui m'inquiète la dedans ce sont les dépendances côtés clients. Bref, le jour ou si on a pas explorer on n'arrive pas à accéder à toutes les infos.

pas spécialement, non, Mr Anonyme.
J'ai fait ca cet apres midi, et je viens de me rendre compte que j'ai gaffé qq part, j'ai qq substitutions qui sont pas passées

certainement que l'on peut faire ca avec sed, avec awk aussi.
Mais je ne connais pas plus que ca les mécanismes de ces deux programmes, car quand j'ai découvert Perl, il me suffisait et remplissait l'usage des deux autres programmes (attention ! MON usage, awk est peut etre plus puissant pour certains traitement et sed plus rapide)

<< Je ne suis pas sur que l'exemple choisi soit représentatif.Tu montre un exemple de Perl avec une simple expression de substitution. >>

c'était mon but : montrer a quel point perl peur *aussi* s'intégrer au shell unix. ma question était de savoir si python faisait de même.
Je n'ai jamais dit que j'utilisais(moi ou les perlistes en général) perl pour faire de la substitution !

et que fais tu de l'interpolation des variables.
je ne vois pas le rapport avec l'ambiguité d'un langage, puisque par définition la définition d'un langage informatique est non ambigüe (je pense que la ct pour cherche la p'tite bête ?).

Et honnêtement, il faut vraiment très peu de pratique de perl pour faire la différence entre &,@ et $ qui rajoutent du *sens* aux objets et qui devraient permettrent de lever les ambiguité plutot que d'ajouter a la confusion.

Pour en revenir à Python, est-ce qu'il est aussi bien intégré que perl à unix ?
je viens de passer un peu de temps pour faire des changements dans pleins de fichiers, grace a perl je me limite à :

find . -name '*.cgi' -type f -print0 | xargs -0 perl -0777 -pi -e 's/(HTML::Template[^(]*\([^)]*)\)/$1,shared_cache=>1)/smg'

et la je ne veux pas rajouter du cryptique a perl (puisque ce sont des expressions régulières) mais montrer à quel point perl est facile à utiliser au quotidien pour des tâches administratives

allez note 10 du 'chameau':
"Pour certains "puristes" des langages, ces caractères étranges sont une raison d'arbhorrer Perl. cette raison est superficielle. Ces caractères procurent de nombreux avantages : les variables peuvent être interpolées dasn des chaines sans syntaxes supplémentaires. Les scripts Perl sont faciles à lire (pour ceux qui ont pris la peine d'apprendre Perl!) parce que les noms se distingues des verbes et que de nouveaux verbes peuvent ^etre ajoutés au langage sans abîmer d'autres scripts (nous vous avions dit que Perl était conçu pour évoluer). Et l'analogie n'a rien de frivole; il existe de nombreux précédents dans divers langages naturels qui requiérent des marqueurs de noms grammaticaux. enfin c'est notre avis !"

je souligne 'pour ceux qui ont pris la peine d'apprendre Perl'
et apprendre à distinguer $,@,(),{},[] c'est quand meme pas la mort. Et en cas de doutes les docs de référence lèvent très vite toute ambiguité

Je ne vois pas trop où dans Perl on a plusieurs définitions pour plusieurs mots. Le language ne prête pas du tout à confusion. Cependant "TMTOWTDI" (there's more than one way to do it). C'est à dire que pour réaliser une même chose on a plusieurs facon de faire. Et là je ne vois vraiment pas ou est le problème. Cela permet au developpeur d'adopter la solution à un problème qui lui semble la plus intuitive.

comme il est écrit dans le chameau "l'essentiel est que les choses simples doivent le rester et que les choses compliquées ne doivent pas rester impossible"

En ce qui concerne l'aspect cryptique de la syntaxe de perl, l'effort d'apprentissage est minime (bah oui, un minimum d'effort, comme pour tout)

Autre chose, que je n'ai pas encore vu ailleurs - sauf dans uen moindre mesure en java - en Perl il existe une communauté importante à fort caractère : les mongueurs. Ceux-ci sont caractérisés par le fait qu'ils prennent vraiment plaisir à utiliser Perl et à user à fond toutes les possibilités du language pour le *fun*.

rho ... merci quand même.
Sans avoir énormément d'expérience, j'ai pas dit qu'il y avait qu'une personne qui developpait TOUT. Cependant dés qu'il y a un crado dans l'équipe ca se voit tt de suite (cf. ma toute petite expérience, merci) et qd c une equipe de pro, regarde les sources de Apache, ca se passe de commentaire

j'en déduis que tu es qqun de pas très propre.
dans la plupart des languages, un programme reflète la qualité du développeur; c'est encore plus vrai en perl.