C'est ici : http://www.linuxquestions.org/questions/2008-linuxquestions.(...)
Comment choisissons-nous ?
Peut-on considérer le monde des langages de programmation comme un marché ?
Dans le marché grand public, ce ne sont pas toujours les meilleurs qui gagnent, mais en est-il de même dans un marché dont les "clients" sont avertis ? D'autant que le coût d'apprentissage incite à ne pas choisir à la légère (apprentissage non seulement d'un langage, mais surtout des bonnes pratiques et de l'API qu'il fournit).
À titre personnel (désolé, je me prends comme exemple), quand je choisis d'utiliser un logiciel à utiliser (pas pour contribuer, juste utiliser, et quand j'ai le choix, donc), la démarche qui sous-tend le développement est un élément crucial. Pour Python, l'ergonomie est manifestement au cœur des préoccupations, et le mécanisme d'amélioration permanente est clair et accessible.
Il y a donc les caractéristiques intrinsèques, mais aussi la façon de développer... on choisit quelque chose aujourd'hui parce que ça sera mieux demain ! Comment décider ?
En fait ça va jusqu'au caractère du/des mainteneur/s principal/aux (toujours mon humble avis : je suis assez fan du pragmatisme provocateur de Torvalds, mais juste amusé par les chouineries des BSDistes).
La perception des autres compte aussi : on ne peut avoir raison tout seul dans son coin pendant très longtemps dans le logiciel (ceux qui ont parié sur E17, levez la main).
La solidité d'un projet (libre en tout cas) tient énormément à l'écosystème dans lequel il s'inscrit ; par exemple l'importance de Debian à la fois dans le monde informel et dans le domaine commercial est un des facteurs qui la rend probablement insubmersible pour des années.
De plus la crédibilité, par les mécanismes d'emballement du marché, se renforce.
Pour clore ce billet de blogjournal par un pronostic, je parie au risque de me tromper que Python et Qt/KDE n'en sont qu'au début de leur ascension, en s'aidant mutuellement, comme l'ont fait Qt et KDE depuis le début.
PS: Au total, je fais du Python non par goût, mais par pur opportunisme, parce que c'est la meilleure façon de produire agréablement des logiciels maintenables de qualité, et vous ?
PS2: je n'ai pas de blog :-)
PS3: C'est un journal constructif, je n'ai pas souhaité dénigrer quelque projet logiciel que ce soit, car je pense que les commentaires sont faits pour ça.
Journal Python, langage de l'année pour la seconde année consécutive
14
fév.
2009
# bonheur
Posté par mxt . Évalué à -1.
File "", line 1, in
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
À quel bonheur python ....
[^] # Re: bonheur
Posté par feth . Évalué à 8.
[^] # Re: bonheur
Posté par Infernal Quack (site web personnel) . Évalué à 5.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: bonheur
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Choose Python3 (qui n'a plus ces problèmes d'Unicode).
[^] # Re: bonheur
Posté par zul (site web personnel) . Évalué à 10.
Ceci n'a pas vocation à être un message constructif :) Mais merci de relayez des sondages aussi "intéressant". Tout le monde devrait pourtant savoir que le langage le plus utilisé dans le monde c'est Tcl/Tk, j'ai un sondage qui le dit dans mon environnement de travail :).
Sinon félicitation pour le nieme message de python lover, mais on commence à avoir compris le message (c'est le nouveau langage IN sur linuxfr en tout cas)).
[^] # Re: bonheur
Posté par IsNotGood . Évalué à 2.
Sinon tu as raison, ce journal est naze.
PS: je n'utilise pas Python.
[^] # Re: bonheur
Posté par Larry Cow . Évalué à 5.
[^] # Re: bonheur
Posté par IsNotGood . Évalué à 1.
Pour le "Visual", un exemple pour python est Glade.
[^] # Re: bonheur
Posté par Larry Cow . Évalué à 7.
[^] # Re: bonheur
Posté par IsNotGood . Évalué à 3.
T'as raison.
> La particularité de VB était d'embarquer un interface de construction d'interface
Pas vraiment. L'intégration de VB dans les outils de développement est bien foutu (grace à la technologie en dessous (activeX)).
Il y a VB le language et VB l'IDE. Les deux ont le même nom.
On peut aussi construire graphiquement des interfaces avec python (du moins avec un bon IDE).
Si on met de côté la qualité des languages, l'intégration de VB est bien meilleur.
[^] # Re: bonheur
Posté par Larry Cow . Évalué à 4.
C'est totalement tiré par les cheveux. Faire du VB sans l'interface VB était, du temps de sa popularité, hors de propos. Je veux bien qu'avec l'avènement de .Net il soit possible de faire du VB dans notepad et de lancer un interpréteur là-dessus en ligne de commande.
Mais le VB qui a marqué le monde informatique, c'est un VB dans lequel langage et GUI étaient indissociables (propriété qu'on retrouve aussi dans ce cher Windev, par exemple). C'est même probablement pour cela que ça a marché.
[^] # Re: bonheur
Posté par Guillaume Knispel . Évalué à 1.
Hm, NON, je ne nourrirais pas le troll.
PS: je n'utilise pas Python.
T'avais pas vraiment besoin de préciser :P
[^] # Re: bonheur
Posté par feth . Évalué à 1.
1b) 861 personnes c'est déjà un énorme échantillon. Je ne connais pas la taille de la population de référence, mais sur la population française les échantillons sont de l'ordre de 1000 personnes.
Je cite ipsos (http://www.ipsos.fr/CanalIpsos/cnl_static_content.asp?rubId=(...) ) :
La marge d’erreur varie aussi en fonction de la répartition des réponses. Ainsi, pour 1000 personnes interrogées, elle sera de plus ou moins 3,2% si la réponse obtenue est de 50% mais seulement de plus ou moins 2,5% si elle est de 20 ou 80% et même de plus ou moins 0,9% si elle est de 2 ou 98%.
On a d'ailleurs ici une excellente occasion de reprendre nos cours de probabilité (mais moi je vais lâchement aller me promener dans la campagne ce dimanche).
[^] # Re: bonheur
Posté par Zenitram (site web personnel) . Évalué à 8.
Je cite ipsos
Avant de sortir des conneries énormes, évite de supprimer la partie qui ne t'arrange pas : l'intro que tu oublies à son importance, je cite (le gras est le truc important à ne pas oublier) :
En théorie, on ne peut pas connaître scientifiquement la marge d’erreur d’un sondage réalisé par quotas (voir question 2). En pratique, on estime que cette marge est du même ordre que celle que la loi de Gauss permet de calculer dans le cas des sondages aléatoires.
Oh, miracle, on apprend que la marge d'erreur fournie dépend de la "base" utilisée pour le sondage (qui représente l'ensemble de la population française dans le cas d'IPSOS), alors que les 861 personnes interrogées par le site utilise la méthode de "visiteurs du site qui aiment les sondages" beaucoup moins éprouvée et dont la marge d'erreur doit passer à 99.9%.
On a d'ailleurs ici une excellente occasion de reprendre nos cours de probabilité (mais moi je vais lâchement aller me promener dans la campagne ce dimanche)
Reviens, tu as 0/20, va falloir réviser sec pour espérer avoir au moins la moyenne : quand on sort des théories, on n'oublie pas les pré-conditions (souvent oubliées quand une personne a déjà la solution à ce qu'elle veut démontrer...).
Et n'oublie pas la partie "corrections d'un sondage" qui a son importance aussi :
http://www.ipsos.fr/CanalIpsos/cnl_static_content.asp?rubId=(...)
[^] # Re: bonheur
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Linuxquestions, ça fait peu de BSDiste, de windowsiens, et encore moins de "je me fous de l'OS".
Je serais plus tenté par ce sondage auprès des lecteurs de Lambda The Ultimate. Au moins, je me dirais que les gars savent pourquoi ils votent pour tel ou tel langage (en dépit du biais usuel genre "et en plus, je fais un doctorat sur telle propriété de ce langage")
[^] # Re: bonheur
Posté par dkremer . Évalué à 1.
http://www.developpez.net/forums/d683199/general-developpeme(...)
Pourtant c'est vrai que je l'aime bien, moi...
[^] # Re: bonheur
Posté par zul (site web personnel) . Évalué à 2.
Le sondage de dvp.com est sûrement plus neutre, en tout cas représentant bien plus la communauté de "développeur" française (aka à 90% sous Windows, dans des SSII :D)). Bon ça reste dramatique qu'on utilise / plébicite autant Java mais bon, ceci est un autre problème.
[^] # Re: bonheur
Posté par feth . Évalué à 4.
[^] # Re: bonheur
Posté par zul (site web personnel) . Évalué à 2.
# On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Ouaouuu... Rien que ça. C'est totalement subjectif ça. C'est peut être la meilleur façon pour TOI. Mais sûrement pas pour tout le monde. Chacun a ses préférences, ses goûts en matière de langage. Personnellement, ce n'est certainement pas avec Python que je vais produire des logiciels maintenables et de qualité. Tout simplement parce que je n'aime pas trop Python. Et ça veut pas dire qu'avec un autre langage, je ne vais pas produire des logiciels maintenables et de qualité.
Et puis, en dehors des gouts et des couleurs, il y a aussi le fait que chaque langage a ses spécificités, qui lui permet d'être plus efficace que d'autres pour la réalisation d'un type de logiciel particulier. Ce n'est par exemple certainement pas avec Python que je vais m'amuser à faire le moteur de rendu d'un browser HTML...
[^] # Re: On n'est pas vendredi
Posté par BAud (site web personnel) . Évalué à 1.
qu'est-ce-qui te ferait préférer XML-based_User_interface_Language au hasard ?
certainement pas le fait que c'est interprété, qu'il n'y a pas d'éditeur dédié, ni de tests unitaires normalisés, ni de compilation pour la vérification des types ou encore d'équivalent de valgrind pour les fuites mémoires ?
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Euh, c'est quoi le rapport avec un langage de programmation comme python ? Le XUL n'est qu'un format descriptif d'une interface utilisateur. Tu compares dont un format avec un langage. Très fort :-)
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu). à coup sûr, si je n'avais qu'à choisir entre XUL et python, je choisirais bien évidement python pour un projet comme ça, parce qu'avec XUL, je ne vais pas aller loin...
> certainement pas le fait que c'est interprété,
"interpreter" un fichier XML, c'est pas pertinent... Surtout que dans Gecko, le XUL n'est pas interprété, mais analysé et ensuite on travaille avec un DOM...
>qu'il n'y a pas d'éditeur dédié,
y a des plugins pour eclipse, y a Komodo...
> ni de tests unitaires normalisés,
Je ne vois pas ce que tu appelles "normalisés", mais il existe des outils pour faire des tests unitaires dans Mozilla.
>ni de compilation pour la vérification des types
hors sujet vis à vis de XUL
> encore d'équivalent de valgrind pour les fuites mémoires ?
Valgrind est utilisé dans le developpement de Gecko (même si il n'y a toujours aucun rapport avec XUL).
[^] # Re: On n'est pas vendredi
Posté par 2PetitsVerres . Évalué à 10.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: On n'est pas vendredi
Posté par BAud (site web personnel) . Évalué à 1.
cela me confirme donc bien que je n'ai jamais compris - à raison - le L de XUL \o/
[^] # Re: On n'est pas vendredi
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Bref, la comparaison entre Python et XUL n'a pas lieu d'être.
[^] # Re: On n'est pas vendredi
Posté par Alex . Évalué à 4.
Bref ça reste un langage car ça propose une grammaire formelle, mais ça sert "juste" à décrire des données
[^] # Re: On n'est pas vendredi
Posté par Bozo_le_clown . Évalué à 2.
C'est certainement pas avec ça que je vais développer le moteur de rendu d'un browser (j'ai bien dit : moteur de rendu)
En tout cas si j'avais à écrire une IHM pour un navigateur Web je ne choisirais certainement pas Javascript ;-)
[^] # Re: On n'est pas vendredi
Posté par feth . Évalué à 1.
Par exemple, je n'ai jamais vu de démarche charitable dans le développement d'emacs, alors que le vimiste ordinaire est altruiste.
# Effet de mode
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Certes, python est vieux (1991 d'après wp), mais j'ai l'impression qu'il est célèbre et répandu depuis, disons, 5 ans ? J'ai connu Ruby avant, par exemple (avec un vieux GLMF).
J'ai un peu cette image de "Python c'est mieux car"
- C'est objet
- L'indentation ca limite les bugs
- Contrairement à Perl, j'arrive à lire du code
Ce à quoi je suis tenté de répondre
- et si j'aime pas *cette* approche de l'objet ? Je veux (ou pas) héritage multiple, multiple dispatch…
- Les parenthèses aussi, et en plus ça détermine l'indentation
- Pour lire Perl, faudrait l'apprendre aussi, avant d'en dire du mal comme ça.
Je trolle pas mal langage, et je reste persuadé que beaucoup de gens choisissent Python, Ruby, autre… avec de faux arguments. Souvent, le choix du langage pour ses facilités devrait se tourner vers Perl (facilité de traitement) ou Scheme (facilité de prise en main et d'extensibilité).
Si encore tu disais "J'aime python, car toutes les libs dont j'ai besoin sont déjà là", ca ferait sérieux. Mais sur le langage lui même, non, faut pas pousser. Pas de quoi casser trois pattes à un canard.
Ceci étant, il est probable que Python ne fasse que commencer son ascension ; après tout, java a bien percé lui aussi…
[^] # Re: Effet de mode
Posté par Dr BG . Évalué à 3.
Sinon il y aussi des langages comme OCaml et Haskell où on a pas besoin de choisir entre efficacité et concision.
[^] # Re: Effet de mode
Posté par Misc (site web personnel) . Évalué à 10.
[^] # Re: Effet de mode
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Du code efficace en haskell, c'est loin d'être facile à écrire. Les programmes sur alioth sont souvent imbitables et super bas-niveau… Je code en OCaml et haskell depuis pas mal de temps, et même si GHC s'améliore sans cesse, je crois un bon programme haskell n'est pas à la portée du premier venu… Il sera certes pas dramatiquement lent, mais bien plus toutefois que l'on croyait, à cause de la paresse du langage qui va accumuler des données qu'il pourrait réduire comme on s'y attendait… (à tel point qu'il y a des fonctions pures non paresseuses fournies comme foldl'…)
[^] # Re: Effet de mode
Posté par Dr BG . Évalué à 1.
[^] # Re: Effet de mode
Posté par Octabrain . Évalué à 1.
[^] # Re: Effet de mode
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
La théorie derrière est pas fastoche, certes, mais dans la pratique, c'est juste une factorisation de code. Un design pattern, mais qui sert à rendre le code effectivement plus simple, concis, agréable…
Si tu comprends pas les monades en haskell, c'est juste que tu n'est pas fait pour les langages statiquement et fortement typés (car en pratique, si tu comprend le type des 2 fonctions "return" et "bind", ça va tout seul après…)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Effet de mode
Posté par Sarcastic . Évalué à 3.
Qui est bien vulgarisé et compréhensible (Ça mériterait peut-être une autre place qu'un commentaire perdu au fin fond d'un thread).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Effet de mode
Posté par MrLapinot (site web personnel) . Évalué à 2.
Ou comment comprendre toutes les « type classes » usuelles d'Haskell (y compris les monades, bien sûr).
[^] # Re: Effet de mode
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
bind a pour type
bind :: monade a -> (a -> monade b) -> monade b
C'est a dire que ca prend un objet dans sa monade et une fonction qui sait manipuler l'objet et le mettre dans une boite. Et ca retourne l'objet modifié dans la boite.
return a pour type
return :: a -> monade a
Ca prend un objet, ca le met dans la boite.
Pour manipuler un objet dans une monade (dans une boite), t'es *obligé* de passer par bind, sinon ca type pas.
Et c'est tout, en fait…
Exemple: j'ai une boite avec un nombre, et je veux incrémenter le nombre:
-- le nombre
n = 41
-- le nombre dans sa boite
nDansUneBoite = return n
-- la fonction qui incrémente
incremente x = x+1
-- incremente nDansUneBoite
-- ca marche pas ! incrémente ne manipule pas des boites !
-- faut utiliser bind pour que ca type bien
-- incrementeDansUneBoite xDansUneBoite = bind xDansUneBoite incremente
-- zut ! incremente a pas le bon type, ca doit rendre une boite !
incrementeDansUneBoite xDansUneBoite = bind xDansUneBoite (\x -> return (incremente x))
Ca y est !
Tout ce que j'ai fait, c'est faire en sorte que ca type.
Ici, ma boite est une simple boite, mais on peut en fait *embarquer* plein de calculs dans la boite qui se feront quand la boite sera passée a bind. Par exemple, elle peut garder 2 valeurs et s'utiliser comme buffer (et elle te filera la valeur du tour d'avant), ou alors stocker plein de valeurs (et représenter une liste), etc, etc.
C'est vraiment une interface, et le code derrière, tu fais ce que tu veux. Mais c'est bien (tm) car *beaucoup* de concepts collent à cette interface, et on peut les combiner…
# pourquoi j'ai choisi python...
Posté par djibb (site web personnel) . Évalué à 10.
Pour ma part, je suis prof de physique, je me suis intéressé à Linux en 2000 (suse 6.3) et je connais très peu le bash, un peu de turbo pascal (delphi) un peu d'access (sql un peu), le tout appris au cours de mes préigrinations scolaires (école d'ingé de chimie, club info en seconde...)
Bref : j'y connais rien en programmation. Le bas niveau c'est pas pour moi, je sais pas écrire une seule boucle en C...ne parlons pas du C++.
Seulement, voilà... j'ai plein d'idées... et j'en ai eu marre de devoir attendre que certains veuillent bien les faire avec un gros boulet (moi).
N'ayant pas que ça à faire (2 enfants, toussa), il me fallait quelque chose de rapide pour faire des logiciels avec des Gui.
Pour cela je me suis penché vers glade/GTK/python/Kiwi... que j'ai trouvé bof bof. Puis j'ai découvert python/QT4 dit "pyqt4".
Et là... c'est impressionnant... je développe un peu tout ce qui me passe par la tête (pymecavideo/ pyfocus /un logiciel pour modéliser les satellites/un logiciel qui permet de trier des photos astronomiques...) avec une efficacité importante.
Pour le peu que j'avais programmé en delphi, je me trouvaais toujours face à des "syntax error", chose qui ne m'arrive plus du tout en python car le langage est simple.
Son côté typage dynamique mais fort est aussi très intéressant.
J'utilise aussi pas mal de bibliothèques scientifiques pour des calculs sur des images (repérage et modélisation d'étoles sur une photo astronomique etc.) et pour ça numpy est vriament sympa....
Bref, pour moi, QT4 et toute sa clique d'objet (QImage notamment), ses outils (QT-designer, Qtlinguist) permettent vraiment d'avancer sans se prendre trop la tête et c'est magnifique...
Par exemple : en 4 lignes, détection de l'appareil photo branché ou pas via dbus...et récupération de toutes les informations adéquates (dans pyfocus)
Voilou pour faire avancer le schmilblick...
NB : j'avais tenter d'automatiser la récupération de lien web via une page et des download derrière, ça paraissait assez jouable, mais j'ai plus trop eu le temps... ca semblait jouable en moins de 15 lignes mais bon...
[^] # Re: pourquoi j'ai choisi python...
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
J'ai l'impression Python + Qt4 c'est un peu la solution choisie par beaucoup de gens en ce moment. C'est vrai que le C++, c'est franchement difficile à aborder, et ça tranche pas mal avec la simplicité de Qt4, du coup Trolltech^H^H^H Qt Software a développé toute une batterie de Macros pour pallier à la rudesse du C++ mais on est quand même obligé de s'y frotter.
[^] # Re: pourquoi j'ai choisi python...
Posté par IsNotGood . Évalué à -1.
Mouaif. On peut dire de même pour Python + Gtk+.
En passant, j'ai programmé en Qt (C++). Excellent.
Dernièrement pour un projet je ne pouvais pas utiliser Qt (alors que c'est à lui que j'ai pensé en premier). J'ai regardé du côté de Gtkmm et ce dernier n'a pratiquement rien à envier à Qt et est même plus élégant/propre pour certains aspects.
Qt a pratiquement toujours été la référence pour développer en C++. Mais c'est à réviser car gtkmm est vraiment bon (NB: je ne dis pas meilleur !).
Si je dois utiliser python, j'y regarderai à deux fois avant de choisir entre Qt ou Gtk comme toolkit graphique.
[^] # Re: pourquoi j'ai choisi python...
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
[^] # Re: pourquoi j'ai choisi python...
Posté par IsNotGood . Évalué à 3.
Mouaif. Si c'est seulement pour faire des couches au-dessus d'autres couches.
Une bonne librairie C++ (par exemple pour accéder à une base de donnée) doit être utilisable avec Qt ou Gtk+. Si ce n'est pas le cas, alors il y a un truc qui sucks (et c'est peut-être la librairie graphique...).
En passant, c'est aussi ce que j'aime dans gtkmm. Il y n'a pas gtkmm-xml, on utilise libxml, etc.
> Tout dépend de l'ambition de ton programme.
Rien à voir. Firefox utilise Gtk. Serait-il mieux avec Qt ? Rien ne le dit. Rien ne dit le contraire non plus.
[^] # Re: pourquoi j'ai choisi python...
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Une bonne librairie C++ (par exemple pour accéder à une base de donnée) doit être utilisable avec Qt ou Gtk+. Si ce n'est pas le cas, alors il y a un truc qui sucks (et c'est peut-être la librairie graphique...).
j''ai l'impression en te lisant que tu as encore tendance à considérer Qt comme une lib graphique. Ce n'est pas le cas, c'est une boite à outil multiplateforme dont une des principales particularités est d'offrir une couche d'abstraction au dessus d'autres libs pour ne pas avoir à se soucier de ça soi-même. Et oui, ça propose des widgets graphiques foutrement bien foutu et avec un meilleur rendu que GTK sur toutes les platformes cibles (GTK sous windows /o\...)
En passant, c'est aussi ce que j'aime dans gtkmm. Il y n'a pas gtkmm-xml, on utilise libxml, etc.
Ouais en gros, tu va te récupérer toutes les briques dont tu as besoin. En passant, faut bien s'assurer que toutes ces briques vont fonctionner correctement sur toutes les plateformes cibles de ton programme. Parfois, certaines briques sont à remplacer suivant les plateformes.
Bref, je sais exactement pourquoi j'utilise Qt et pourquoi je ne voudrais plus m'en passer maintenant. J'ai déjà assez de libs externes à gérer moi-même (d'ailleurs vive cmake pour ça !) genre Lua pour en plus me taper la gestion de XML par exemple.
[^] # Re: pourquoi j'ai choisi python...
Posté par palm123 (site web personnel) . Évalué à 2.
(dispo à http://www.crummy.com/software/BeautifulSoup/ )
import urllib
import BeautifulSoup
html = urllib.urlopen('http://www.vmspython.org').read()
s = BeautifulSoup.BeautifulSoup()
s.feed(html)
for i in s('a'):
try:
print i['href']
except:
pass
ウィズコロナ
[^] # Re: pourquoi j'ai choisi python...
Posté par djibb (site web personnel) . Évalué à 3.
[^] # Re: pourquoi j'ai choisi python...
Posté par Misc (site web personnel) . Évalué à 3.
Soit grosso modo un peu moins, dans la doc du module.
C'est fou à quel point les jeunes programmeurs ont tendances à ignorer perl et tout le corpus de code déja existant pour se faciliter la vie. Mais j'oubliez "oula la, bobo la tête, je doit réfléchir pour comprendre ce que $codeur_cochon a écrit, ça veut sans doute dire que tout le monde écrit comme un porc en perl".
Car le seul argument qui revient tout le temps, c'est "ben un jour j'ai écrit du code en perl et j'ai rien compris quand j'ai relu". Ce qui grosso modo revient à dire "je sais pas coder propre, donc je vais supposer que ç'est la faute du langage, pas du codeur". Les codeurs sont t'ils des idiots qu'il faut limiter avec "il y a une et une seule façon de faire ? Est ce qu'imposer un style de codage n'est pas une façon de limiter l'esprit digne de ce cher O Brien, personnage de 1984 travaillant au ministère de la vérité ?
[^] # Re: pourquoi j'ai choisi python...
Posté par kib2 . Évalué à 1.
>> import BeautifulSoup
>>
>> html = urllib.urlopen('http://www.vmspython.org').read()
>>
>> s = BeautifulSoup.BeautifulSoup()
>> s.feed(html)
>>
>> for i in s('a'):
>> try:
>> print i['href']
>> except:
>> pass
Mouais...en REBOL ça donne :
parse read http://www.vmspython.org [any [thru "A HREF=" copy link to ">" (print link)] to end]
C'est à dire une seule ligne !
[^] # Re: pourquoi j'ai choisi python...
Posté par Larry Cow . Évalué à 2.
[^] # Re: pourquoi j'ai choisi python...
Posté par kib2 . Évalué à 2.
Du reste, la version 3 le sera en grande partie.
[^] # Re: pourquoi j'ai choisi python...
Posté par Larry Cow . Évalué à 4.
Rien, mais par contre quand on choisit un langage, le fait de savoir qu'il y a une implémentation un tant soit peu indépendante, c'est un gros plus.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pourquoi j'ai choisi python...
Posté par Jean B . Évalué à 6.
from urllib import urlopen
from BeautifulSoup import BeautifulSoup
print '\n'.join(i['href'] for i in BeautifulSoup().feed(urlopen('http://www.vmspython.org').read())('a'))
1 ligne aussi si on passe sur les imports
--> []
[^] # Re: pourquoi j'ai choisi python...
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
# Pratique
Posté par wilk . Évalué à 1.
Que demander de plus ?
Ce que je fait avec ? Des scripts d'admin, de graphisme, de gestion, en ligne ou pas, sous linux ou pas, pro ou pas.
Et pour le plaisir d'être plus proche du système, de mes goûts, par nostalgie, pour que ça tourne plus vite, je m'autorise de lui coller un peu de C.
La seule fois où j'ai perdu du temps avec Python c'est quand j'ai décidé de migrer mes applis en utf8/unicode au lieu d'attendre la v3...
# La seule expérience Python de ma vie
Posté par gUI (Mastodon) . Évalué à 5.
En 2000 et des brouettes, j'avais besoin d'automatiser une connexion vt sur port série (il fallait si je me souviens bien initialiser un debuggeur à distance...). Je vais voir le mec qui est censé nous pondre les petits outils sur mesure et lui expose le problème.
Dialogue :
- J'ai pas trop le temps de te faire ton truc, mais en python, tu verras c'est super simple, t'as toutes les bibliothèques qui existent.
- Mais je connais pas Python moi
- Tu verras c'est super bien foutu, je te maile une doc, ça roulera tout seul.
Et bien 2h plus tard j'avais mon script python qui tournait et initialisait mon debuggeur via le port série. La classe.
Surement que j'aurais pu faire la meme chose en Ruby (je connaissais pas du tout à l'époque) ou dans une foultitude d'autres langages haut niveau, mais faut reconnaitre qu'il n'a pas faillit à sa réputation.
Bon, cela dit, depuis, j'y ai plus retouché (-;
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à 1.
Oui, donc en gros, de ce que je lis, le plus gros bonus de Python est qu'il impose une bibliothèque "standard" alors qu'en C/C++, on te laisse le choix (parce que bon, entre "s = BeautifulSoup.BeautifulSoup()" et "BeautifulSoup s" je ne vois pas trop la différence quand au language, et l'indentation forcée j'ai du mal à accepter (qu'on me force))
Et oui, je vais aller à l'encontre du "Python c'est bien", mais la, Python me fait penser à Windows : les deux sont super parce qu'ils imposent une API/bibliothèque de base complète alors que Linux et C/C++ te laisse le choix quand à la distribution/bibliothèque (et l'indentation)
Et d'un côté, on prône la liberté, de l'autre c'est génial de ne pas avoir le choix et tout le monde utilise la même chose (et l'indentation).
Bizarre ces libristes, je n'adhère pas à l'idéologie Python du coup.
Désolé d'être à l'opposé de la pensée commune, mais cette indentation est l'exemple type de ce qu'est Python : on te dit qu'il y a une seule bonne méthode, et si tu fais pas comme c'est dit, bam erreur démerde toi (erreur à l'exécution de préférence), bref rentre dans les clous ou dégage. Je dégage donc.
[^] # Re: La seule expérience Python de ma vie
Posté par Octabrain . Évalué à 2.
[^] # Re: La seule expérience Python de ma vie
Posté par zul (site web personnel) . Évalué à 4.
BeautifulSoup s; // appel du constructeur par défault
sauf si tu vois une raison particulière dans ce cadre d'avoir besoin de manipuler un pointeur (à par vouloir explicitement montrer ce qu'il ne faut pas faire)). La durée de vie de l'objet est limité à sa portée, il faudrait en effet en tenir une bonne couche pour accoucher d'un pointeur. Dans les rares cas où tu en aurai besoin, on peut utiliser des surcouches intelligentes qui te libère d'une bonne partie du travail (auto_ptr, smart_ptr, ...).
Avant de dire qu'un outil est mauvais, apprend à l'utiliser. Et évite de proférer des stupidités en public, ça te décrébilise un max :)
[^] # Re: La seule expérience Python de ma vie
Posté par Octabrain . Évalué à 0.
Ensuite, c'est vraiment super de parler de *_ptr, mais là tu tends à montrer que C++ est emmerdant, s'il faut enrober chaque objet avec d'autres couches, alors que Zenitram essayait de montrer le contraire.
[^] # Re: La seule expérience Python de ma vie
Posté par Octabrain . Évalué à 3.
[^] # Re: La seule expérience Python de ma vie
Posté par nicoastro . Évalué à 6.
M’enfin, s’arrêter à ce genre de détail pour un langage ne vaut pas grand chose. Personnellement j’ai commencé Python environ une semaine avant le journal sur Linux Magazine (le hasard fait bien les choses:) et je ne comprend pas cette tentation que tout le monde a de comparer les différents langages. Chacun a ses avantages/inconvénients, ce qui permet de s’adapter en fonction de ce que l’on a à faire. Je vois bien le C pour des traitements « lourds, » le Python pour le post-traitement qui a besoins de calculs ou alors le Bash, le Perl (faudrait vraiment que je sois obligé là… question de goût) pour du traitement plus « textuel » que numérique. Ceci n’est qu’un exemple.
Pourquoi vouloir à tout prix établir un classement ? Ça n’a vraiment pas de sens, tout simplement suivant l’usage l’un est plus adapté que l’autre.
[^] # Re: La seule expérience Python de ma vie
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Hum, quand je vois la batterie de tests lancés par les autotools pour tester si on a bien tout ce qu'il faut, je trouve Python beaucoup plus agréable. J'avais fait un peu de C++, et ce que j'en ai retenu : c'est qu'on ne peut pas supposer que la STL est complètement et correctement implémentée. Je me souviens de wxWindows (maintenat appelé wxWidgets) qui avait du mal à migrer à la STL (ex: utiliser std::string plutôt que leur classe maison) car ils visent une grande portabilité et la plupart des compilateurs n'étaient pas prêt. Résultat : chacun recode son std::string (ex: QString dans Qt) dans son coin... Et encore, j'ai pris l'exemple le plus trivial, la STL c'est un peu plus gros que juste les chaînes de caractères ;-)
Qui a dit que Python impose une bibliothèque standard ? Oui, elle est disponible à coup sûr, mais libre à toi de l'utiliser ou non ! Bien sûr, tu peux recoder ta propre bibliothèque standard à toi et réutiliser plein de bibliothèques non standards (ex: setuptools, twisted, PyQt, ...). Mais pour les tâches simples, on est très content d'avoir des bibliothèques fonctionnelles de base.
[^] # Re: La seule expérience Python de ma vie
Posté par zul (site web personnel) . Évalué à 3.
On suppose que la lib python est correctement implémenté dans l'implémentation par défaut parce que la lib livré, c'est le "standard". Est-ce que toutes les implémentations de python sont conformes ? Y'a t'il un truc strictement décrit qui permettrait de confirmer que la lib correspond à sa spé ou on part du postulat que c'est vrai ?
Pour wxWidget, je ne saurai juger, mais au final les idées derrières QString et std::string sont très différentes. std::string est conforme à la logique STL, aka un conteneur sur lequel on peut appliquer des algorithmes. Il se trouve que cette définition est assez anti conformiste, et que beaucoup la trouve peu pratique à utiliser. Qstring reprend une interface plus standard (mais nettement moins générique et belle). Pour information, de quand datent tes connaissances sur le C++ ?
[^] # Re: La seule expérience Python de ma vie
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Si tu utilises la bibliothèque standard, tu es sûr que le module est disponible.
Pour les dépendances (modules tiers), c'est le même bazar qu'importe le langage. Pour Python, y'a la méthode setuptools, la méthode Debian, etc.
Est-ce que toutes les implémentations de python sont conformes ?
En gros, il y a CPython (l'implémentation de référence) et les autres :-) PyPy est compatible à 99% (allez, on va dire 100%), mais reste expérimental. Jython et IronPython implémentent un peu comme ça leur chante quitte à briser la compatibilité (je pense en particulier à IronPython qui fait n'importe quoi) :-/
Y'a t'il un truc strictement décrit qui permettrait de confirmer que la lib correspond à sa spé ou on part du postulat que c'est vrai ?
Pour mesurer le compatibilité, il y a l'énorme suite de tests sur la bibliothèque standard.
Pour information, de quand datent tes connaissances sur le C++ ?
Hum, ça doit faire 2/3 ans que j'ai plus touché au C++.
--
Au sujet de wxWidgets, extrait de la FAQ :
http://www.wxwidgets.org/docs/faqgen.htm#stl
« ... it is in wxWidgets' best interests to avoid use of templates. Not all compilers can handle templates adequately so it would dramatically reduce the number of compilers and platforms that could be supported. »
« The standard C++ string class is not used, again because it is not available to all compilers, and it is not necessarily a very efficient implementation. »
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à -2.
Et ca ne te pose pas un problème?
Par contre, les incompatibilités C/C++, avec plusieurs fournisseurs de compilateur, ça te pose un problème?
Bizarre, quand c'est du C/C++ l'incompatibilité est gênante (alors que les incompatibilités de la STL se voient sur des endroits où Python n'est même pas compilable genre embarqué...), pas pour Python.
En fait, la seul garantie que j'ai avec ce langage est que mon programme fonctionne sur un et seulement un interpréteur, donc "l'entreprise" a montré qu'elle ne se souciait pas du vieux code (incompatibilité v2 --> v3) --> En fait, sur un seul interpréteur et une version donné, cool pour l'avenir.
C'est bon, j'ai mon idée sur la pérennité de la chose ainsi que l'objectivité des critiques des autres langages et les louanges de ce langage.
[^] # Re: La seule expérience Python de ma vie
Posté par grid . Évalué à 6.
>Et ca ne te pose pas un problème?
non, parce que j'ai toujours travaillé avec CPython, comme 99% des programmes.
La STL, c'est des emmerdes à 99% de chance.
Python embarqué existe depuis longtemps. genre sur nokia http://opensource.nokia.com/projects/pythonfors60/
Un programme uniquement compatible IronPython utilisera les spécificités de la plate-forme .NET, ce qui ferme d'office l'ensemble des autres interpréteurs. C'est un choix, et le logiciel libre, c'est aussi le choix.
>C'est bon, j'ai mon idée sur la pérennité
Une idée préconçue depuis le départ.
Mes programmes python écrit pour du 2.1 fonctionne toujours en 2.6.
Python 3000 a cassé la compatibilité ? ok, ca ne pose pas de soucis pour moi, soit je resterais en 2.x, soit je les convertirais (ce qui est très rapide à faire, sur un projet de 20 000 lignes.
Peut-être que le C++ aurait mieux fait de faire un peu de ménage pour éviter d'être un enfer lorsqu'on veut être multi-plateforme/multi compilo.
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à 2.
Je le vois autrement : j'avance des problèmes, et la seule réponse que j'ai est "mais c'est pas grave". Alors forcement, pour faire changer d'avis quelqu'un, c'est pas gagné.
Par exemple :
Mes programmes python écrit pour du 2.1 fonctionne toujours en 2.6.
Ben oui, mais moi ca m'embête de ne pas savoir si mes programmes vont passer en 3.0 ou 4.0 etc...
Peut-être que le C++ aurait mieux fait de faire un peu de ménage pour éviter d'être un enfer lorsqu'on veut être multi-plateforme/multi compilo.
C'est sans doute de la que diverge notre vision : je cherche la stabilité à terme. Python ne me l'apporte pas, car pensée à court terme. C'est un choix. Ce langage ne répond pas à mon besoin.
non, parce que j'ai toujours travaillé avec CPython, comme 99% des programmes.
C'est un choix. Pas le mien, je préfère rester indépendant d'un distributeur. Certes c'est libre on peut forker, mais quand même, ça reste marrant de voir les gens aimer les langages dont la destinée est décidée par une entité. Encore un truc pas pour moi (en C/C++, c'est un comité qui décide, c'est plus démocratique).
Python, c'est comme programmer avec Visual C++ : pas d'emmerdes avec la STL, ca compile pour 99% des utilisateurs, alors pourquoi s'emmerder avec le 1% qui fait chier?
Je ne vous embête pas plus : j'ai "compris", Python c'est le super truc qui n'a pas de défauts car il ne s'appelle pas Microsoft.
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 1.
Dans ce cas, tu souhaiteras probablement éviter le C++. Ou en tous cas le C++ libre. À moins que les changements d'ABI de gcc aient déjà disparu de l'inconscient collectif, parce que c'était franchement plus lourd à gérer que ce que fait Python pour le passage de 2 à 3.
Alors ok, ça s'est un peu calmé et ça n'était lié qu'à un seul compilateur. Sauf qu'en C++, l'interopérabilité entre les implémentations, c'est loin d'être ça. Et que, comme en Python, rien ne garantir l'avenir. Life sucks.
Il y a des tas de raisons de ne pas aimer Python et (un peu moins) des tas d'aimer C++. Mais de grâce, mets-les en concurrence sur des points où C++ est vraiment gagnant, si tu veux mettre en lumière ses qualités.
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à 2.
Que vient faire la partie binaire dans la discussion? Ca n'a absolument rien à voir avec le source, qui n'a absolument pas à changer entre GCC 3.3 et GCC 3.4 (changement d'ABI d'un et un seul compilo)?
Tu amènes des choses, des défauts sur un côté où Python a éliminé le problème : pas de compilation (donc un package de plusieurs Mo pour un simple "Hello world").
Ca repart toujours dans le truc "vive le monopole de Python, avec Python pas d'incompatibilité du au monopole")
Avec ton argumentation, Linux c'est pourri il y a des problèmes tout le temps (jamais la même distrib, mais c'est simple, on additionne les problèmes), restons sous Windows la compatibilité binaire est assurée depuis 13 ans (mes softs tournent sur Win95 --> Windows 7, j'en dirai pas autant de Linux...).
C'est le truc rigolo : je retrouve exactement sur le principe les arguments des Windowsiens ici-même appliqués à Python. et ça ne vous choque pas?
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 3.
Certes, par contre il y a eu aussi des modifs côté source entre la version 3 et la version 4 (notamment dans la "tolérance" à certaines pratiques de développement qui s'est durcie).
Tu peux chercher toutes les raisons que tu veux, il n'empêche que le développement en C++ ne t'apporte pas plus de garantie qu'en Python, et que tout ce que tu trouves à y redire c'est ce que tu reproches au mec d'en haut que je sais plus qui c'est : dans la théorie, c'est pérenne, dans la pratique ça l'est pas.
Si tu veux tout savoir, je n'aime pas (plus, en fait) C++, mais pas pour ces questions de pérennité à la manque. De même que si j'aime Python, çà n'a rien à voir avec ça non plus, et ça m'agacera probablement aussi le jour où mon code ne sera plus compatible avec la version "mainstream". Pour moi, tout ce débat sur la pérennité du code est un faux problème, du moins tant qu'on ne fait pas entrer dans l'équation un langage pour lequel la dite pérennité a été un critère fondateur. Et ça n'est le cas ni de Python, ni du C++ (le C s'en sort un peu mieux, mais ça n'a pas non plus été une volonté exprimée au départ, il me semble).
Tu amènes des choses, des défauts sur un côté où Python a éliminé le problème : pas de compilation (donc un package de plusieurs Mo pour un simple "Hello world").
Ca repart toujours dans le truc "vive le monopole de Python, avec Python pas d'incompatibilité du au monopole")
Unmatched parenthesis ;)
Maintenant, oui, c'est vrai. Et après? Si le problème est éliminé, c'est l'essentiel? Et si la résolution a apporté d'autres soucis, on peut discuter de ceux-ci. Mais, au passage, le "simple hello world" qui fait plusieurs Mo, c'est de la mauvaise foi à l'état pur : le hello world "opérationnel" en Python ne fait que quelques octets (strlen('print "hello world"') + 1, à vue de nez). Si tu veux compter tout l'interpréteur dedans, et c'est ton droit, il ne faut pas oublier que ça te fournit l'environnement de développement pour le "même prix", et que pour être juste tu pourrais compter g++ dans le score du C++. On peut jouer à ce petit jeu là longtemps, et personne ne gagnera.
Avec ton argumentation, Linux c'est pourri il y a des problèmes tout le temps
Hein? Je défends un langage pour lequel les spécifications ne sont pas gravées dans le marbre, et tu arrives à en déduire que je critique le changement?!
Pour information, je n'ai pas prétendu que Python était immuable ni rien, j'ai juste fait remarquer que le langage que tu défendais ne brillait pas vraiment pas la stabilité de ses interfaces. Pour ce qui est de la compatibilité binaire sous win, c'est à peu près comme sous Linux : ça dépend. Des softs vieux de 13 ans qui tournent encore (modulo une recompilation, certes), ça peut se trouver. Des softs qui tournent tels quels, j'en ai qui datent de 1999/2000 environ. Et encore, je ne parle que des softs "compilés", j'ai des scripts shell plus anciens que ça qui marchent du feu de dieu. Et pareil, des programmes de 95 qui sont infoutus de tourner sur un Windows récent, j'en ai. Pas besoin d'aller chercher des merdes en mode DOS, il y a quantité de softs qui se basaient sur l'absence de protection mémoire de win9x et qui se vautrent comme des merdes depuis win2k.
C'est le truc rigolo : je retrouve exactement sur le principe les arguments des Windowsiens ici-même appliqués à Python. et ça ne vous choque pas?
Et je suis certain qu'on pourrait faire l'inverse et appliquer les arguments des Linuxiens (diversité, choix, libre accès au source, développement à la portée de tout un chacun). C'est vraiment une question de point de vue, et ça me déçoit un peu de voir ta prose, d'ordinaire assez douée pour éviter les œillères et autres intégrismes à deux balles, donner dans la dialectique de nightclub.
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à 2.
Arghhh, erreur venant du compilo C/C++ du coup :)
C'est vraiment une question de point de vue, et ça me déçoit un peu de voir ta prose, d'ordinaire assez douée pour éviter les œillères et autres intégrismes à deux balles, donner dans la dialectique de nightclub.
Disons que dans le cas de Ptyhon vs C++ (vs plein d'autres), c'est beaucoup moins clair, car ça fait aussi entrer des choses très subjectives (je n'aime pas le principe de l'interprété) et des besoins différents qu'on ne peut pas concilier (va faire rentrer un interpréteur Python dans 1 Mo en embarqué, mais va faire pas trop gros avec au moins 100 programmes quasi identiques quand tu as 100 Mo où le temps de dév est le plus important, la l'interprété va mieux) contrairement à Linux qui peut s'adapter à tout ou presque, donc c'est beaucoup facile d'être carré sur l'argumentation ;-), donc je l'admets, je suis moins à l'aise, donc j'accepte la critique (tout en continuant à rejeter toutefois certaines "qualités" de Python qui viennent du "monopole" de CPython, faut pas déconner ;-) )
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 5.
Ca s'est vu :)
Pour le reste, j'ai trouvé chez Python un relativement juste équilibre. Effectivement, j'y ai perdu une certaine efficacité à l'exécution, par rapport au temps où je faisais du compilé. Mais j'y ai terriblement gagné en temps et en plaisir de développement. Et ça, je ne suis pas prêt à le perdre. Et vu ce qu'on voit de nos jours (les gens d'OpenMoko qui trouvent des parades pour éviter de multiplier l'impact de l'interpréteur par le nombre de programmes, les gens de PyPy qui refont Python en Python "pour la beauté du geste" et qui en tirent des enseignements capables d'améliorer les autres implémentations, et j'en passe et des meilleurs...), je ne dois pas être le seul (y'a déjà l'auteur de ce journal, logiquement).
Alors oui, c'est un langage interprété, il a des particularités qui ne plaisent pas toujours, il est relativement lent, c'est pas un vrai langage d'homme bien velu comme C, c'est pas chatoyant comme le costard Armani d'un consultant J2EE, ça fait pas fumer les méninges comme OCaml ou Haskell, ça passe moins bien à l'échelle qu'Erlang, ... Oui, chaque langage a ses avantages et ses inconvénients. Et chaque "toolkit" apporte aussi son lot de plus et de moins. Entre faire du PyGtk et du Qt en C++, j'hésite pas un instant et je choisis le C++. Mais quand j'ai pas envie de me traîner environnement de développement monstrueux derrière moi et de coder "à l'envi", je choisis Python. Et quand j'ai trop bu, je fais du Java.
[^] # Re: La seule expérience Python de ma vie
Posté par Dr BG . Évalué à 1.
Je ne trouve pas ces langages plus compliqués. Il s'agit juste d'une autre approche. Si tout le monde commençait par apprendre le fonctionnel plutot que l'impératif, le saut aux langages impératifs serait peut-être même encore plus compliqué (mine de rien, vous y êtes habitué, mais l'affectation n'est pas tellement naturelle).
[^] # Re: La seule expérience Python de ma vie
Posté par Octabrain . Évalué à 2.
Par contre, avec CAML et Haskell, dès qu'il s'est agi des IO, ça a commencé à devenir juste "chiant". Puis pour Haskell, arrivé aux monades, j'ai eu beau essayer de comprendre, ça ne passait pas. J'ai fini par me faire une raison, genre "j'ai pas le QI nécessaire pour comprendre ça", et j'ai abandonné, plutôt déçu.
Et, non, je ne pense pas que ça soit uniquement une histoire d'habitude de l'impératif.
[^] # Re: La seule expérience Python de ma vie
Posté par Metzgermeister . Évalué à 2.
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 2.
Avec le temps, et à contre-coeur, j'ai fini par abandonner Caml, en gros dès que j'ai eu trouvé des remplaçants au C++ (ObjectiveC, puis Python, dans mon cas).
Alors effectivement, j'avais connu des langages impératifs avant, ça joue surement...
[^] # Re: La seule expérience Python de ma vie
Posté par Antoine . Évalué à 3.
Ah oui, le design by committee... J'imagine que c'est ce qui explique que 20 ans après sa création, le C++ ait toujours une bibliothèque standard médiocre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La seule expérience Python de ma vie
Posté par Antoine . Évalué à 2.
Si si, je suis désolé. Un langage qui s'est traîné pendant des années une classe "string" rachitique au point qu'il faut souvent caster en "char *" pour faire des choses un peu complexes est un langage bridé par sa bibliothèque standard.
(et là je suis gentil, je ne parle même pas des années où il n'y avait même pas de classe "string" standard)
Est-ce que Ada est aussi médiocre ?
Des souvenirs que j'en ai, oui :-) Disons que sa supposée robustesse en est le seul avantage. Pour le reste, beaucoup trop verbeux pour ce que ça fait.
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 0.
Objective-C avait su garder cette compatibilité : un programme C restait un programme ObjC tout à fait valide. Je ne sais pas ce qu'il en est advenu avec Objective-C 2.0, par contre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La seule expérience Python de ma vie
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Pourquoi tu dis ça ? Est-ce toujours cette obsession (Python3 va forcer tout le monde à migrer) ? En supposant que Python3 forcerait tout le monde à migrer (ce qui est faux), ça fait quand même 8 ans que la compatibilité ascendante n'avait pas été cassée.
As-tu suivi un peu PHP 4.0 => 4.3 => 4.4 => 5.0 ? Moi j'y ai goûté, et c'est un sacré merdier... Autre exemple : Perl6 va tout révolutionner, super. Par contre, il n'y a aucun outil de conversion Perl5 vers Perl6, il faut tout recoder manuellement ! Pourtant, c'est un langage de linguiste, ils auraient pu écrire un traducteur ;-)
Tu compares la stabilité de Python à la stabilité du C++, mais ce n'est pas comparable. Quand tu installes Python, tu as directement des bibliothèques pour décompressser une archive ZIP, te connecter à un serveur FTP, envoyer des emails, etc. C'est aussi cette ENORME bibliothèque standard qui est restée disponible et stable durant toute cette période. Est-ce que l'API de Boost et de Qt est restée stable sur 8 ans ? Je ne crois pas : il faut réécrire les programmes Qt3 pour Qt4...
Python, c'est comme programmer avec Visual C++
Visual C++ est un logiciel propriétaire uniquement disponible sous Windows et son développement dépend du bon vouloir de Microsoft.
quand même, ça reste marrant de voir les gens aimer les langages dont la destinée est décidée par une entité. Encore un truc pas pour moi (en C/C++, c'est un comité qui décide, c'est plus démocratique)
Tu te permets de critiquer une communauté que tu méconnais totalement ! Es-tu réellement capable de proposer une nouvelle fonctionnalité dans le langage C++ ? Pour Python, je te dirai que tu peux car il n'y a pas de comité : n'importe qui peut proposer ce qu'il veut, les idées sont longuement discutées et les meilleures sont implémentées. Les changements lourds (changement du langage) passent par l'écriture d'une PEP :
http://www.python.org/dev/peps/
Bien que je sache pas du tout comment évoluent les langages C++ et Java, ça me semble quand même beaucoup plus fermé (fait par des sociétés, passe par un organisme de normalisation on ne peut plus sérieux, etc.).
[^] # Re: La seule expérience Python de ma vie
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
Dans le monde réel, Python a ceci de particulier que c'est CPython qui est utilisé pour la grosse grosse majorité des programmes Python. Et cette implémentation libre est dispo sur la plupart des platformes majeures ( http://fr.wikipedia.org/wiki/CPython ).
En matière de pérennité, je sais pas ce qu'il te faut de plus.
[^] # Re: La seule expérience Python de ma vie
Posté par Zenitram (site web personnel) . Évalué à 0.
L'argument fourni me fait penser à "Je développe sous Visual C++, qui est utilisé par tout le monde, c'est pérenne pourquoi changer, pourquoi s'emmerder à être compatible GCC?"
Nous n'avons juste pas la même conception de pérennité ni de compatibilité pour un langage.
[^] # Re: La seule expérience Python de ma vie
Posté par Guillaume Denry (site web personnel) . Évalué à 1.
Gni ? Si demain je sors un compilo C++ qui respecte pas la norme , alors le C++ c'est pourri et le C++ devrait "s'emmerder" à être compatible avec mon compilo ?
[^] # Re: La seule expérience Python de ma vie
Posté par zul (site web personnel) . Évalué à 2.
La STL 99% d'emmerde ? Un peu de sérieux ne ferait pas de mal à ce thread. Tu peux donner un cas pathologique ? voir 99 cas pathologiques (je me chargerai de trouver des cas qui marche, ça sera moins fatiguant?))
Quand à faire du code portable, de nos jours, ce n'est guère plus un problème, vu le nombre de librairies portables et de qualité existant (oui faut faire une petite étude en amont pour éviter d'utiliser n'importe quoi, trop dur, suis sûr que vous choississez vos libs pas standard au premier résultat sur google :)) (Citons qt, boost, ACE pour quelques unes des grands fonctionnalités classiques).
Le langage et l'eco système ont évolué, C++ is not just C with class :). Et le FUD c'est mal
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . Évalué à 4.
[^] # Re: La seule expérience Python de ma vie
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Et ca ne te pose pas un problème?
J'avais testé Jython et IronPython il y quelques temps, alors :
- C'est désuet : Jython 2.2 implémente Python 2.2 alors que la dernière version stable est Python 2.6 (et on parle même pas de Python 3.0...) => Jython 2.5 est en développement, Sun semble pousser le projet, chouette !
- Ça m'intéresse pas : Jython nécessite la JVM et IronPython le truc .NET ou Mono, je préfère CPython qui me semble plus léger (et portable?)
- IronPython est bogué et incompatible avec CPython : j'ai rapporté plusieurs bugs mais je n'ai pas obtenu de réponses... j'ai pas envie de toucher à du code .NET. Je me souviens que Microsoft avait déjà écrit des implémentations incompatibles de JavaScript, puis HTML, puis XSLT, etc. Bref, c'est sans espoir et c'est tant pis pour eux :-p
Note : PyPy est un bordel expérimental qui ne semble intéresser personne et n'est pas aussi performant qu'ils auraient voulus. Perso, j'ai abandonné PyPy car je ne comprend rien au code, je ne peux pas contribuer.
Par contre, les incompatibilités C/C++, avec plusieurs fournisseurs de compilateur, ça te pose un problème?
Je considère Jython et IronPython comme très minoritaires (à vrai dire, je ne connais personne qui l'utilise !?). Tant dis que CPython est installé de base sous Linux et Mac OS X, de plus en plus présent sous Windows, et commencer à rentrer dans nos téléphones mobiles. Pourquoi faudrait-il avoir plusieurs implémentations majeures si l'implémentation de référence convient à tout le monde ? Bon, je crois qu'en même qu'à terme Jython, IronPython et PyPy vont tendre vers une compatibilité maximale (ils ont tout intérêt pour pouvoir exécuter le code existant...).
"l'entreprise" a montré qu'elle ne se souciait pas du vieux code (incompatibilité v2 --> v3)
Mais d'où sort cette idée que Python3 signe l'arrêt de mort de Python2 ? Python2 continue d'être développé, pour preuve 2.6.1 est sorti récemment. D'ailleurs, 2.7 est prévu et trunk est encore la branche 2.x (la branche 3.x, py3k, est à part !).
D'ailleurs, tu te trompes doublement car il existe un programme de conversion (2to3) qui permet de migrer du code Python2 sans aucun effort ;-) De par mon expérimente, pour un projet pur Python de 25.000 lignes, il m'a fallu une après-midi pour faire la conversion. Mais mon projet reste du Python2, j'ai juste écrit des scripts pour le convertir en Python3 pour les gens qui veulent essayer.
[^] # Re: La seule expérience Python de ma vie
Posté par zul (site web personnel) . Évalué à 2.
Si tu utilise un module de la libstdc++, tu es aussi sur de l'avoir. Evidemment, c'est moins large que python, mais bon globalement, le problème arrive tôt ou tard, et c'est assez chiant.
Le respect de la "non-specification" semble évidemment très implémentation dépendant, et donc globalement la majorité des codes python ne fonctionne que sur Cpython. On peut donc dire que ça dépend beaucoup de l'interpréteur que tu utilise. L'utilisation de tests permet peut-être de vérifier l'interface (encore faut il que les tests soient exhaustifs), mais pas la complexité des implémentations (qui est par exemple préciser pour les algorithmes de la lib standard C++).
Concernant les templates et le C++, il y'a possiblement des compilateurs qui ne les implémente pas, ou mal. M'enfin boost (la plus grosse lib C++ donc, à base à 99% de template) fonctionne sur tous les compilateurs majeurs C++ existants, donc ça doit pas être si critique que ça de nos jours. Pour std::string, aucune idée, le bottleneck chez moi, ça a jamais été std::string (surtout qu'on peut spécifier un allocateur spécifique de mémoire si besoin)).
En conclusion, je ne vois pas bien l'avantage de python sur C++ sur les points cités (surtout si tu limite le monde C++ a g++ comme tu limite le monde python à Cpython).
[^] # Re: La seule expérience Python de ma vie
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Bon, ok, c'est un langage pas à la mode, lourdingue et le ompilo est limite fasciste mais bon, j'ai déjà écrit tellement de conneries qu'un compilo qui me flique, ça peut pas me faire de mal :D
[^] # Re: La seule expérience Python de ma vie
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
Quand le langage est Turing-complet c'est ok, tu peux faire ce que tu veux avec, le reste c'est les gouts et les couleurs ... Par contre avec un logiciel proprio tu peux toujours te brosser pour modifier le code, c'est interdit et pas facile : un peu plus qu'un problème de gout.
[^] # Re: La seule expérience Python de ma vie
Posté par Antoine . Évalué à 3.
Voilà, c'est bien connu, il y a des tas d'alternatives à la libc.
ils imposent une API/bibliothèque de base complète
Tu peux réécrire ta propre stdlib Python si ça t'amuse, un peu comme tu peux réécrire ta propre libc. Je pense même que réécrire la stdlib Python serait plus facile.
mais cette indentation est l'exemple type de ce qu'est Python : on te dit qu'il y a une seule bonne méthode,
Oui, car C/C++, lui, te laisse utiliser les accolades pour autre chose que pour délimiter tes blocs.
Je dégage donc.
Au vu du dessus, c'est une décision raisonnable :-)
# Python et KDE?
Posté par Sylvain Colinet (site web personnel) . Évalué à 3.
Ensuite python Qt/Kde est beaucoup développé parce que python a réussis a attirer beaucoup de gens grâce a un effet de mode. Les develeppeurs principaux de KDE sont très peu ouvert à autre chose que du C++ dans les trucs de base.
Pour moi python a eut et à encore du succès parce qu'il y a eut une bonne poussée d'utilisateur qu'on pourrai comparer au wiki gentoo. Y a un bon regroupement de la doc et de méthodes clef en main.
Mais d'un point de vue technique c'est clairement pas ce qu'il y a de mieux et de plus adapté a tout les usages qu'ont peut en faire.
# Python et Ruby
Posté par alberthier (site web personnel) . Évalué à 0.
Ce que je trouve vraiment pénible en Python, c'est l'absence de protected/private pour les classes et non, le sale hack du double underscore __ ne me convient pas.
Et je trouve particulièrement chiant de devoir passer self en premier paramètre de toutes les methodes et de devoir faire self.toto pour accérer à chaque membre de ma classe.
Je trouve domage que Python 3 n'ait pas corrigé des deux points.
En plus en ruby, on a la possibilité de passer des blocs à des fonctions et c'est vraiment sympa.
Par contre je trouve la lib standard de Python un peu moins bordélique que celle de ruby. Dans ruby, ça ressemble vraiment à des bouts de code chopés à droite et à gauche sans vraiment de cohérence. Domage qu'aucun langage interprété n'ait de lib standard qui soit de la même qualité que l'API de Qt.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.