Antoine a écrit 5722 commentaires

Ou bien tu voulais parler de tout ces framework soit disant simplificateur de life, orientés objets, improved blabla

Oui mais les fichiers de config sont en XML. C'est un gage de robustesse.
(cf. dépêche récente sur Jelix, qui d'ailleurs commence par J comme Java et finit par X comme XML... symptôme d'un logiciel bien conçu)

Linuxfrench.net a été, de son temps, un des piliers parmis les sites libristes,

Heu, pilier de quoi ? De comptoir ?
Pardon pour le jeu de mots, mais Linuxfrench m'a toujours paru un site de médiocre qualité, avec des articles nombreux mais bâclés et une certaine propension à faire dans le style tabloïd.

Parce qu'au bout de quatre ans de CVS, une bonne partie des développeurs

- soit n'utilisent pas du tout CVS
- soit ne font qu'un commit (en fin de projet)
- soit utilisent CVS mais ont du mal

Pourquoi veux-tu une intégration CVS si CVS est à peine utilisé.

Je connais des devs qui refusent aussi d'utiliser un outil de gestion de versions, parce qu'ils sont "devs SQL", et que "CVS, c'est pas mon métier".

Avec ce genre d'arguments tu peux leur répondre que "bug tracker, c'est pas mon métier".

Ca a l'air agréable ta boîte, heu ton institut de statistiques.

C'est sûr que là, le prix du CD est abusif!

Et pourquoi donc ?
Des tests en aveugle sont menés régulièrement par des fous furieux (cf. forums hydrogenaudio), et il s'avère qu'avec les meilleurs compresseurs (lame dernière version), un MP3 aux alentours de 190 kbps est à peu près indiscernable de l'original.

Sans compter que les harmoniques au-delà de 22050 Hz sont théoriquement inaudibles, sauf pour certaines très rares personnes comme un des intervenants de ce fil.

Justement, si on habituait les gens à apprécier la dynamique...

Eh bien justement les concerts de rock c'est assez pourri au niveau dynamique.
Pourquoi ? Parce qu'au-delà de 110dB on atteint des niveaux dangereux (et je crois qu'il y a une interdiction légale aussi), et en-dessous de 80dB on est gêné par le bruit des voisins.

Donc voilà, si tu veux de la dynamique, écoute de bons disques à un niveau suffisamment élevé dans une pièce très calme.

Par exemple, si une cymbale émet un son à 23khz et un autre à 30khz, on entendra les 7khz d'écart. Enfin c'est l'idée, je me trompe peut-être un peu dans les détails...

Vu que les deux sons sont inaudibles pour l'oreille humaine, tu te trompes en effet "peut-être un peu dans les détails"... !!

les bons vieux CDs reprennent un coup de jeune

Avec ce genre d'affirmation stérile on ne va pas bien loin.

mais ceux-là, on n'en parle pas de la même façon.

Pardon, je ne suis pas responsable de ce que disent les autres ("on")...
Pour ce qui est de la dépendance aux entreprises j'ai même écrit un article qui examine des logiciels libres sous (entre autres) cet angle :
http://www.libroscope.org/Benchmark-23-logiciels-libres

Le message ci-dessus est humoristique mais c'est vrai qu'on peut se poser la question de la pertinence d'utiliser un logiciel de gestion de versions dont la survie est liée à une entreprise dont le comportement vis-à-vis du libre est assez mouvant (cf. Launchpad). Sans compter la tendance à faire du marketing à outrance.

Bon, c'est vrai que je suis biaisé car j'aime beaucoup Mercurial (autre système de gestion de versions distribué, aussi écrit en Python, et adopté par pas mal de projets libres) : http://www.selenic.com/mercurial/

Mais je crois que la distribution de package python est en pleine mutation, car aux EGGs, se rajoute encore les 2 systèmes concurrents entre eux : pycentral et python-support (exclusivement debian, non ?)

Ce n'est pas vraiment "concurrent". Chaque distribution a ses outils dédiés pour gérer les packages. Si ta distrib fournit le paquet que tu veux, et que tu n'as pas besoin de la toute dernière version, alors il est recommandé d'utiliser le paquet fourni par la distrib.

L'intérêt de setuptools c'est :
1. de donner accès à des tas de paquets (bibliothèques, programmes) qui ne sont pas intégrés par ta distrib. Tu tapes "easy_install nom_du_paquet" et c'est fait.
2. de te permettre d'installer facilement des versions "bleeding edge" voire des versions de développement si tu en as envie.

C'est un peu comme recompiler un programme depuis ses sources (./configure etc.), sauf que setuptools facilite largement la tâche en l'automatisant, ainsi que la gestion des dépendances vis-à-vis d'autres paquets setuptools.

Pour un développeur l'intérêt de setuptools est que c'est une méthode de déploiement qui marche sur toutes les plateformes, y compris sous Mac et Windows...

Pour le reste, elles sont surtout opportunistes et ne font que répondre à la demande de leurs clients.

Parce que ce n'est pas le cas des SSLL peut-être ? Mort de rire.

La GPL3 proteste & Stallman avec :)

La GPL3 n'a rien à voir avec les services Web, c'est de l'AGPL qu'il fallait parler.

Heu, vu ce que fait setuptools en standard, il ne doit pas manquer grand'chose pour lui faire créer des deb automatiquement (il y a déjà une commande bdist_rpm, mais pas bdist_deb).
En cherchant un peu sur Google, j'ai trouvé ça : http://easy-deb.sourceforge.net/ et ça : http://stdeb.python-hosting.com/
(je ne peux pas tester, je suis sous Mandriva :-))

Jarold Lanier [...] préconisait une approche plus basé sur la reconnaissance de forme.

Victoria Livschitz [...] cite aussi l'impossibilité pour une brique logiciel de s'adapter à un nouvel environnement, et partant, de la difficulté de créer des architectures pérennes.

Eh bien, j'espère que tes amis ont une carte de fidélité au bistrot du coin.
Comme dit Gombrowicz : « plus c'est intelligent, plus c'est con ! ».

[un objet] peut changer dynamiquement de parents à l'exécution

En Python, tu peux changer la classe d'un objet en affectant simplement l'attribut __class__, mais c'est une pratique considérée comme fort crade.

il faut bien voir qu'on a ici deux définition parallèle, et non successives

Tu peux regarder comment fonctionne VHDL, qui a exactement cette sémantique.

completion ne permettant pas de programmer rapidement

Prétendre que Java a pour avantage d'être rapide à taper, c'est vraiment se moquer du monde.

La relative pauvreté de java en fait un langage simple a parser

Heu, je ne sais pas pour Ruby mais Python est un langage ultra-simple syntaxiquement. Certainement beaucoup plus que Java ou C# avec leur myriade de mots-clés, modificateurs à la noix, tournures diverses et variées...

Voici un graphe de la grammaire de Python :
http://flickr.com/photos/nicksieger/281055485/
Comparaison avec Ruby :
http://www.flickr.com/photos/nicksieger/280661836/
Et avec Java :
http://flickr.com/photos/nicksieger/280662707/

En tout cas, ça a l'air sympa l'ambiance dans la communauté Rails. Frais, amical, décontracté... :-)

Java est quand même remarquable : c'est le seul langage (pardon, écosystème) où l'on considère qu'écrire des accesseurs et implémenter des « designs patterns » sont des problèmes de programmation en soi. Quoique la communauté PHP se rapproche dangereusement d'un tel niveau de stupidité...

L'intérêt de Java c'est que la bêtise verbeuse du langage alimente toute une industrie visant à « programmer mieux » (ou moins pire) : IDEs, littérature envahissante, perpétuation d'une caste de parasites (consultants spécialisés, « experts » pontifiants, etc.). Avec toutes ces couches de complexité surajoutées, on crée naturellement une barrière à l'entrée ce qui permet de protéger l'« industrie » du logiciel mal écrit et de l'incompétence (SSII), au détriment de tout le reste du monde informatique.

Le premier problème là-dedans c'est que "bien faire son métier" n'est pas équivalent à "satisfaire le client". Pour satisfaire le client, il vaut mieux éprouver beaucoup de difficultés à sortir le soft, faire des heures sup comme un taré et donner l'air de se démener comme un diable, que de produire une solution propre et intelligente qui aura demandé une quantité de travail raisonnable. Dans le premier cas, le client pense qu'il a vraiment fait une bonne affaire en payant peu cher une si grande quantité de travail, dans le second cas il a presque l'impression de se faire rouler ("si c'était aussi facile c'est que j'ai payé trop cher" : c'est l'inénarrable mentalité française).

Le deuxième problème c'est que bien faire son métier c'est aussi se préparer à l'avenir et améliorer son efficacité en se frottant à de nouvelles méthodes, de nouveaux outils. "Satisfaire le client" en faisant la maintenance de programmes écrits en COBOL ne remplit pas vraiment ce critère.

Le troisième problème c'est que le facteur plaisir dans le métier est important quoique tu en penses, sinon autant devenir trader pour s'en mettre plein les fouilles. De plus les gens qui éprouvent du plaisir à leur métier sont en général plus efficaces.

Après on peut faire des trucs propres en PHP, oui, et on peut même s'y amuser relativement (l'autre jour j'ai dû écrire un bout d'ORM dans ce merveilleux langage). Mais c'est comme utiliser un ersatz de langue française dont la moitié de la puissance d'expression serait passée à la trappe : c'est vite frustrant, sauf pour les rappeurs et les fans de l'oulipo.

Un fois que tu as choisi Gnome ou KDE tu peux utiliser au choix Firefox, Epiphany, Galeon, etc. sans être obligé de garder les autres sur ta machine.

Si tu veux utiliser l'aide de Gnome, tu es obligé de garder Gecko sur ta machine.

$ ldd /usr/bin/yelp | grep moz
libgtkembedmoz.so => /usr/lib/firefox-2.0.0.9/libgtkembedmoz.so (0xb6e51000)

(bon, c'est la première fois que j'essaie yelp depuis belle lurette, je redécouvre que c'est une belle merde... fin de la parenthèse)

Si tu veux utiliser le panneau de configuration KDE, tu es obligé de garder KHTML sur ta machine.

$ ldd /usr/bin/kcontrol | grep khtml
libkhtml.so.4 => /usr/lib/libkhtml.so.4 (0xb7aab000)


Je ne sais même pas comment retirer Outlook Express...

Heu.... Tu sais, Outlook Express ne va pas te faire des enfants dans le dos si tu ne l'utilises pas. A moins d'être un maniaque de la propreté de ton disque dur, je ne vois pas de raison de vouloir l'enlever. Je suis d'accord qu'un ordinateur ne contenant que le minimum nécessaire a un certain attrait esthétique, mais ce n'est pas vraiment un point de vue d'utilisateur.

Sous Linux on a vraiment le choix de remplacer un composant par un autre de fonctionnalité identique.

Mort de rire, et ils existent les composants de fonctionnalité identique ?
Par quoi peux-tu remplacer ton noyau Linux et faire tourner les mêmes modules ?
Par quoi peux-tu remplacer udev ? Comment fais-tu tourner les applis GTK avec un autre toolkit que GTK ? etc.

Je suis sûr que sous Windows, tu peux, si tu veux, utiliser un équivalent à l'Explorateur Windows et à des tas d'autres trucs (*). Si personne n'a écrit ces équivalents, ce n'est pas la faute à Microsoft, de même que si personne n'a écrit de remplaçant intégral au noyau Linux, ce n'est pas la faute de Torvalds....

(*) après tout, suffit de remplacer les DLL n'est-ce pas :-))

Avoir vraiment le choix ?

Oh qu'il est mignon le troll.

Sous Linux, tu as le choix de faire tourner ton ordinateur sans Perl (difficile vu la myriade d'outils de base qui l'utilisent), ou un X11 sans toute la panoplie de bibliothèques qui va avec ?

Microsoft a choisi d'utiliser les composants IE pour diverses parties du système, si çe ne te plaît pas, tu as en effet le choix... le choix de changer d'OS.

J'ai peut etre tout simplement pas envie de l'avoi sur mon pc.

C'est bien ce que je dis : si tu n'as pas envie d'avoir les fichiers d'IE sur ton PC (pauvre chou), tu n'as qu'à virer Windows. C'est aussi simple que ça.

Maintenant, tout le monde à part quelques zozos comme toi se fichent de savoir que, quand ils lancent Windows, il y a les fichiers d'IE quelque part sur le disque dur.

Lance windows update, et devine qu'est ce qu'il lance.

Oh, tu peux toujours essayer de lancer Windows Update sous Firefox... maintenant vu que Windows Update semble utiliser un composant ActiveX, je pense que ça n'ira pas très loin.
Et encore une fois, si tu n'es pas content, libre à toi de coder autre chose, de même que si tu n'es pas content d'avoir des outils d'admin en Perl sur ta machine, libre à toi de les recoder en Python/Ruby/Cobol.NET/etc.

En même temps les guillements officiels en langue française c'est plutôt « ceux-là » (dommage que Templeet n'ajoute pas les espaces insécables automatiquement comme le fait SPIP, mais c'est peut-être trop demander à un logiciel si moderne :-)).

Ca dépend des conventions en cours dans les différents langages.

En C il me semble que le mixedCase est quasi-proscrit, l'habitude étant plutôt aux minuscules_avec_des_underscores.
En Python la convention recommandée (PEP 8) est CamelCase pour les noms de classe, et minuscules_avec_underscores pour les variables, fonctions et méthodes.

Note que le mixedCase est assez pénible quand tu as des attributs qui correspondent à des colonnes dans une base de données par exemple.

Par ailleurs avec un clavier AZERTY le mixedCase est plus pénible à taper que les minuscules_avec_underscores, car le '_' ne demande pas l'utilisation de la touche shift.

C'est vrai que dans les langages de mangeurs de quiche (Java, PHP), le mixedCase semble s'être imposé (de façon totalement absurde en PHP où les noms de fonctions sont de toute façon case-insensitive...).

Pourquoi il faut ajouter les __ dans la deuxième version en Python?

Précisément parce que tu n'es pas censé appeler cette méthode toi-même mais utiliser la fonction abs() à la place ;)
Python essaie de séparer protocole interne et API publique :
- le protocole interne, c'est mon_entier.__abs__()
- l'API publique, c'est abs(mon_entier) qui appelle en sous-main la méthode mon_entier.__abs__()

Dans un cas simple on ne voit pas trop la différence, mais ça se justifie dans des cas plus complexes (par exemple la transformation en chaîne unicode via unicode(objet) peut appeler objet.__str__() ou objet.__unicode__() selon que l'un ou l'autre est défini).

C'est utilisé aussi pour les opérateurs. Par exemple "a + b" appelle a.__add__(b).

Existerait-il une doc (à peu près à jour...) genre "Python en 30 mn pour ceux qui programment déjà dans un langage de script" ?

Le tutorial officiel :
http://docs.python.org/tut/tut.html
La documentation officielle des types intégrés et des modules standard :
http://docs.python.org/lib/lib.html

Il y a aussi Dive Into Python, qui commence à dater (2004) mais fournit une bonne introduction :
http://www.diveintopython.org/