Discussion :

[kuranes]

J'ai l'impression qu'il y a une rivalité entre perl et python... Quelles choses peut on faire par rapport à Python ? (je ne crée pas un nouveau sujet là dessus, vu que ça reste un peu dans la même veine...)

[vodevil]

Moi perl c'est pour faire mon site web , automatiser certaines tache , faire des taches d'administration réseaux , et faire le ménage dans Windows (il sert a vider mes caches etc ...)

Et des délires

[Beetlejuice]

Perso :

Interaction avec MySQL (lecture écriture)
Interface avec GTK2-Perl pour faire diverses applications en mode graphique

[Katyucha]

Je l'utilise pour un seul usage :

Le parsing de fichier de log ou plus généralement le traitement de fichiers de log.

Parce que awk et sed .... Pouaaah

[vic]

A mon tour :

* Gestion de mes MP3
* Serveur de streaming audio
* Bots IRC
* Analyse de logs
* Moteur de recherche FTP
* Partie soft d'une station meteo
* Tout un tas de scripts divers que je pourrais faire en bash
* etc ...

[scaleo]

Tout

[placebomuse]

Bonsoir à tous !

Voilà je suis en deuxieme année de DUT Info et j'ai un projet à realiser en Perl. Le projet est libre donc je viens vous consulter pour me donner des idées ! Ce doit etre un projet tout de meme consequent puisqu'à realiser sur 4 mois (tout en suivant les cours ds le mm temps) mais qui reste de niveau DUT.

Le prof nous a donné qq idées : blog, wiki ou plugin pour Gimp.
Mais ca ne me tente pas trop.
En fait j'aimerai trouver qq chose qui fait appel au base de données et puis peut-etre qui puisse s'utiliser en réseau. (je ne veux pas faire un jeu !).

Voilà merci d'avance pour votre aide, à vos claviers !

[Invité]

Bonjour,

- CGI pour reporting et délégation de tâches systèmes
- data munging
- monitoring MS SQL Server
- centralisation et analyse de log avec ouverture de ticket d'incident de prod
- monitoring système NT
- gestion de comptes / droits NTFS

[pouet33]

Des scripts pour des traitements de données financières.
Le gros avantage c'est qu'il n'y pas besoin de recompiler à chaque modif

[Seb_de_lille]

Perso:

• Traitement de logs
• Surveillance de Webs
• diffusion de fichiers

[mhooreman]

• Supervision
• Facturation
• Archivage en base de donnees
• Gestion du développement
• Nettoyage des systèmes et bases de données
• ...
• Me brosser les dents le matin (enfin, je suis en train d'écrire le module)

[Besky]

Pour la bioinfo:
-recherche dans des bases de données
-modification des formats des séquences ADN
mais surtout:
-pipeline (prendre des séquences les balancer dans un logiciel, recherché des données dans le output du premier pour pouvoir le lancer dans un autre logiciel etc...)

et aussi au début pour dire bonjour...

[pepper18]

bonjour,

projet de stage : lire des fichiers xml, extraire les données, traiter les données, les injecter dans une base de données. ou dans le meme genre : lire des fichiers textes, extraire les données, traiter les données, afficher les données en html.

[Jedai]

Hum eh bien en fait...Disons que ... j'ai commencé avec Perl moi et il faut savoir que dans les cours d'initiation à l'info en linguisitique ou ce genre de filières, ils utilisent perl pour le meilleur et surtout...pour le pire!!!
J'ai toujours trouvé que c'était un langage correct pour faire de quick'n dirty mais ça s'arrête là. Plus de 10 lignes de scripts et c'est immaintenable et illisible pour un autre que toi: il y a longtps que j'ai arrêté d'utiliser les regexps de perl par exemple. Pour mes recherches professionnelles, j'utilise Sed (eh oui!). Je le trouve plus rapide et surtout il est bien dans l'esprit unix de ne faire qu'une chose et de bien le faire.

Tu as une vision bien étriquée de Perl si tu peux le remplacer par Sed.... C'est parfaitement incomparable et pour faire les même choses, la version Perl est nettement plus lisible (je ne parle pas ici des unilignes où l'on se contente de faire une recherche ou un remplacement sans calcul, utiliser Perl dans ce cas est une aberration).
Il y a de grosses applications écrites en Perl et qui continuent à être maintenues. Il est vrai qu'on peut écrire du code horrible en Perl plus facilement que dans certains autres langages (quoique PHP...) mais ce n'est pas une fatalité, et avec très peu d'effort on obtient un code parfaitement lisible et maintenable, c'est une question de bonnes pratiques. Le langage en lui même est très expressif et dispose d'un très large choix de librairies sur le CPAN.

Tu te plains des regexps de Perl, mais tous les langages ont copié sur Perl pour leur bibliothèques de regexps (et ont inventé très peu de nouveautés)... Plains-toi des regexps si tu veux, mais dans ce cas ne crois pas que Perl soit un cas particulier.

(quant à ton 'Perl est à la mode'... je n'avais pas cette impression pour ma part : il y a bien moins de hype autour de Perl que de Ruby ou même Python, sans parler de Java ou .NET. Je pense plutôt que tu voulais dire que Perl était mieux connu que Sed, non ?)

--
Jedaï

[Gnux]

Tu as une vision bien étriquée de Perl si tu peux le remplacer par Sed.... C'est parfaitement incomparable et pour faire les même choses, la version Perl est nettement plus lisible (
je ne parle pas ici des unilignes où l'on se contente de faire une recherche ou un remplacement sans calcul, utiliser Perl dans ce cas est une aberration).

Recherche/Remplacement sans calcul sont le fond de commerce de mon boulot. Et dans ce cadre je trouve sed plus "handy" que Perl.

Il y a de grosses applications écrites en Perl et qui continuent à être maintenues. Il est vrai qu'on peut écrire du code horrible en Perl plus facilement que dans certains autres langages (quoique PHP...) mais ce n'est pas une fatalité, et avec très peu d'effort on obtient un code parfaitement lisible et maintenable, c'est une question de bonnes pratiques. Le langage en lui même est très expressif et dispose d'un très large choix de librairies sur le CPAN.

Mais à quel cout? Qd je vois que urpmi, par exemple, doit être maintenu par un pumpkin pour voguer...

(quant à ton 'Perl est à la mode'... je n'avais pas cette impression pour ma part : il y a bien moins de hype autour de Perl que de Ruby ou même Python, sans parler de Java ou .NET. Je pense plutôt que tu voulais dire que Perl était mieux connu que Sed, non ?)

--
Jedaï

Effectivement

[Jedai]

Mais à quel cout? Qd je vois que urpmi, par exemple, doit être maintenu par un pumpkin pour voguer...

?? Mais Urpmi est un gros programme indispensable à Mandriva (et un assez bon gestionnaire de paquetage), en quoi est-ce donc choquant qu'une personne doivent le maintenir ? En quoi le fait qu'il soit écrit en un autre langage aurait-il évité cela ?

--
Jedaï

[Gnux]

?? Mais Urpmi est un gros programme indispensable à Mandriva (et un assez bon gestionnaire de paquetage), en quoi est-ce donc choquant qu'une personne doivent le maintenir ? En quoi le fait qu'il soit écrit en un autre langage aurait-il évité cela ?

--
Jedaï

Ce qui est choquant? C'est que c'est la seule personne qui peut le faire...

[pospos]

tu a appris le perl dans une optique quick and dirty, à la perl 4, mais ca ne veut pas dire pour autant que c'est la suele chose que perl soit capable de faire.
Une chose est sure: on peut mettre un mauvais programmeur sur du java et esperer en sortir qqchose d'utilisable (genre SSII) alors que c'est impossible en perl. Pour bien programmer en perl il faut savoir ce que l'on fait. C'est un langage qui offre plus de libertées, et donc forcement plus de possibilités de faire n'importequoi. Mais cette libertée apporte aussi une grande expressivité, et la possibilité de resoudre de nombreux problemes d'une maniere vraiment naturelle: on adapte le langage au probleme et non l'inverse.
Du bon code perl sera bien plus maintenable que du java, car plus court, plus concis, et plus concentré sur la logique metier.
Evidemment pour ca il faut quelqu'un qui sache coder en perl, et pas simplement un debutant qui crois que perl = CGI et qui ne sais pas ce que veut dire "use strict".
Donc oui perl 5 est tres efficace pour faire du quick and dirty et presque n'importe qui sachant faire un if peut coder ce genre de truc en perl. Tout comme n'importe qui peut conduire une ferrarie mais se crachera dans le mur à la premiere occasion.

En gros, le fait que tu fasse du quick and dirty ne veut pas dire que c'est tout ce que l'on soit capable de faire avec ce langage. Ne le reduit pas à ce que tu sais (ou crois savoir) en faire.

[Arioch]

Tout à fait d'accord avec Pospos

Il m'arrive de faire du code Perl jetable pour des besoins bien précis dont je sais qu'ils n'apparaîtront qu'une fois. Là, clair que mon code n'est ni commenté, ni joli à voir. Il est fonctionnel et fait ce que je lui demande, c'est le principal.

Et à côté, je fais de gros scripts à usage personnel ou professionnel et là, je fais en sorte d'être le plus clair possible et de commenter au maximum.

Le tout, c'est de ne pas rester sur le quick'n dirty. Oui, Perl sait très bien faire ce genre de code mais il sait tellement faire plus. Faut juste savoir s'y pencher un peu

[Lapince]

Je l'utilise essentiellement pour accéder à des bases Oracle sous forme de scripts lancés "manuellement" ou via des forms Oracle, pour enrichir des fichiers Excel ou csv.