Au programme, correction de bugs, refonte de certains modules, et quelques fonctionnalités supplémentaires. La plus attendue étant l'ajout des caractères Unicode.
Pour ceux qui ne connaîtraient pas ce langage, il est simple à apprendre, lisible, objet (si on le désire programmé objet) et on peut très rapidement être fonctionnel avec.
PS : alors Fabien, quand est-ce que tu t'y mets ? :-)
Note de Fabien: Je m'y mettrai le jour ou Perl ne me suffira plus. C'est pas demain :)
Aller plus loin
- Site officiel Python (3 clics)
- Page de téléchargement (1 clic)
- Nouveautés de la 2.0 (1 clic)
- Site PythonLabs (1 clic)
# Fautes
Posté par Anonyme . Évalué à 0.
# Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Sauf que l'on oublie "lazyness, impatience and hubris" et les modules du CPAN, et l'extrême fléxibilités du language.
Mais quels sont les avantages à utiliser Python ? (ce n'est pas un appel a troll même si ca pourrait y ressembler, c'est juste que je ne connais pas Python)
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
j'en reste coi, suis IMMEDIATEMENT convaincu, et vais de ce pas m'acheter le o'reilly sur python (quoi, il est « jeu oct 19 00:22:51 CEST 2000 » ??? c'est ma vie, c'est à moi, ça m'amuse de te dire ça !!!!)
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
http://www.ioccc.org/(...)
Ca veut tout dire!
Franchement, Python incite à écrire des programmes un peu plus lisibles et réutilisables que Perl...
Et toi, quels sont tes arguments?
Aucun?
Ah bon.
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
dans la plupart des languages, un programme reflète la qualité du développeur; c'est encore plus vrai en perl.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
*La qualité originale du code
*La qualité du code après avoir un peu "vécu" (maintenance...)
Tu sais, j'ai vu du code assembleur très très propre dans ma carrière (propre avant les modifs de maintenance évolutive), mais ça n'empêche que je ne conseillerais à personne d'utiliser l'assembleur pour développer !
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
Fatalement, a un moment ou a un autre, il y en a au moins un qui fera un boulot de cochon (manque de temps, il ne connaissait pas ce langage, il est débutant, il débarque sur le projet, il a fallut intégrer le code avec un autre soft éminemment incompatible ....)
[^] # Re: Puisqu'on parle de perl...
Posté par Gaël . Évalué à 1.
Cette approche peut plaire ou intéresser; mais toute personne voulant qu'un outils ne serve à faire qu'une seule chose, et qu'il n'y ait qu'un seul outil par chose à faire, le tout bien étiqueté dans des petits compartiments bien rangés ne peut pas aimer Perl. A vous de voir si vous avez ce degrès de maniaquerie.
<Hors-sujet>N'empêche que je préferais quand les commentaires anonymes étaient désactivés</Hors-sujet>.
[^] # Re: Puisqu'on parle de perl...
Posté par mister popo ポポ (site web personnel) . Évalué à 1.
Perl necessite effectivement un feeling, c'est plus de la poesie qu'autre chose, et si tu le sens pas, c'est même pas la peine d'essayer.
[^] # ton site
Posté par Anonyme . Évalué à 1.
« Le logo à coté n'est pas là pour
embéter les utilisateurs Windoz, mais
juste pour rappeler qu'il existe une
alternative à Windoz (il y aussi BeOS,
Linux...). Ce site n'est pas spécifique
au Mac, il peut interresser tout le
monde.»
sans être redondant dans mon propos, Mac c'est proprio sur le logiciel et sur le matériel.. pas bandant
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
Il se trouve qu'on a pas mal de recul sur le développement et que pas mal de gens sont d'accord pour dire que l'approche un mot = une signification = un mot (en gros une seule façon de faire quelque chose et un seul sens pour chaque mot) est relativement efficace et permet d'écrire des programmes lisibles et faciles à maintenir.
Perl c'est justement tout le contraire, avec comme seul argument : Perl contre la dictature (je caricature, mais c'est un peu ça). Je trouve ça un peu léger.
Par contre, ça n'enlève rien au fait qu'on peut écrire rapidement des scripts très pratiques en Perl qui est donc un langage parfaitement adapté à son but, exactement comme Python, mais avec une autre philosophie.
Tout ça pour dire que l'argument de Wall est assez foireux à mon avis.
<Hors-sujet>
<<N'empêche que je préferais quand les commentaires anonymes étaient désactivés.>>
Totalement d'accord. </Hors-sujet>
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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*.
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
<<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) >>
Et bien ce n'est pas normal. Un langage de programmation c'est fait pour être clair et remplacer l'assembleur au niveau de la simplicité, de la clarté et de la puissance d'expression. Il est clair que perl est très puissant (on peut écrire en quelques symboles quelque chose qui demande plusieurs lignes de code dans un autre langage). Je pense que c'est au détriment de la clarté des programmes et de la simplicité de l'apprentissage. Encore une fois, c'est MON avis. On peut en discuter pendant des heures, ce n'est pas du domaine du rationnel.
[^] # Re: Puisqu'on parle de perl...
Posté par Henri Cault . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
Le commentaire doit indiquer *POURQUOI* un bout de code est là, pas *CE QUE FAIT* ce bout de code. Pour ça il suffit de lire le code... a moins qu'il ne soit illisible (!)
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
C'est totalement idiot comme remarque ! D'abord parcequ'il est à la fois utile de savoir d'un seul coup d'oeil ce que fait le code et pourquoi il le fait ainsi ! Et si tu lis du code aussi vite et aussi bien que du commentaire en francais, t'es un génie ! Vois-tu, ca m'étonnerait tres tres fort que tu y parviennes avec du C++, du Perl parfois, de l'assembleur, ou une bonne programmation système en C avec quantité d'appels à des procédures/fonctions systèmes pas toujours évidentes à lire & comprendre d'un simple coup d'oeil... En plus, le code peut être buggé, le commentaire rarement... Enfin, avec un langage bien verbeux, tu perdras beaucoup plus de temps à lire le code que le commentaire... Bref, a mon avis, tu viens de dire une belle connerie... Essaye la programmation, en particulier en entreprise, et on en reparlera !!!
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
Et *UNE LEULE FOIS* j'ai utilisé du PERL. Je ne suis pas con, je n'ai pas recommencé...
Un mec qui me dit qu'il va développer une application non-systeme en C, ben tout simplement je ne l'embauche pas ! Faut être completement crétin pôur ça (et je le dis après avoir pissé plus de 100 000 lignes de codes C sous Unix chez intergraph)
Quand au C++ c'est discutable. En tout cas c'est clair que qqun qui pretend connaitre le programmation objet parce qu'il connait (que) C++ je ne l'embauche pas non plus.
JAMAIS PLUS je n'utiliserais du PERL en entreprise ! Ca été la seule fois ou j'ai fais peter le budget... non pas pour le developpement, mais pour les années suivantes : maintenance corrective et évolutive.
PERL ca a des grod relent de basic microsoft :
10 Input "Entrez votre prénom ", $prn : ? "Bonjour ";:? $PRN:GOTO 10
La grosse connerie, tu viens de la dire : si t'es pas foutu de trouver un bug sans la doc qui t'esplique chaque ligne de code, c'est que faut tout mettre a la poubelle ! En entreprise ca coûte bcp moins cher.
"En plus, le code peut être buggé, le commentaire rarement." Ben qqun qui me sort ça, c'est clair que je ne l'embauche pas. Tu ne connais sans doute que MERISE voire UML. T'as probablemet jamais entendu parler de méthodes comme NIAM dont la première étape est *justement* de décomposer les phrases en élément syntaxiquement incomposables parce que *effectivement* les premiers bugs sont dans les phrases écrites en langages naturel (specs, cahier des charges, analyse détaillé, commentaires...)
Vous êtes médiocre, tout simplement.
H.Lefebvre
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
ni C, ni C++, ni Perl, on a pas entendu les argument contre jave ?
dois pas y a avoir grand monde dans ta boite ..
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
C++ est un erzatz de POO. Au départ ce n'était qu'un simple préprocesseur C.
Il y a suffisamment de monde dans ma boite, et en tout cas il n'est jamais arrivé que j'embauche qqun a qui on puisse reprocher quoique ce soit au niveau compétences techniques.
Il est évident que la connaissance du C, C++ ou Java est nécessaire. Mais ceux qui ne connaissent QUE ca, et qui ne jurent QUE par ca, j'en veux pas.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Wahou... de plus en plus fort ! Il est des fois ou tu as besoin de performances, ou encore d'un nombre suffisant de personnes maitrisant bien un langage permettant (plus ou moins aisement que d'autres, mais comme d'autres) de realiser une tache demandant pas mal de ressources par rapport a l'effectif de ta boite... Ca fait partie des criteres, et c'est pour cela, par exemple, que pas mal de boites realisent des script CGI en C, et ca n'a *rien* à voir avec de la programmation système... Tu te re-plantes !
>>> JAMAIS PLUS je n'utiliserais du PERL en entreprise ! Ca été la seule fois ou j'ai fais peter le budget... non pas pour le developpement, mais pour les années suivantes : maintenance corrective et évolutive.
Si tout le monde s'en sortait aussi mal que toi, plus personne n'utiliserait Perl... Or Perl est toujours utilisé, et pas uniquement pour des taches d'administration, et pas uniquement sous Unix... Donc, d'autres sont meilleurs que toi, et tu te re-re-plante...
>>> PERL ca a des grod relent de basic microsoft : 10 Input "Entrez votre prénom ", $prn : ? "Bonjour ";:? $PRN:GOTO 10
Placer sur le même plan Perl en le(s) Basic(s), tout ça en réalisant une ligne de code *tres vaguement* ressemblante à une ligne de code Perl, c'est bien de ton niveau : super efficace comme argumentation... On pourrait p't'etre faire de même avec C/C++/Java/Perl/PHP/etc...? non ? Bah, tu vois, tu te re-re-re-plante !
>>> si t'es pas foutu de trouver un bug sans la doc qui t'esplique chaque ligne de code, c'est que faut tout mettre a la poubelle !
En plus, il faut que t'apprenne à lire ! Et je parle pas de code source, mais seulement de francais... J'ai pas du tout écrit ca ! Simplement, les commentaires aident fortement à la compréhension du code, à la maintenance, et (autre remarque) il est bon de disposer d'un minimum de normes de programmation indiquant comment coder (sur la forme) : toujours pour la *lisibilité* du code, toujours pour faciliter le travaille de la personne qui passera derrière, qqs mois après, et ce même si c'est la même personne... Normalement, un developpeur SAIT tout cela d'EXPRIENCE !!! C'est sans le cas contraire que le code est à virer ! Tu te (re-){4}plantes !
>>> Tu ne connais sans doute que MERISE voire UML.
Perdu ! Je connais un peu MERISE, sans plus... En plus, considirer que qqun qui te parle de Perl comme un mec qui ne connaitrait que MERISE, c'est un peu curieux !!!
>>> les premiers bugs sont dans les phrases écrites en langages naturel
Bah c tout à fait normal... Les "specs" sont réalisés avant le codage, donc les premiers risques d'erreurs sont au niveau des specs, et par des sources... A moins que la fleche du temps ne soit inversées dans ta tete ???
>>> Vous êtes médiocre, tout simplement.
J'ai bien peur que le médiocre soit... Mr LEFEBVRE !
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
"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é
[^] # Re: Puisqu'on parle de perl...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
Pour utiliser un faux argument, je te dirais qu'il me semble quand même étrange que l'écrasante majorité des langages de programmation utilise des identificateurs sans symbole cryptique. Perl aurait donc raison contre le reste du monde ?
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
Il suffit de prévoir une séquence d'échappement (comme les {} de XSL), ça ne pose aucun problème. Tout dépend du cas général. Mais il est vrai que l'interpolation des variables de perl est assez agréable.
<<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>>
Justement. Le camel book utilise typiquement des arguments irrecevables (assez classique). Il procède de la façon suivante : "c'est vachement bien de metre @ $ etc. parce que ça fait la différence entre les verbes et les noms et qu'il existe des langues naturelles qui font ça." Donc, d'après les auteurs, l'analogie avec une langue naturelle est un argument valide pour justifier une construction d'un langage informatique. C'est du grand n'importe quoi, puisque justement un langage informatique est explicitement construit comme non ambigü, contrairement aux langues naturelles.
Comprenons nous bien. Je ne veux pas dire que perl fait les choses mal. Je veux juste dire que l'argument est foireux.
Pour le reste, je n'ai pas grand chose à te dire. Je pense que python est aussi bien intégré à unix que perl et je maintiens que le choix est essentiellement une question de goût.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
[^] # Re: Puisqu'on parle de perl...
Posté par T Sang Neuf . Évalué à 1.
d'après les auteurs, l'analogie avec une langue naturelle est un argument valide pour justifier une construction d'un langage informatique.
>>
Moi je trouve que c'est un argument valide, car ca aide a faire des programmes esthetiques.
c'est une des qualites que j'apprecie dans un source. j'aime bien regarder et ecrire ces constructions la, par exemple:
while (<>) {
last if /DATA/;
print unless /^#/;
...}
print "-" x 80;
print sort @montableau if @montableau;
($a,$b) = ($b,$a);
<<C'est du grand n'importe quoi, puisque justement un langage informatique est explicitement construit comme non ambigü, contrairement aux langues naturelles.
>>
Je pense que l'ambiguite n'est pas un probleme. Perl est un langage de programmation et n'est donc pas ambigu, simplement. mais c'est interessant d'avoir un langage de programmation analogue a un langage naturel, pour l'esthetique, pour l'apprentissage aussi.
[^] # Re: Puisqu'on parle de perl...
Posté par Ronan BARZIC . Évalué à 1.
La plupart du code Python que j'ai pu voir, ce sont des programmes complets, avec des fonctions, des modules, des gestions d'exception, etc...
Et là franchement, je trouve que Python, c'est le pied... et en tout cas, beaucoup plus clair que du code Perl pour quelqu'un qui à une expérience limitée dans les deux langages
PS : c'est moi qui est écrit le post disant combien la doc livrée avec Python était excellente. Désolé pour le post anonyme
[^] # J'ai encore gaffé
Posté par Ronan BARZIC . Évalué à 1.
Trops de Python la nuit dernière...
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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 !
[^] # Re: Puisqu'on parle de perl...
Posté par Ronan BARZIC . Évalué à 1.
A third way of starting the interpreter is "python -c command [arg] ...", which executes the statement(s) in command, analogous to the shell's -c option. Since
Python statements often contain spaces or other characters that are special to the shell, it is best to quote command in its entirety with double quotes.
Donc c'est possible
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Ca, c'est juste utiliser des expressions régulières. Est ce que tu ne peux pas faire ca avec sed? awk? vi(pour un seul fichier)? ...?
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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)
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Tu es fier?
[^] # Re: Puisqu'on parle de perl...
Posté par Yann Kerhervé (site web personnel) . Évalué à 1.
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
[^] # Re: Puisqu'on parle de perl...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Par contre, il devrait y avoir un système de modération (par tous les utilisateurs) qui permettrait d'envoyer un post vers /dev/nul lorsque plus de 90% (par exemple) des utilisateurs le modèrent vers le bas.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Celui-là a dit qu'il aimait KDE, je le modaire -10 parce que KDE SuX...
Tu fais bien trop confiance aux utilisateurs de Linuxfr!
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Ca fait longtemps que je n'ai plus fait de Perl, mais voila en bref pourquoi je reste avec Python:
- developpement tres rapide
- oriente-objet, programmation fonctionnel et autres trucs sympas
- globalement du code tres lisible (de par la syntaxe du langage
Enfin, 1 et 3, c'est vraiment ce qui ressort de mon experience en Python...
[^] # Re: Puisqu'on parle de perl...
Posté par Henri Cault . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
- la syntaxe, que je trouve plus "lisible" que Perl (pas de $_, @_, pour les noms de variable...)
- la doc livrée avec, un modèle du genre avec un tutorial excellent pour commencer rapidement
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
Tout à fait ! Contrairement à Perl, je trouve. Comme je ne trouvais pas mon bonheur dans les docs standard, j'ai acheté comme un con le Camel Book, que je trouve complètement nul : pas clair du tout (en particulier sur la sémantique bizarre de Perl), plein de blagues merdiques (je n'achète pas un bouquin d'info pour lire des blagues, merci), pas très bien organisé, etc.
[^] # Re: Puisqu'on parle de perl...
Posté par Poseidon_k . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par boubou (site web personnel) . Évalué à 1.
A titre personnel (ça n'engage que moi, ok ?), je pense qu'il est préférable de commencer par Python, car il y a eu un indéniable effort pédagogique par la communauté, contrairement à Perl (à mon avis, hein ?). Donc les documents d'introduction me semblent meilleurs. Comme les possibilités sont en gros les mêmes, il vaut mieux se tourner vers le langage le plus simple d'accès.
[^] # Re: Puisqu'on parle de perl...
Posté par Henri Cault . Évalué à 1.
Perl c'est super pour faire des filtres, des transformation de textes, des formatages de données,... vite fait bien fait, avec des expressions rationnelles. je l'utilise encore pour ça. Mais dès que tu veux faire de l'objet, des programmes complexes et structurés avec les prototypes de fonction clairs et détaillés, et utiliser des modules puissants et bien documentés, Python est génial, et évite bien des embrouilles (tant au niveau structures de données que fonctions).
Typiquement, en appli perso sur XML :
- perl pour l'extraction de données textuelles et la génération de rapports en XML
- python pour le parse et l'interprétation XML pour piloter des process, effectuer des transformations profondes ou des mises en pages, faire du réseau (client-serveur), ...
Moi je dis : quand on hésite, faut essayer les deux !
[^] # Re: Puisqu'on parle de perl...
Posté par Slowhand . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
[^] # Re: Puisqu'on parle de perl...
Posté par Franck Guillaud . Évalué à 1.
D'ailleurs, je le vend, si ça intéresse qq'un ;-)
[^] # Re: Puisqu'on parle de perl...
Posté par Matafan . Évalué à 1.
Pour ce qui est du ton, je l'ai trouvé très agréable (la traduction de Jean Zundel est d'ailleurs exellente).
La seule faiblesse que je lui trouve est la partie consacrée à l'approche objet, qui laisse le débutant un peu rêveur.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
J'aimerais acheter d'aussi bon bouquins plus souvent.
A eviter pour un debutant total toutefois, par contre si on a un petit bagage...
Python: semble plus clair, mais un peu moins "fun"
que perl (Ah les structures de donnees auto-generées par le programme appelant !)
[^] # Re: Puisqu'on parle de perl...
Posté par Henri Cault . Évalué à 1.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Autrement dit, le "code" depandait des "donnees"
Faire ca avec un programme compile ?
Non, je ne coucours pas pour le Obfuscated Perl Contest ! ( ni pour celui de l'explication la plus floue)
[^] # Re: Puisqu'on parle de perl...
Posté par Mokona . Évalué à 1.
Puis ensuite de manière générale dans tous les langages qui définissent les objets comme étant des objets (meta-objet) (ce qui n'est pas le cas du C++, mais cela peut se simuler).
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
A priori, je ferai ca en me reservant un petit coin de memoire, et en faisant de l'Arithmétique de pointeurs pour retrouver les champs, mais je trouve ca un peu dégueu...
[^] # Re: Puisqu'on parle de perl...
Posté par Mokona . Évalué à 1.
En C effectivement, je vois ça en simulant les objets. C'est bof, et c'est pas fait pour. Mais c'est faisable.
En C++, il suffit de créer une classe Objet qui décrit ce qu'est un objet. Après tout, un Objet en mémoire est un... objet. C'est bête à dire mais bon :)
(au cas où, explication : on peut imaginer un ensemble de classes (là je ne parle plus C++) qui héritent toutes d'une classe "Objet". Puis on peut tenter de définir cette classe "Objet" en termes de classe, nommée "Méta-Objet". On va vite s'appercevoir qu'il y a un bouclage : une méta-classe est une classe).
C++ n'a pas ce mécanisme intrinsèquement (void *, le père de tout le monde, ne fait pas grand chose), mais on peut créer une classe "Objet" facilement, avec ces "addMethod()", "addMember()".
Au niveau implémentation simple, on peut imaginer un vecteur d'associations entre des "string" et des "void *".
Maintenant, si on veut faire ça dans le cadre d'un petit script rapidement, c'est n'est pas le langage à choisir, je disais ça juste pour montrer que c'est faisable (et utile, et utilisé).
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
realisable en Perl.
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
Tu ajoutes le champ b dans l'objet a :
a.b = b
une méthode
a.f = f
Etu peux aussi créé des classe dynamiquement n'import quand ...
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
A cote, le Camel Book, c'est Tele 7 Jours.
<troll>
Sur ces bonnes paroles, je retourne a mon PHP.
Avec KNotepad.
</troll>
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
quelqu'un connait il un site de documentation sur python en français (tutorial, code source ...)
[^] # Re: Puisqu'on parle de perl...
Posté par Slowhand . Évalué à 1.
).
- http://www.python.org/doc/NonEnglish.html#french(...)
pour plus d'infos
- http://pythonfr.free.fr/(...) projet de traduction de la doc
[^] # Re: Puisqu'on parle de perl...
Posté par Anonyme . Évalué à 0.
# Acceleration rapide du developpement
Posté par MetalX . Évalué à 1.
Cependant, cette 2.0 n'est pas le Python 3000 tant attendu, qui lui n'est pour tout de suite. (et qui au depart devait s'appeller Python 2.0 si je ne m'abuse)
# Equivalent de CPAN & comparaison
Posté par Slowhand . Évalué à 1.
Vault of Parnassus : http://www.vex.net/parnassus/(...)
Et de ce qui est des avantages (je connais très peu Perl, mais je suis entouré de perlistes au boulot (salut à eux) ), l'API standard est déjà très interessante. La syntaxe du langage aide à la clarté du code (attention à l'indentation, il faut un bon éditeur). La documentation est très bonne (manuel de référence, tutoriel, FAQ ...), on développe rapidement etc...
Plein de comparaisons à :
http://www.python.org/doc/Comparisons.html(...)
Python est un très bon langage pour apprendre la programmation, tout en ayant les mêmes possibilités que Perl (honnêtement, vous enseigneriez Perl à des personnes qui n'ont jamais programmé ?)
Je ne crache pas sur Perl et l'utilise à l'occasion, mais si on me donne la possibilité, je choisi Python.
[^] # Re: Equivalent de CPAN & comparaison
Posté par Anonyme . Évalué à 0.
# PYTHON trop lent ?
Posté par Anonyme . Évalué à 0.
[^] # Re: PYTHON trop lent ?
Posté par MetalX . Évalué à 1.
J'ai pas fait de benchmarks exacts, mais soyons clair: avec l'interpréteur java, tu interprètes du bytecode. Autrement dit, il y a toute un phase de la compil qui a été fait en amont.
Concernant python et perl, je ne connais pas trop mais j'avais plutot entendu parlé de code interpreté... Ils ne sont pas compilés a proprement parlé...
Autre facteur, Java est strictement typé (strongly-typed: je suis pas sur de la traduc :-) ) ...
[^] # Re: PYTHON trop lent ?
Posté par Anonyme . Évalué à 0.
Quant à Java, il est vrai que les premières moutures n'étaient pas des foudres de guerre, mais la technologie avance, et on finit par s'approcher des perfs de C++.
[^] # Re: PYTHON trop lent ?
Posté par Wawet76 . Évalué à 1.
Tu parles du fait que le perl est compilé a la volé. C'est aussi le cas du bytecode Java avec toutes les machines virtuelles recente.
Reste que les composants graphiques standards de Java (awt et surtout SWING) sont tres sympa a utiliser mais sont lents et lourds...
[^] # Re: PYTHON trop lent ?
Posté par Gaël . Évalué à 1.
A mon avis, la vrai raison pour laquelle on pense souvent qu'en terme de vitesse, Assembleur > C > C++ > Java, c'est que plus un langage est proche de la machine, plus le programmeur est conscient des tours et des détours que fera le code; et peut donc l'optimiser. Avec un langage très abstrait où, comme en Java, toute la mécanique est cachée, il y a une certaine dose d'empirisme avant de faire du code rapide.
Bon, sinon, je vient de me rendre compte que je suis totalement hors-sujet.
[^] # Re: PYTHON trop lent ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Il ne le compile pas vers du binaire mais vers du byte code, un peu comme Java.
[^] # Re: PYTHON trop lent ?
Posté par Anonyme . Évalué à 1.
En plus, le code PERL ne peut etre compilé par un automate déterministe a nombre d'états fini.
[^] # Re: PYTHON trop lent ?
Posté par Anonyme . Évalué à 0.
ca a l'air bien ...
c'est quoi ?
Et ce serait pas parce-que Perl offre des solutions syntaxiques intéressantes que ce n'est pas possible ?
Boulon : qu'est-ce que j'ai bien pu foutre comme code nom de Z3uS
[^] # Re: PYTHON trop lent ?
Posté par Anonyme . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.