Hi all,
Je commence à apprendre Perl et je suis vraiment "séduit" par le côté inhabituel de ce language (de cette langue plutôt, non ?). Je vous propose donc de m'aider à continuer mon apprentissage tout en sauvant le monde des abominables logiciels propriétaires... :)
Voici ce que je pense être assez instructif et intéressant pour la communauté.
Le protocole Jabber incarne le protocole ouvert pour la messagerie instantanée.
Ce protocole est prévu pour être extensible. De plus, la plupart des clients actuels fournissent des fonctionnalités de façon assez hétérogènes (notamment le transfert de fichier). Je propose donc ici la réalisation d'un client et d'un serveur Jabber (les briques de base sont déjà dispos sur le CPAN, reste le packaging). L'implémentation devra respecter l'extensibilité du protocole pour pouvoir être amené par la suite à évoluer vers une espèce de réseau P2P (plutôt friend2friend) pour l'échange de fichiers, ou autre. L'implémentation du client et du serveur se fera en Perl (bah ui, hein, sinon...). Le client devra fournir une interface suffisamment bien faite pour être utilisable en CLI et une surcouche graphique basé sur wxwidget pourra être enviseagée. Le premier niveau de fonctionnalités fourni par le client pourrait être : a) im b) transfert de fichier c) transport des avatars. Les aspects de sécurité devront être pris en compte (authentification, chiffrement). J'aimerai aussi pouvoir appliquer dans le processus de développement certaines idées du TAOUP (c'est zen, c'est beau). J'aimerai aussi que le code transpire la beauté (ce serait un proof of concept qu'on peut faire du beau Perl). A terme, cette implémentation pourrait éventuellement supporter le transport de flux video. Dans ce cas, la compatibilité avec iChat (Apple) devra être garantie.
Voilà j'espère que cette thématique vous inspirera autant que moi et n'hésitez pas à apporter vos suggestions, remarques, etc.
Cordialement,
Bruno.
bcarnazzi@jabber.fr
:wq
Forum Programmation.perl Qui m'aime me suive !!
10
oct.
2005
# Heu, perl ?
Posté par pierthi . Évalué à 1.
Il y a des trucs qui sont vraiment *mal* foutus dans perl :
- programmation multi-threadée : c'est de la bidouille infâme (à éviter autant que possible).
- accès à des bibliothèques externes (pas écrites en perl) : pour du code propre, tu peux réver.
- la programmation objet et les structures de données : ça fait un peu scotch et ficelle (passer par des tables de hachages pour les structures, les références pour les objets, ...)
- la machine virtuelle est lente à démarrer sous Windows.
Tout ces petits problèmes seraient résolus dans Perl 6 (quand il sortira). Pour la version 5.8, je n'ai jamais réussi à l'utiliser pour autre chose que des CGI.
[^] # Re: Heu, perl ?
Posté par brunoc . Évalué à 1.
Pour la partie multi-thread, le module Net::Server n'est-il pas censé encapsuler toute cette complexité ? De plus, je ne crois pas vraiment en la pertinance des threads en dehors des io dans ce type de projet (dans le TAOUP, les threads ne sont pas considérés comme une bonne pratique. Bon, ça vaut ce que ça vaut). J'ai assez peu d'info sur le deuxième point que tu abordes : peux-tu préciser ou comparer avec d'autres langages ? Pour ce qui est de la programmation objet, je ne suis pas un afficionado et je ne comptai pas trop verser dans ce style. Pour ce qui est de la VM sous Windows, c'est pas grave :)
Bon, celà dit, je crois que j'ai posté un peu vite... Pour la partie serveur, il y a jabberd ( http://jabberd.jabberstudio.org/(...) ) qui semble déjà faire ce que voudrai. Et je crois que tu as raison : c'est très ambitieux. Peut-être juste se limiter à un client au début.
Peux-tu me faire rapidement part de ton expérience dans la programmation Perl : ce qui t'as (dé)?plu ? Ne crois-tu pas que Perl soit aussi adapté pour le développement d'un serveur Jabber que OCaml pour un démon de p2p ? :) L'inesthétisme de Perl est-il inéluctable ? Pour ma part, je dirai qu'on peut parler un français littéraire, moderne, moyen-ageux, argotique, etc. N'en est-il pas de même pour Perl ?
[^] # Re: Heu, perl ?
Posté par Yves Agostini (site web personnel) . Évalué à 1.
voilà quelques idées pour faire autre chose que du CGI en perl
http://www.crium.univ-metz.fr/docs/devel/cleanperl/(...)
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 1.
- perlXS
- Inline::*
- swig+XS
2. la programmation multi thread
les threads lourds : fork()+exec() comme en C
les threads legers : POE ou iThreads selon le besoin
3. la POO en perl est de la POO classique mais faite en perl.
en C++, tu retrouve class/struct/union ... la seule extension par rapport au C est class
quand tu manipule un objet en java, tu manipule des references d'objets ( d'ou les constructeurs de copie ).
puis si tu regardes serieusement, python et perl on la meme grammaire objet.
4. la VM sous windows, sur ce point je n'ai pas fait de test je ne dirai rien.
5. Pour ce qui est de perl 6, une implementation est disponible au travers de Pugs.
PS : ne pas savoir autre chose que du CGI avec perl 5.8 n'est pas le signe d'une grande maitrise de perl. essaie au moins mod_perl, tu y gagneras en perf.
[^] # Re: Heu, perl ?
Posté par pierthi . Évalué à 2.
2. threads lourds (on dit aussi processus) : marche pas sous Windows.
iThreads : trop de bidouille à mon gout.
POE : l'artillerie lourde. Pour le coté léger, on repassera.
3. La POO en perl est de la POO classique mais faite en perl.
Ah ben personne ne l'aurais deviné. Tu veux aussi expliquer comment on affecte des variables ou qu'est qu'un langage de programmation ?
5. Ouais bien sûr, mais une version de production, et un minimum testée sous Unix (et Windows, ben ouais, on n'a pas forcément le choix). Parce que bon une version alpha, quasi indisponible sur toutes les distros, ça va être super pour le déploiement.
> PS : ne pas savoir autre chose que du CGI avec perl 5.8 n'est pas le signe d'une
> grande maitrise de perl. essaie au moins mod_perl, tu y gagneras en perf.
Ben alors qu'est qui va pas ? T'as une mauvaise journée ? Rhôo, j'ai même dit le quart du huitième de ce que j'ai fait sous perl, et paf t'as réussi à déduire ça. T'es fort toi.
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 2.
En plus clair : l'implementation de la POO en perl est plus que correct bien que deroutante et est suffisament intégré pour pouvoir etre mixé avec du non-objet sans soucis.
5. c'est clair que si tu n'as pas le choix, tu n'as pas le choix et personne ne pourra rien pour toi. il n'empeche que Pugs existe.
pour le PS, dire que tu ne fais que du CGI avec la 5.8 et ayant rapporté un probleme de filtre de source dans Switch.pm en tapant sur perl ( qui n'y est pour rien sur ce coup ), ne m'a pas laissé présager grand chose d'autre que "il debute". si tu dis faire d'autres choses avec perl, c'est ta vie je te crois et je n'irai pas verifier.
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . Évalué à 2.
Elle est lourde car elle manque de sucre. Je parle de la construction d'objet avec « bless » explicite, et de l'obligation de passer l'instance comme premier paramètre des méthodes.
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 2.
>>>>def __init__(self):
>>>>>>>>self.data = []
>>>>def add(self, x):
>>>>>>>>self.data.append(x)
>>>>def addtwice(self, x):
>>>>>>>>self.add(x)
>>>>>>>>self.add(x)
ca c du python ( http://www.python.org/doc/2.4.2/tut/node11.html(...) ) et on y voit :
- le passage explicite de this.
- un truc qui aurait pu s'appeler package Bag;
Pour ce qui est de bless, l'enorme interet de cette instruction est de changer de classe un objet. J'utilise entre autre bless pour faire des fabriques d'objets et pour faire muter un objet ( genre des werewolf objects ;) ).
Dans les autres langages, muter sans cloner avec un constructeur prevu à cet effet est une galere sans nom. muter avec n'est pas mieux.
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . Évalué à 2.
Je parle de Perl. En réponse tu sors un des pires langages, je vois pas ce que ça prouve. On peut toujours trouver pire. En C aussi tu peux « faire de l'objet » mais c'est pire qu'en Perl, on est d'accord.
Pour ce qui est de bless, l'enorme interet de cette instruction est de changer de classe un objet. J'utilise entre autre bless pour faire des fabriques d'objets et pour faire muter un objet ( genre des werewolf objects ;) ).
Hum, a premiere vue ca me semble logique de devoir explicitement prévoir les changements de classe (après tout on prévoit explicitement les constructions, vu qu'un changement de classe c'est une construction partielle, ça me parait normal d'avoir un cas spécialisé pour ca). Donne-moi un exemple en Perl, ce sera peut-etre plus parlant.
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 3.
- parseur tolerant de type xml/html/sgml ou tous mes tokens sont blesée standalone, puis reclassé en open si un close est trouvé ( et resolution des fermetures necessaire pour l'obtenir ).
- interpreteur : une instruction "X" générique doit prendre un comportement contextuel connu a l'éxecution selon si l'instruction "Y" ou "Z" a été executé correctement, je change la classe du noeud dans mon arbre d'execution et donc change le comportement de mon noeud. le gros interet est pour choisir la bonne execution pour un noeud qui en a plusieurs possible mais seulement une executable.
- gestion de protocole : cas SMTP / ESMTP : tu as les rfc 821 / 2821, la difference se declare dans le EHLO ou HELO mais les commandes ne sont pas les memes ce qui fait que mon interpreteur doit pouvoir changer de mode si quand il est en 2821 il recoit du 821 ou le contraire.
je ne suis pas un adepte des IF et je comprend le propos de Dijkstra comme si le goto est harmful, et qu'il ne peut y avoir au plus qu'un goto inconditionnel utile, ce qui est harmful dans le goto c'est la condition sous jacente. a partir de là, le bless de perl a tous sont interet.
sinon, on est d'accord python est assez pauvre comme langage ...
"There is only one way to do it" ai je lu a son sujet, c'est comme si il n'y avait que le missionnaire comme position possible ou qu'une seule maniere de penser les chose. on retrouve la meme approche dans java.
d'un autre coté, on retrouve aussi cela à l'école avec 2+2=4, ou la racine carré de -1 n'existe pas, ou il n'y a qu'un infini, ... donc bon, il en faut pour tous les gouts c'est ce qui fait la richesse de l'humanite.
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . Évalué à 1.
ok mais du code ?
mais bizarrement, ce n'est pas parce qu'il n'y a qu'une seule solution que tout le monde va y arriver, cela part d'une sous evaluation colossale de l'imagination de l'etre humain.
Rappelle-toi aussi que du code Perl est plus difficile à maintenir que d'autres langages à cause justement du grand nombre de styles utilisés par les programmeurs Perl. C'est un problème.
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 2.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
j'avais ecrit ce post sur usenet a propos de perl ( effectivement cité sur wikipedia http://fr.wikipedia.org/wiki/Perl_%28langage%29(...) ) :
http://groups.google.fr/group/fr.comp.lang.perl/msg/f8e35176b2448bb(...)
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
package HA::Net::SMTP;
sub import {
my( $package, $RFC ) = @_;
# a finir
$RFC = "RFC2821" unless $RFC;
$RFC = "RCF$RFC" if $RFC =~ /^\d+$/;
$DEFAULTRFC = $RFC if $RFC =~ /^RFC\d+$/;
}
sub new {
my( $class, @args ) = @_;
$class .= "::$DEFAULTRFC"; #gloups risque ici si classe fille mal faite
$class->new( @args );
}
sub helo {
my( $this, @args ) = @_;
bless $this, __PACKAGE__."::RFC821";
$this->helo( @args );
}
sub ehlo {
my( $this, @args ) = @_;
bless $this, __PACKAGE__."::RFC2821";
$this->ehlo( @args );
}
package HA::Net::SMTP::RFC2821;
use strict;
use base qw( HA::Net::SMTP );
sub ehlo {
my( $this, $p ) = @_;
$this->sendline( "EHLO " . $p->( "domain" ) );
return $this->return_code_is( "250" );
}
package HA::Net::SMTP::RFC821;
use strict;
use base qw( HA::Net::SMTP );
sub helo {
my( $this, $param ) = @_;
$this->sendline( "HELO " . $param->( "domain" ) );
return $this->return_code_is( "250" );
}
[^] # Re: Heu, perl ?
Posté par gc (site web personnel) . Évalué à 1.
Pas d'accord. Perl est difficile à maintenir parce qu'il y a tellement de façons de faire quelque chose, que si toi tu lis du code que moi j'aurais écris avec mes habitudes et préférences, à tous les coups tu vas le trouver illisible. Et inversement bien sûr. Et si tu dois améliorer/changer mon code, tes changements seront illisibles pour moi.
La multiplicité des styles de programmation en Perl est sûrement un avantage pour l'écriture car les gens "trouvent" un style proche de leur approche et leur façon de faire, par contre c'est un inconvénient pour la maintenabilité du code dans une grande équipe (moi je bannis "unless" que je trouve illisible, ce genre de détail à la con).
Je ne vois pas d'ailleurs en quoi le fait qu'il ne faille pas l'aborder comme les autres langages solutionne quoi que ce soit au niveau de la maintenabilité du code.
pour donner un exemple, ecrire la doc d'une feuille d'impots est un exercice à plusieurs mains, il faut que cela soit le plus homogene possible sinon c'est inmaintenable.
Je ne vois pas trop le rapport :)
j'avais ecrit ce post sur usenet a propos de perl ( effectivement cité sur wikipedia http://fr.wikipedia.org/wiki/Perl_%28langage%29(...)(...) ) :
http://groups.google.fr/group/fr.comp.lang.perl/msg/f8e35176b2448bb(...)
Je ne vois pas du tout où tu veux en venir dans ce post. Je pense que tu n'illustres pas assez. Bon ton exemple avec l'enfant et le ballon est drôle. Ceci dit, Larry Wall est un linguiste à ma connaissance, donc je pense que tu creuses un point intéressant de son approche à son langage.
un extrait de code pour le SMTP genericisé ( commentaire d'origine ;) ) :
Si j'ai bien compris, tu construis un objet HA::Net::SMTP puis tu le précises dans les méthodes helo et ehlo. C'est effectivement un side-effect élégant de la syntaxe de création des objets en Perl, j'acquièsce vigoureusement. Maintenant, est-ce que l'intérêt est suffisant pour contrebalancer la ligne « bless » supplémentaire nécessaire pour tous les objets qui n'auront jamais besoin de cette fonctionalité ? Je n'en suis pas vraiment sûr. En plus, Perl pourrait suivre la convention de faire un bless implicite sur la valeur de retour de la fonction "new" avec le nom de package adéquat, si cette valeur n'est pas déjà un objet (ça a peut-être été écarté pour raisons de compatibilités avec les anciens programmes perl non objet utilisant la fonction new ? bon un tel problème n'a pas empêché d'ajouter l'appel implicite de DESTROY).
[^] # Re: Heu, perl ?
Posté par Mouns (site web personnel) . Évalué à 2.
dans la programmation classique, on instaure des coding-rules plus ou moins stupide qu'il faut changer regulierement car l'on se rend compte des soucis qu'ils produisent. au hasard, je cite la notation hongroise massivement utilisé par MS qui si l'on en a pas l'habitude est illisible.
le probleme de la maintenabilité de perl se situe à l'opposé de cela : perl se lisant à voix haute ( tu as rappelé que Larry Wall est linguiste ), ne peut se maintenir que si l'on se relis ...
... à voix haute
... comme pour faire de la poésie, savoir si ca sonne bien ( de toute facon, on sait qu'a la base l'interpreteur va se debrouiller pour l'interpreter plus ou moins comme on le souhaite ).
ton exemple de unless est tres bon, si tu n'as pas l'habitude, c'est clair que perl est hautement deroutant ( surtout si tu relis du code de personne qui font du C/Java&consort en perl )
do something() unless $my_case->is_empty();
do something() if ! $my_case->is_empty();
something() if ! $my_case->is_empty();
if ( ! $my_case->is_empty() ) {
something();
}
unless ( $my_case->is_empty() ) {
something();
}
Toutes ses propositions sont equivalentes. bizarrement, un non informaticien comprend la premiere. la seconde et la derniere sont limite.
mets en oeuvre mon conseil de lire le code a un beotien en programmation, et regarde si il comprend. je ne vais pas te rappeler que nous l'avons tous été, et que l'on a commencé avec des grandes phrases et des dessins. perl permet les grandes phrases.
Jouant avec la theorie des graphes les bases de données et perl depuis une dizaine d'années, je dois dire que perl m'a fait gagné enormement de temps pour coder et debugger du code. le seul equivalent est C mais il est trop couteux au niveau temps de developpement ( sauf pour des XS et Inline::* ) .
Pour ce qui est de mon bout de code, tu y es presque : si tu precise un HA::Net::SMTP tout court tu choisi celui par defaut, si tu choisi un rfc821 et que tu fais un ehlo() tu deviens rfc2821, et si tu fais un helo() en 2821 tu deviens rfc821 . bien entendu si tu forces un HA::Net::SMTP, et que tu fais un ehlo() et helo(), tu deviens la bonne classe.
ce que tu nommes un side effect n'en est pas un. j'utilise la meme chose en Java mais avec l'introspection ( lang.reflect.* ) et c'est ultra gore.
un autre grand interet est :
while ( my $packet = $socket->get_packet() ) {
next unless $packet->is_known();
$packet->handle();
}
ou get_packet() est un wrapper sur un constructeur de packet qui lui meme instancie une bonne classe fille ou reste un packet. packet::is_known retourne undef tandis que packet::*::is_known retourne @_.
apres, chaque packet::* a son propre handle() qui fait ce qu'il doit faire.
cela evite le :
while( my $packet = $socket->get_packet() ) {
if ( $packet->{type} eq "machin" ) {
# ...
} elsif ( $packet->{type} eq "bidule ) {
#...
} else {
}
}
une subtilité au niveau lisibilité non-informaticienne est :
$_->handle() while $_ = $socket->gives_packet();
ou sur le principe precedent :
while ( my $packet = $socket->get_packet() ) { $packet->handle() }
qui se lit on execute le handle sur le paquet en cours tant qu'il y en a un fourni par la socket ( avec un handle() par defaut à nop comme tu as pu le deviner ;) ).
[^] # Re: Heu, perl ?
Posté par brunoc . Évalué à 1.
Je suis contre l'appauvrissement des concepts à travers l'homogénéisation.
C'est aux gens de prendre les initiatives de ce qu'ils veulent dans la vie, en politique, en technique, en amour. Ca doit venir des boyaux. Pas du ciel.
Tchuss.
# Phénomène de dispersion
Posté par brunoc . Évalué à 1.
Ca tient la route, non ?
[^] # Re: Phénomène de dispersion
Posté par Mouns (site web personnel) . Évalué à 2.
perl a, à la différence des grands langages classiques, necessite une maitrise du sous entendu.
perl a cela de particulier est qu'il est lisible a voix haute. donc le truc que je donne pour savoir si ton code perl fait ce qu'il doit faire est dire à haute voix ton source à quelqu'un qui ne sait pas programmer en perl ( voire pas du tout ) et lui demander ce que cela fait.
si la personne comprend, il y a des chances que cela soit bon.
si la personne ne comprend rien, il y a toutes les chances que cela soit tres mal codé surtout si cela est quelque chose qui n'utilise aucune subtilité mathématique ou algorithmique inconnue de la personne.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.