Au même moment, Stas Beckman le principal auteur de l'excellent guide mod_perl parle de notre capitale :
In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :(
on pourrait traduire :
à Paris on ne peut pas embaucher un seul développeur mod_perl, parce que les gens ne savent même pas ce que c'est. Ils en connaissent des tas sur php et ASP. C'est vrai ils ne savent même pas ce qu'est Perl :("
Cela rejoint les dernières discussions que l'on a eu sur mod_perl... Et vous ? Pourquoi utilisez vous php plutôt que mod_perl ? Connaissez vous Perl ? Quel est l'inconvénient d'utiliser Perl/mod_perl d'après vous ?
Aller plus loin
- le nouveau site (url provisoire) (11 clics)
- les archives de la discussion (2 clics)
- le Guide Mod_perl (13 clics)
- le site officiel mod_perl (6 clics)
- un peu de doc ca fait pa de mal (3 clics)
# allo
Posté par Anonyme . Évalué à -1.
# allo ?
Posté par Anonyme . Évalué à -1.
# Test
Posté par NoRSfall . Évalué à -1.
# Ils savent pas chercher, ou quoi ?
Posté par bmc . Évalué à 1.
Pourquoi je préfère Perl/mod_perl à PHP ? Je pense que c'est le fait de l'impressionante quantité de modules de qualités pour Perl disponibles actuellement. En deux temps trois mouvements, tu rajoutes une fonctionnalité : DBI (=> bases de données), CGI, mail, et je ne parle que des ultra-connus.
L'autre intérêt, c'est que Perl ne sert pas que dans un domaine particulier (cela peut d'ailleurs être un avantage comme un inconvénient), il peut "remplacer" l'utilisation de différents langages/outils : C, PHP, shell, sed/awk ...
# infos suppl :)
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
Ensuite, php est soutenu par des ISP comme Free (sont vraiment sympathiques dans cette boite ...) ca doit pas mal aider, notamment pour les personnes que je viens de citer juste au dessus.
Un point qui est soulevé dans la ML: la communauté php est bien mieux organisée pour la promotion (comparez phpbuilder.net ou php.net à perl.apache.org :) c'est pas la même chose.
A propos des mod_perlistes à Paris : y'en a :) mais à mon avis ils sont tous pas mal overbookés :p
A ce propos, je sais que c'est la crise de l'emploi en informatique en ce moment :) personne ne trouve de boulot, mais il en reste du côté de mod_perl :)) Viendez ! Bon, blague à part, y'a du boulot et c'est intéressant:)
[^] # Re: infos suppl :)
Posté par T Sang Neuf . Évalué à 1.
Du coup mes scripts ne sont pas du tout portable chez les ISP. Et pour remedier a cela je suis partie sur une autre base, PHP.
Ceci dit, ca ne doit pas etre dur de de passer de PHP a mod_perl.
Y a t'il des formations ou bien des tutorials en ligne bien faits ?
Y a t'il des ISP supportant mod_perl ?
[^] # Re: infos suppl :)
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
Mais tu peux toujours regarder les liens de la news (notamment le guide).
Au niveau des ISP, la question a été traitée par Stas dans un article récent de <a href="http://apachetoday.com/news_story.php3?ltsn=2000-11-27-001-01-OS-LF(...) Today</a>
également : <a href="http://perl.apache.org/isp.html">(...) le site officiel </a>
Après tout dépend de ce que tu veux faire en mod_perl! Une page perso, je te déconseille à moins que tu ne connaisses au moins perl, au mieux mod_perl. Mais si tu veux créer un site à la linuxfr ;-), à la /. alors oui !
Il y a d'ailleurs plein de sites qui tournent sous mod_perl (beaucoup sont cachés derrière des proxy donc netcraft ne les voit pas)
<a href="http://perl.apache.org/netcraft/">(...) ca fait un bon paquet qd meme</a>
<a href="http://perl.apache.org/sites.html">donne(...) un tout petit aperçu</a>
[^] # Re: infos suppl :)
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
vous corrigerez de vous même :(
[^] # s/.*href=
Posté par T Sang Neuf . Évalué à 1.
Apache Today : http://apachetoday.com/news_story.php3?ltsn=2000-11-27-001-01-OS-LF(...)
Le site officiel : http://perl.apache.org/isp.html(...)
ca fait un bon paquet qd meme : http://perl.apache.org/netcraft/(...)
un tout petit aperçu : http://perl.apache.org/sites.html(...)
merci. :)
[^] # Re: infos suppl :)
Posté par T Sang Neuf . Évalué à 1.
Dans mes cartons, j'ai un projet de fabriquer un cours d'initiation a la programmation dynamique. Ca s'adresse a des personnes qui maitrisent HTML, eventuellement les feuilles de styles, mais qui n'ont pas fait de programmation.
J'ai commence a travailler sur le sujet du cours et pour l'illustrer, j'ai cherche un langage. j'ai laisse tombe les CGI parce que PHP etait plus attirant pour mes etudiants (c'est plein de html).
En fait, du moment que les scripts sont petits et qu'on peut faire des trucs epatants (bdd, sessions, png, pdf, connection a d'autres serveurs avec des protocoles divers), le langage importe peu (sauf cobol!).
Et meme, s'il y en avait plus d'un, ce ne serait pas plus mal.
Mon probleme est plutot de trouver un ISP. Sourceforge n'a pas mod_perl :-(
[^] # Re: infos suppl :)
Posté par Anonyme . Évalué à 0.
langage importe peu (sauf cobol!).»
Oui, en effet programmer en PHP permet de faire des trucs épatants en peu de ligne et facilement. Mais lorsque tu veux faire un site costaud avec des composants réutilisables, multilingue... tu es obligé de passer par des templates, tu mets tout le code dans des classes ; on en revient à la même complexité que pour mod_perl, où il existe des classes pour gérer les templates, et en plus tu bénéficies de toute la dynamique autour du CPAN ( http://www.CPAN.org(...) ) !!
Le simplicité du PHP qui consiste à mettre du code de programmation à l'intérieur de pages HTML ne tient que pour des projets d'envergure modeste. On passe de toute façon à la même artillerie lourde quand il s'agit de sites complexes.
[^] # Re: infos suppl :)
Posté par Anonyme . Évalué à 0.
# PHP / mod_perl
Posté par Anonyme . Évalué à 0.
Sans blague.
Alors, pourquoi php plutôt que perl ?
Ma réponse est très simple:
quand je fais du perl, je "code" donc avec mes raccourcis de codeur (et en perl y a un sacrès potentiel) alors que en php, je fait d'abord de "l'html +++".
Vous voyez ce que j veux dire ?
y a qua regarder une page mod_perl et une php, l'une aura des paquets de <form><table><tr><th> etc. alors que en perl j saute direct sur monmachin->addtable(paf) etc.
Désolé pour l'exemple qui n'est clair que pour moi :o) héhéhéhé et pourtant il n'est pas si tard que ça !
Sinon, ben c une question classique, pourquoi le Zip se vends et pas la superdrive (ou chai plus quoi) ... pasque plus il y a d'utilisateurs et plus il y a de "machins" qui le pousse.
D'autre part, le PHP est accessible au plus grand nombre, alors que le perl pas trop (y a plein de manières de se perdre dans un tout petit script perl tellement y a de trucs sous entendus).
Voila qq arguments
# Logique ....
Posté par Anonyme . Évalué à 0.
Et si tous font à la place:
- PHP
- JSP
- ASP (euh si si ca existe encore !)
C'est aussi qu'il doit y avoir une raison ....
IMHO Perl à apporté une solution à des problemes de CGI à un certain temps .... mais aujourd'hui malgres la forte créativité de la comunauté, forcé de constaté qu'il ne posséde guere plus trop d'avantage decissif face à la concurence hypervitaminée.
RIP Perl :(
[^] # Re: Logique ....
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
Aujourd'hui un nouveau groupe de Perl Monger vient d'être crée en France, c'est celui de toulouse:
<a href="http://toulouse.pm.org">(...) toulouse.pm</a> (bientôt).
Je crois que c'est une affirmation un peu trop rapide. En plus tu ne parles apparemment de perl que comme un language orienté web (si on veut). Or perl est un outil standard unix ... tu peux essayer sur ta machine un
$ su -
# find / -name 'perl' -print0 | xargs -0 rm -f
et voir ce qu'il se passe, mais moi j'oserais pas...
[^] # Re: Logique ....
Posté par bmc . Évalué à 1.
et encore, je ne suis pas très avancé dans ce genre de choses, je soupçonne que l'on peut faire des choses bcp plus élaborées. Sans se prendre la tête évidemment.
[^] # Re: Logique ....
Posté par bmc . Évalué à 1.
[^] # Re: Logique ....
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
ce sont les sytèmes de template dont on parlait l'autre jours (Fabien disait que pour linuxfr ils utilisaient un système de template en php)
Le tout récent Template-Toolkit (ce papier est plutôt bon,)
http://www.template-toolkit.org/tpc4/paper.html(...)
Personnellement j'aime beaucoup HTML::Template : http://www.cpan.org/modules/by-module/HTML/HTML-Template-2.0.readme(...)
l'avantage du second sur le premier, amha, c'est qu'il n'y a VRAIMENT aucun code dans le html, c'est vraiment simple à capter, même pour un non informaticien. Alors que Template-Toolkit, me semble un poil plus compliqué
[^] # Re: Logique ....
Posté par Chamelle Kolabo . Évalué à 1.
Et pourquoi ne pas utiliser alors un serveur Objet comme Zope ou Jellybean .
La c'est plus marrant une URI devient un object
[^] # Re: Logique ....
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
Je n'ai pas vu ce qu'apportais le DTML sur un projet. En effet, est-ce que mon designer va devoir apprendre DTML ?
En plus au niveau des performances, je ne connais pas vraiment les chiffres exacts, mais j'ai l'intuition que Zope est moins performant qu'une solution mod_perl. Ce qui m'a plus avec Zope c'est le 'no-prise de tete', on lance install, start, et voilà. Après c'est très facile de rajouter un squishdot ou un Tracker, ca je trouve ca bien
# mod_perl moins répandu chez les ISP
Posté par Anonyme . Évalué à 0.
J'ai récemment développé un site en utilisant mod_perl, parce que j'aime la puissance de perl, surtout combiné si étroitement à apache, mais j'ai failli le regretter lorsque j'ai commencé à chercher un ISP. (g galéré pour trouver un truc pas trop cher, même avec même avec la liste sur perl.apache.org.) Si j'avais commencé par chercher un ISP, j'aurais probablement choisi PHP...
Après ça, on comprend que peu de monde choisissent mod_perl bien qu'il soit d'un usage plus large que PHP; c'est malheureusement pas plus compliqué que ça à mon avis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.