Je fais souvent des softs PyQt pour windows, c'est assez facile. Py2exe ou pyinstaller marchent très bien. Et c'est trivial à packager par la suite avec InnoSetup.
J'aurai pas le temps de m'en occuper pour pymecavideo, mais tu peux t'inspirer de ce que j'ai fait sur d'autres softs.
Il faut regarder les fichiers make-exe.py et pyticroque-inno.in.iss
Je fonctionne avec un script python qui me fait à coup de ligne de commande :
- packaging en .exe
- packaging du .exe en installeur
- packaging du .exe en zip
- packaging des sources en zip
- upload de l'installeur, du zip et des sources
Je recommande fortement, ca permet de faire des release super vite.
Si t'as des questions, hésite pas à me contacter (phil at freehackers dot org)
J'étais tout réjoui de savoir que je pouvais scripter OO en python.
Jusqu'à ce que j'essaye.
De tête, si je me souviens bien :
- on peut utiliser uniquement la version de python livrée dans le repertoire d'OO. Pas de py2exe, pas de python standard
- par défaut, OO n'est pas scriptable en python. Il faut lancer un OO en mode serveur et à ce moment, on peut ouvrir d'autres OO qui serviront de client
- la façon de distribuer des scripts Python pour OO et de les lancer me semble hyper compliqué pour un utilisateur.
Du coup, j'ai regardé si je pouvais scripter Excel en python. En 10 minutes, j'ai réussi à faire ce que je voulais.
« Venir après pleurnicher que GNOME impose ses technos »
Je tiens à préciser que DBUS ne rentre pas pour moi dans la liste des technos imposées ou standardisée en force par Gnome.
Au contraire, c'est plutôt un modèle de comment il faut faire. Il y avait un besoin pour un outil, pour lequel DCOP avait des principes intéressants mais ne répondait pas à l'ensemble du besoin. Havoc avait donc un objectif clair, et a écouté très attentivement le feedback de KDE, les a intégré au processus (même si on peut regretter qu'ils n'aient pas été plus présent, comme tu le soulignes ils ont quand même participé).
Au final, la transition DCOP -> DBUS a pu se faire en douceur pour KDE, et KDE a pu profiter des avantages de DBUS par rapport à DCOP.
Ce processus de standardisation inter-desktop s'est produit plusieurs fois avec succès, avec par exemple les fichiers .desktop (format proposé par KDE), les notifications (spec conjointe KDE / Gnome basée sur XEmbed), les extensions du protocole X, les formats des thèmes. On trouve moins d'exemples récents cependant, probablement parce que les parties qui restent à faire collaborer sont autrement plus complexes.
Quand je parlais de technos Gnome qui veulent passer en force sur xdg, je pensais à des cas où la consultation de KDE n'a pas eu lieu, ou à des cas où elle a eu lieu mais les retours ont été ignorés.
« Tu as des pans entiers de Qt4 qui n'ont pas d'équivalents dans Qt3 ou qui ont été complétement réécrits. Le portage de Qt3 vers Qt4 n'a rien de trivial, il a fallu rajouter un module de compatibilité qt3support pour faciliter le portage. »
Une application qui fonctionne avec qt3support est une application qui fonctionne pour Qt4 donc je maintiens que c'est rapide de porter une application vers Qt4.
Apres, vouloir s'affranchir de qt3support est a priori une bonne idée mais pas du tout nécessaire.
« Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe »
Je suis pas super à jour mais je crois que tu as raison. Il ne semble pas y avoir de solution idéale, car je peux pas dire que j'entende que des gens satisfaits du son côté Gnome.
« DCOP n'était pas utilisable dans un contexte autre que KDE. »
Tout à fait faux. Il y avait une dépendance à Qt du à l'utilisation de containers Qt. Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante. Ceci n'est pas différente de la situation actuelle ou l'implémentation de DBUS dépend si je m'abuse de gobject.
Il restait à DCOP la dépendance a libice qui est beaucoup moins pratique mais DCOP était tout à fait utilisable en dehors de KDE, et je crois même qu'il a été utilisé de façon très mineure sans KDE.
Mais on peut pas en même temps reprocher à KDE de réécrire des composants et lui reprocher d'utiliser un composant existant, à savoir libice.
« DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP. »
Je serai curieux de savoir ce que DBUS empreinte a bonobo ou Corba. De ce que j'en sais, rien du tout. Pour moi, ca reste un DCOP amélioré.
Je trouve ça particulièrement ironique quand on sait à quel point KDE s'est fait craché dessus quand ils ont osé utiliser DCOP plutôt que Corba lors du passage de KDE1 à KDE2.
« J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années. »
De mon point de vue, ils l'ont regardé avec scepticisme, puis curiosité, puis l'ont adapté au vu des apports majeurs en terme d'interopérabilité (alors que fondamentalement, DBUS apporte peu à KDE en comparaison de DCOP). En tout cas, j'appelle pas ça royalement ignorer.
« développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop »
Il semble que nous ayons tous les deux exemples concrets où la discussion n'a pas eu lieu et où des comportements anti-coopération ont eu lieu à la place, que ce soit pour des technos proposés par KDE ou par Gnome.
Notamment, on a vu des exemples récents de technos discutés sur freedesktop, où le feedback de KDE a été complètement ignoré, et le dev Gnome en question a choisi volontairement des choix incompatible avec l'existant chez KDE.
Pour ce qui est de PolicyKit, l'idée par exemple est bonne et a été adoptée par KDE à la place de KDESu si j'ai bien suivi. Mais peut-on reprocher à KDE de ne pas avoir proposer KDESu à Gnome en 1999 ?
« Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. »
On doit pas avoir la même définition de « la plupart du temps ». Je dirai pour ma part que une fois sur deux, des développeurs provenant de Gnome tentent d'imposer des technos sur xdg sans tenir compte de l'existant de KDE ou bien encore des besoins de KDE pour permettre une adoption partagé.
Les exemples que tu as cité sont plutôt des réussites, mais n'effacent pas les autres tentatives d'abus de standardisation. Cela dit, ce n'est pas un choix politique de Gnome, c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
« Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop. »
Je suis d'accord mais en même temps, il y a eu tellement de fois où les efforts de coopération ont été ignorés que bcp de developpeurs de KDE ne font pas confiance à freedesktop au dela du minimum syndical (en encore).
Je sens le besoin d'apporter quelques commentaires :
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon. Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.
C'est quand même un peu facile de mettre tout sur le dos de Microsoft. Genre sans Microsoft, la norme aurait été pondue en deux mois et de façon impeccable.
On pourrait tout aussi bien dire que c'est la faute de Red Hat et Sun et KDE, qui n'ont pas employé assez de monde pour se concentrer uniquement sur ce sujet stratégique qu'est ODF et que à cause de ça, ca avance lentement. Et ça se tient tout à fait, si chacune des boites du libre avait dépéché 30 mecs qui avaient passé plusieurs années à plancher et sur ODF, et sur la norme Ms, ODF 1.2 serait sorti bien plus vite.
D'ailleurs, je soupçonne aussi que l'obésité est responsable de ce retard: en effet, l'obésité entraîne une baisse de fertilité, ce qui diminue la population, donc le nombre d'informaticiens et au passage, le nombre d'informaticiens capable d'intervenir sur la norme ODF.
Sus au hamburger, comme ça, on aura ODF 1.3 bien plus rapidement !
Trêve de plaisanterie, je rejoins PBPG, t'es pas crédible à raconter que tout est la faute de MS.
C'est bien plus crédible de souligner la difficulté de faire une norme interopérable, sur des sujets aussi complexe que ce que vise ODF, et qu'il a fallu aussi tenir compte du feedback de ODF 1.1 qui montre des interprétations divergentes, et que les gens ont aussi été occupé à sortir des nouvelles versions de leurs logiciels (OpenOffice, KOffice en tout cas).
Bref, moins de mauvaise foi, plus d'infos, ça fait toujours du bien.
J'aime bien aussi, je m'en suis servi pour debugger un peu des services XMLRPC .
C'est aussi pratique pour savoir si il y a du monde qui "téléphone à la maison".
Par contre, pour une utilisation rapide, impossible pour moi de comprendre quoi que ce soit aux filtres et surlignement. Je m'en suis sorti sans mais ça a pas l'air trivial.
Je suis d'accord. Je trouve ça notamment bizarre que il soit possible d'utiliser le mode raster en passant un argument en ligne de commande, mais que pour l'utiliser par défaut, il faille recompiler Qt.
D'autant plus qu'il me semble que Qt a maintenant un petit fichier de config dans le répertoire utilisateur.
« Il y a juste des probabilités importante qu'un logiciel libre soit plus "propre" qu'un logiciel propriétaire qui est souvent écrit vite dans le but d'être rentable le plus rapidement possible. »
C'est vraiment de la généralisation à deux balles.
Ce n'est pas parce qu' un logiciel est propriétaire qu'il a des deadline absolues.
Ce n'est pas non plus parce qu'un logiciel est propriétaire que le département responsable de la qualité du code n'intervient pas pour protester.
Ce n'est pas parce qu'un logiciel est libre et a du temps pour sortir ses versions qu'il n'est pas écrit par un pauvre étudiant qui débute en programmation et te fous plein de bugs partout.
Ce n'est pas parce qu'un logiciel est libre qu'un contributeur bénévole a du temps pour corriger tous les bugs identifiés.
Au final, je pense que les probabilités d'avoir du bon code dans un logiciel sont équivalentes en libre comme en proprio. La seule différence, c'est que sur du proprio, tu ne peux en général pas le vérifier.
J'ai vu pour ma part autant de bouses en logiciel libre qu'en logiciel proprio.
Moi je fais aussi des fichiers de config en python, mais j'évite d'y mettre des structures complexes comme des classes. Mes fichiers de config python ne contiennent que des listes, de chaînes de caractères, des dictionnaires et des nombres. Pour les parser, j'utilise safe_eval : http://code.activestate.com/recipes/496746/
Pour moi les avantages sont les suivantes :
- je garde la distinction entre fichier de config contenant des données et fichier exécutable
- le format est super facile à faire évoluer
- c'est très facile à modifier même quand on est pas développeur.
Cher Fabien, je pense que tu es profondément naïf sur la réalité du fonctionnement du business des jeux video.
Le modèle que tu décris a vraiment très très peu de chance de rentabiliser un jeu video. Une chance infime. Qq'un qui a investi énormément de son temps à développer un jeu video de bonne qualité ne va pas prendre le risque de tout perdre pour la beauté des remerciements sur linuxfr.
On est vraiment dans des réflexions de comptoire (et encore, il y a quand même des plus intelligentes).
Si un créateur de jeu veut vivre de son art, ta proposition en gros, c'est qu'il a qu'à pas le faire. C'est sur que avec des propositions comme ça, la création de jeux libres ne peut que mieux se porter.
Ah c'est sûr qu'avec des produits comme ça t'es pas prêt de trouver un business model pour les jeux vidéos dans le libre
Au contraire c'est parce qu'ils font le choix du non libre qu'ils trouvent justement un business model. Tous les autres efforts de jeux video libres se sont misérablement planté. Il y a peut-être quelque chose à comprendre la-dedans qui t'a échappé.
J'ai pris un tableau d'entier pour simplifier mais il est évident que l'utilisation d'une boucle avec ce type de complexité en C++ ne se justifie que par exemple pour parcourir une structure custom (genre arbre) qui te retourne un itérateur, et qui contient aussi une structure custom.
Dans ce cas, la STL est bien adapté et la syntaxe est bien celle que je décris, en python comme en C++.
L'avantage des délimiteurs est justement de rendre le code lisible sans ambiguïtés quelque soit le style choisit par le programmeur.
Note que le seul cas où il y a ambiguïté visuelle en Python est le cas où d'une part, le programmeur a mélangé allègrement tabulation et espaces, et d'autre part, ton éditeur n'est pas configuré comme l'éditeur de l'auteur original (et encore, uniquement dans un mode défavorable; s'il a choisi 2 espaces pour une tabulation et que tu en utilises 8, le code sera encore lisible parfaitement). Si t'es sous vim, tu pourras rectifier la situation en 3 secondes et ça doit être possible sous d'autres éditeurs.
Note que la même situation peut se produire avec du C++. Le code sera tout aussi moche et plein d'ambiguïtés visuelles, mais tu pourras encore le compiler. Est-ce que c'est mieux ou moins bien ? je ne saurai dire...
D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :
int * a, b, c, d; // oops, qui est un pointeur et qui ne l'est pas ? Ou est donc l'aide des délimiteurs ?
for( i=0, i < 10, i++) // ah ah, le délimiteur me fait-il sauter aux yeux cette erreur de syntaxe pourtant patente ?
for( i=0; i <37 && pasFini == true; i++ ) ; {
.... // fait des trucs mais il ne le fait qu'une fois au lieu de 37 fois. Merci aux délimiteurs.
}
Je ne suis pas non plus d'accord que les délimiteurs rendraient le code plus lisible. Après quelques années à faire du python et à me déshabituer de la syntaxe C/C++, un code chargé de symboles abscons comme ces deux derniers langages me semble beaucoup plus illisible que du code python qui me semble clair et surtout aéré.
Aller, un petit exemple à deux balles :
l = [1,2,3,4,5]
for i in l :
.... print i
int array[] = { 1, 2, 3, 4 ,5 };
std::vector l( array, array + sizeof( array ) / sizeof( int ) );
for( std::vector::iterator it = l.start(); it != l.end(); ++it ) {
.... printf( "%d\n", *it );
}
Merci à linuxfr qui ne permet pas de taper facilement du code !
En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.
Donc pour en revenir à nos moutons, en ce qui me concerne, je me réjouis que les concepteurs d'un nouveau langage pensent aussi à sa lisibilité en utilisant une syntaxe légère. Les jeunes barbus sont choqués, les vieux barbus regardent ça avec une moue dédaigneuse et un vague sourire en coin (ah plan 9, ça, c'était quelque chose) et les jeunes boutonneux regardent soit avec un enthousiasme démesuré, soit avec des yeux de merlans frits.
Si tu juges un langage uniquement sur sa syntaxe, ben ... je sais pas trop quoi dire mais ça me parait tellement réducteur. Certes, la syntaxe n'est pas anodine et je peste sur la syntaxe old school de CMake par exemple, mais de là à refuser d'utiliser un outil parce que sa syntaxe est pourrie, ça me dépasse. Quid de la facilité d'utilisation en général, de la pertinence à résoudre simplement ou pas les problèmes qui se posent à toi, du jeu de bibliothèque, de l'expressivité du code, de la maintenabilité, de l'intérêt des nouveaux concepts, de la performance, de la portabilité ?
De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.
Une indentation bien particulière oui. Poser plus de problèmes qu'elle n'en résout, je suis pas d'accord. Le code est plus lisible, il y a moins de caractères à taper, et il est indenté de façon uniforme. Bon, de toute façon, j'ai jamais compris cet argument. C'est OK d'imposer un langage de programmation pour donner des ordres à un ordinateur, c'est ok d'utiliser une indentation cohérente pour faciliter la séparation sémantique des blocs mais c'est pas ok que cette séparation sémantique fasse partie du langage. C'est ok de forcer à utiliser un point-virgule à la fin de chaque ligne, c'est ok d'utiliser plein de caractères ésotériques pour la programmation ( &!<*{;]:?}[ ) mais c'est pas ok d'avoir moins de caractères pour programmer.
Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.
De même, un codeur (comme moi) qui lit du ruby dit : j'y comprends rien. Et il dit la même chose quand il lit du lua, du perl, du SmallTalk, du lissac, du Haskell et du LISP. Mais avant de dire que le langage est une grosse merde et le codeur un gros brlanleur, je me dis que peut-être je devrai me documenter un peu plus sur le langage.
Note qu'il existe aussi pleins d'erreurs qu'un compilateur de langage statique ne décelera jamais.
Tu as raison sur le fait que malgré tous les argument qu'on peut avancer, au final, la syntaxe de Python peut introduire des bugs qui peuvent générer une exception qui font planter l'application alors que certains de ces problèmes auraient été attrapés par des langages à vérification de typage statique type C++.
Et pourtant, mon expérience personnelle, qui semble partagée, est que mes programmes C++ ont bien plus de bugs que mes programmes Python.
On peut réfléchir à d'autres aspects. Par exemple, une étude d'IBM montrait que le nombre de bugs produit par un programmeur donné par nombre de lignes tapées est constant quel que soit le langage utilisé.
Certaines constructions en python peuvent faire en 3 lignes ce qui prend une dizaine voire une vingtaine de ligne en C++. Ceci expliquerait peut-être cela, tout n'est pas dans le typage, statique ou pas, mais plus dans l'esprit du langage.
On parle d'un langage développé en Open Source, incidemment par des employés de google. On parle ensuite des limitations techniques de Python, notamment dans le cadre d'application qui doivent tenir une très forte montée en charge et tu ressors le vieux laïus du grand méchant google.
[mode offensif] Tu le sors à chaque fois qu'il y a qu'il y a marqué google dans un commentaire ?
Le tout est de faire les delete dès que possible, sans les accumuler pour les faire plus tard.
Ca, c'est assez naïf comme vision. Justement, dans un jeu video où il y a beaucoup de temps réel, reporter un delete a plus tard peut être très important. Et si les delete se produisent de façon automatique, cela peut créer de vrais problèmes puisqu'il ne devient plus possible de le reporter.
Il y a justement une discussion sur ce sujet (l'utilisation de Python par google) sur la liste de Unladen Swallow. La conclusion est simple et sans fioriture : google aime bien python mais il y a plein de tâches pour lequel il n'est pas du tout adapté.
Par un des auteurs de Unladen Swallow :
Well, simple common sense is going to limit Python's applicability when operating at Google's scale: it's not as fast as Java or C++, threading sucks, memory usage is higher, etc. One of the design constraints we face when designing any new system is, what happens when the load goes up by 10x or 100x? What happens if the whole planet thinks your new service is awesome? Any technology that makes satisfying that constraint harder -- and I think Python falls into this category -- *should* be discouraged if it doesn't have a very strong case made in its favor on other merits.
Moi j'aime bien l'idée d'avoir des interfaces à la duck-typing.
Le modèle de classe / méthode me fait penser à la simplicité de lua, ce qui permet de l'optimiser à donf sans passer par des tables de fonctions virtuelles.
# Trucs pour la version Windows
Posté par Philippe F (site web personnel) . En réponse au journal Pymecavideo devient multiplateforme. Évalué à 6.
J'aurai pas le temps de m'en occuper pour pymecavideo, mais tu peux t'inspirer de ce que j'ai fait sur d'autres softs.
Par exemple :
http://labs.freehackers.org/projects/pyticroque/repository/s(...)
Il faut regarder les fichiers make-exe.py et pyticroque-inno.in.iss
Je fonctionne avec un script python qui me fait à coup de ligne de commande :
- packaging en .exe
- packaging du .exe en installeur
- packaging du .exe en zip
- packaging des sources en zip
- upload de l'installeur, du zip et des sources
Je recommande fortement, ca permet de faire des release super vite.
Si t'as des questions, hésite pas à me contacter (phil at freehackers dot org)
# Scripter OpenOffice en python : bof !
Posté par Philippe F (site web personnel) . En réponse à la dépêche OpenOffice.org 3.2 est disponible. Évalué à 2.
Jusqu'à ce que j'essaye.
De tête, si je me souviens bien :
- on peut utiliser uniquement la version de python livrée dans le repertoire d'OO. Pas de py2exe, pas de python standard
- par défaut, OO n'est pas scriptable en python. Il faut lancer un OO en mode serveur et à ce moment, on peut ouvrir d'autres OO qui serviront de client
- la façon de distribuer des scripts Python pour OO et de les lancer me semble hyper compliqué pour un utilisateur.
Du coup, j'ai regardé si je pouvais scripter Excel en python. En 10 minutes, j'ai réussi à faire ce que je voulais.
J'espère que la situation s'est améliorée...
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 3.
Je tiens à préciser que DBUS ne rentre pas pour moi dans la liste des technos imposées ou standardisée en force par Gnome.
Au contraire, c'est plutôt un modèle de comment il faut faire. Il y avait un besoin pour un outil, pour lequel DCOP avait des principes intéressants mais ne répondait pas à l'ensemble du besoin. Havoc avait donc un objectif clair, et a écouté très attentivement le feedback de KDE, les a intégré au processus (même si on peut regretter qu'ils n'aient pas été plus présent, comme tu le soulignes ils ont quand même participé).
Au final, la transition DCOP -> DBUS a pu se faire en douceur pour KDE, et KDE a pu profiter des avantages de DBUS par rapport à DCOP.
Ce processus de standardisation inter-desktop s'est produit plusieurs fois avec succès, avec par exemple les fichiers .desktop (format proposé par KDE), les notifications (spec conjointe KDE / Gnome basée sur XEmbed), les extensions du protocole X, les formats des thèmes. On trouve moins d'exemples récents cependant, probablement parce que les parties qui restent à faire collaborer sont autrement plus complexes.
Quand je parlais de technos Gnome qui veulent passer en force sur xdg, je pensais à des cas où la consultation de KDE n'a pas eu lieu, ou à des cas où elle a eu lieu mais les retours ont été ignorés.
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 3.
Maintenant que nous somme plus ou moins d'accord, il reste plus quà nous serrer la main respectueusement en souhaitant bon vent...
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 5.
Une application qui fonctionne avec qt3support est une application qui fonctionne pour Qt4 donc je maintiens que c'est rapide de porter une application vers Qt4.
Apres, vouloir s'affranchir de qt3support est a priori une bonne idée mais pas du tout nécessaire.
« Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe »
Je suis pas super à jour mais je crois que tu as raison. Il ne semble pas y avoir de solution idéale, car je peux pas dire que j'entende que des gens satisfaits du son côté Gnome.
« DCOP n'était pas utilisable dans un contexte autre que KDE. »
Tout à fait faux. Il y avait une dépendance à Qt du à l'utilisation de containers Qt. Il suffirait (dixit le concepteur) de quelques heures de travail pour en faire une implémentation indépendante. Ceci n'est pas différente de la situation actuelle ou l'implémentation de DBUS dépend si je m'abuse de gobject.
Il restait à DCOP la dépendance a libice qui est beaucoup moins pratique mais DCOP était tout à fait utilisable en dehors de KDE, et je crois même qu'il a été utilisé de façon très mineure sans KDE.
Mais on peut pas en même temps reprocher à KDE de réécrire des composants et lui reprocher d'utiliser un composant existant, à savoir libice.
« DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP. »
Je serai curieux de savoir ce que DBUS empreinte a bonobo ou Corba. De ce que j'en sais, rien du tout. Pour moi, ca reste un DCOP amélioré.
Je trouve ça particulièrement ironique quand on sait à quel point KDE s'est fait craché dessus quand ils ont osé utiliser DCOP plutôt que Corba lors du passage de KDE1 à KDE2.
« J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années. »
De mon point de vue, ils l'ont regardé avec scepticisme, puis curiosité, puis l'ont adapté au vu des apports majeurs en terme d'interopérabilité (alors que fondamentalement, DBUS apporte peu à KDE en comparaison de DCOP). En tout cas, j'appelle pas ça royalement ignorer.
« développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop »
Il semble que nous ayons tous les deux exemples concrets où la discussion n'a pas eu lieu et où des comportements anti-coopération ont eu lieu à la place, que ce soit pour des technos proposés par KDE ou par Gnome.
Notamment, on a vu des exemples récents de technos discutés sur freedesktop, où le feedback de KDE a été complètement ignoré, et le dev Gnome en question a choisi volontairement des choix incompatible avec l'existant chez KDE.
Pour ce qui est de PolicyKit, l'idée par exemple est bonne et a été adoptée par KDE à la place de KDESu si j'ai bien suivi. Mais peut-on reprocher à KDE de ne pas avoir proposer KDESu à Gnome en 1999 ?
« Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. »
On doit pas avoir la même définition de « la plupart du temps ». Je dirai pour ma part que une fois sur deux, des développeurs provenant de Gnome tentent d'imposer des technos sur xdg sans tenir compte de l'existant de KDE ou bien encore des besoins de KDE pour permettre une adoption partagé.
Les exemples que tu as cité sont plutôt des réussites, mais n'effacent pas les autres tentatives d'abus de standardisation. Cela dit, ce n'est pas un choix politique de Gnome, c'est juste que certains développeurs n'ont pas compris le concept de standard et se prennent pour Microsoft.
« Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop. »
Je suis d'accord mais en même temps, il y a eu tellement de fois où les efforts de coopération ont été ignorés que bcp de developpeurs de KDE ne font pas confiance à freedesktop au dela du minimum syndical (en encore).
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 9.
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon. Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.
[^] # Re: Hahaha
Posté par Philippe F (site web personnel) . En réponse au journal ODF 1.2 part 1 pret pour les revisions. Évalué à 4.
On pourrait tout aussi bien dire que c'est la faute de Red Hat et Sun et KDE, qui n'ont pas employé assez de monde pour se concentrer uniquement sur ce sujet stratégique qu'est ODF et que à cause de ça, ca avance lentement. Et ça se tient tout à fait, si chacune des boites du libre avait dépéché 30 mecs qui avaient passé plusieurs années à plancher et sur ODF, et sur la norme Ms, ODF 1.2 serait sorti bien plus vite.
D'ailleurs, je soupçonne aussi que l'obésité est responsable de ce retard: en effet, l'obésité entraîne une baisse de fertilité, ce qui diminue la population, donc le nombre d'informaticiens et au passage, le nombre d'informaticiens capable d'intervenir sur la norme ODF.
Sus au hamburger, comme ça, on aura ODF 1.3 bien plus rapidement !
Trêve de plaisanterie, je rejoins PBPG, t'es pas crédible à raconter que tout est la faute de MS.
C'est bien plus crédible de souligner la difficulté de faire une norme interopérable, sur des sujets aussi complexe que ce que vise ODF, et qu'il a fallu aussi tenir compte du feedback de ODF 1.1 qui montre des interprétations divergentes, et que les gens ont aussi été occupé à sortir des nouvelles versions de leurs logiciels (OpenOffice, KOffice en tout cas).
Bref, moins de mauvaise foi, plus d'infos, ça fait toujours du bien.
[^] # Re: Alternatives ?
Posté par Philippe F (site web personnel) . En réponse au journal WireShark la capture réseau. Évalué à 2.
C'est aussi pratique pour savoir si il y a du monde qui "téléphone à la maison".
Par contre, pour une utilisation rapide, impossible pour moi de comprendre quoi que ce soit aux filtres et surlignement. Je m'en suis sorti sans mais ça a pas l'air trivial.
[^] # Re: Fichier de config
Posté par Philippe F (site web personnel) . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 3.
D'autant plus qu'il me semble que Qt a maintenant un petit fichier de config dans le répertoire utilisateur.
[^] # Re: Diantre
Posté par Philippe F (site web personnel) . En réponse à la dépêche Jabber.org se tourne vers un serveur propriétaire. Évalué à 5.
C'est vraiment de la généralisation à deux balles.
Ce n'est pas parce qu' un logiciel est propriétaire qu'il a des deadline absolues.
Ce n'est pas non plus parce qu'un logiciel est propriétaire que le département responsable de la qualité du code n'intervient pas pour protester.
Ce n'est pas parce qu'un logiciel est libre et a du temps pour sortir ses versions qu'il n'est pas écrit par un pauvre étudiant qui débute en programmation et te fous plein de bugs partout.
Ce n'est pas parce qu'un logiciel est libre qu'un contributeur bénévole a du temps pour corriger tous les bugs identifiés.
Au final, je pense que les probabilités d'avoir du bon code dans un logiciel sont équivalentes en libre comme en proprio. La seule différence, c'est que sur du proprio, tu ne peux en général pas le vérifier.
J'ai vu pour ma part autant de bouses en logiciel libre qu'en logiciel proprio.
[^] # Re: Désinscriptions
Posté par Philippe F (site web personnel) . En réponse au journal Web 2.0 Suicide Machine. Évalué à 4.
Les scripts qu'ils ont mis en place vont supprimer une par une toutes ces informations avant de fermer ton compte.
[^] # Re: Code source
Posté par Philippe F (site web personnel) . En réponse au journal Web 2.0 Suicide Machine. Évalué à 6.
Améliorable ne veut pas dire qu'elle sera améliorée. Combien de logiciels libres pourrissent avec un seul unique contributeur dans son coin ?
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 3.
http://code.activestate.com/recipes/364469/
[^] # Re: Vachement gore
Posté par Philippe F (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 3.
http://code.activestate.com/recipes/496746/
Pour moi les avantages sont les suivantes :
- je garde la distinction entre fichier de config contenant des données et fichier exécutable
- le format est super facile à faire évoluer
- c'est très facile à modifier même quand on est pas développeur.
[^] # Re: gratte-gratte ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Machinarium, un nouveau jeu pour Linux. Évalué à 2.
Le modèle que tu décris a vraiment très très peu de chance de rentabiliser un jeu video. Une chance infime. Qq'un qui a investi énormément de son temps à développer un jeu video de bonne qualité ne va pas prendre le risque de tout perdre pour la beauté des remerciements sur linuxfr.
[^] # Re: gratte-gratte ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Machinarium, un nouveau jeu pour Linux. Évalué à 1.
Si un créateur de jeu veut vivre de son art, ta proposition en gros, c'est qu'il a qu'à pas le faire. C'est sur que avec des propositions comme ça, la création de jeux libres ne peut que mieux se porter.
[^] # Re: gratte-gratte ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Machinarium, un nouveau jeu pour Linux. Évalué à 4.
Au contraire c'est parce qu'ils font le choix du non libre qu'ils trouvent justement un business model. Tous les autres efforts de jeux video libres se sont misérablement planté. Il y a peut-être quelque chose à comprendre la-dedans qui t'a échappé.
[^] # Re: Première remarques
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 2.
Dans ce cas, la STL est bien adapté et la syntaxe est bien celle que je décris, en python comme en C++.
[^] # Re: Première remarques
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 7.
Note que le seul cas où il y a ambiguïté visuelle en Python est le cas où d'une part, le programmeur a mélangé allègrement tabulation et espaces, et d'autre part, ton éditeur n'est pas configuré comme l'éditeur de l'auteur original (et encore, uniquement dans un mode défavorable; s'il a choisi 2 espaces pour une tabulation et que tu en utilises 8, le code sera encore lisible parfaitement). Si t'es sous vim, tu pourras rectifier la situation en 3 secondes et ça doit être possible sous d'autres éditeurs.
Note que la même situation peut se produire avec du C++. Le code sera tout aussi moche et plein d'ambiguïtés visuelles, mais tu pourras encore le compiler. Est-ce que c'est mieux ou moins bien ? je ne saurai dire...
D'ailleurs, ton affirmation que les délimiteurs rendent le code sans ambiguïté peut facilement être remise en question. Je te sors quelques classiques :
int * a, b, c, d; // oops, qui est un pointeur et qui ne l'est pas ? Ou est donc l'aide des délimiteurs ?
for( i=0, i < 10, i++) // ah ah, le délimiteur me fait-il sauter aux yeux cette erreur de syntaxe pourtant patente ?
for( i=0; i <37 && pasFini == true; i++ ) ; {
.... // fait des trucs mais il ne le fait qu'une fois au lieu de 37 fois. Merci aux délimiteurs.
}
Je ne suis pas non plus d'accord que les délimiteurs rendraient le code plus lisible. Après quelques années à faire du python et à me déshabituer de la syntaxe C/C++, un code chargé de symboles abscons comme ces deux derniers langages me semble beaucoup plus illisible que du code python qui me semble clair et surtout aéré.
Aller, un petit exemple à deux balles :
l = [1,2,3,4,5]
for i in l :
.... print i
int array[] = { 1, 2, 3, 4 ,5 };
std::vector l( array, array + sizeof( array ) / sizeof( int ) );
for( std::vector::iterator it = l.start(); it != l.end(); ++it ) {
.... printf( "%d\n", *it );
}
Merci à linuxfr qui ne permet pas de taper facilement du code !
En tout cas, les deux exemples font la même chose, je continue à trouver la version python plus lisible. Et je n'ai pas triché sur le C++, j'ai utilisé la méthode officielle d'itérer sur un tableau STL.
Donc pour en revenir à nos moutons, en ce qui me concerne, je me réjouis que les concepteurs d'un nouveau langage pensent aussi à sa lisibilité en utilisant une syntaxe légère. Les jeunes barbus sont choqués, les vieux barbus regardent ça avec une moue dédaigneuse et un vague sourire en coin (ah plan 9, ça, c'était quelque chose) et les jeunes boutonneux regardent soit avec un enthousiasme démesuré, soit avec des yeux de merlans frits.
[^] # Re: Première remarques
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 8.
De la même manière que je ne fait pas de python à cause de cette indentation qu'il faut faire d'une manière bien particulière et que j'ai toujours vu poser plus de problèmes qu'elle n'en résout.
Une indentation bien particulière oui. Poser plus de problèmes qu'elle n'en résout, je suis pas d'accord. Le code est plus lisible, il y a moins de caractères à taper, et il est indenté de façon uniforme. Bon, de toute façon, j'ai jamais compris cet argument. C'est OK d'imposer un langage de programmation pour donner des ordres à un ordinateur, c'est ok d'utiliser une indentation cohérente pour faciliter la séparation sémantique des blocs mais c'est pas ok que cette séparation sémantique fasse partie du langage. C'est ok de forcer à utiliser un point-virgule à la fin de chaque ligne, c'est ok d'utiliser plein de caractères ésotériques pour la programmation ( &!<*{;]:?}[ ) mais c'est pas ok d'avoir moins de caractères pour programmer.
Un codeur qui ne connait rien à Go, lorsqu'il va voir du code avec des nom en majuscule et d'autre en minuscule, il va se dire que le programmeur est un branleur qui pourrait au moins faire un code homogène ; il se dira surement pas : à tiens, ça doit surement servir à dire au compilateur qu'elle sont les méthodes externes.
De même, un codeur (comme moi) qui lit du ruby dit : j'y comprends rien. Et il dit la même chose quand il lit du lua, du perl, du SmallTalk, du lissac, du Haskell et du LISP. Mais avant de dire que le langage est une grosse merde et le codeur un gros brlanleur, je me dis que peut-être je devrai me documenter un peu plus sur le langage.
[^] # Re: Typage statique/dynamique
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 5.
Tu as raison sur le fait que malgré tous les argument qu'on peut avancer, au final, la syntaxe de Python peut introduire des bugs qui peuvent générer une exception qui font planter l'application alors que certains de ces problèmes auraient été attrapés par des langages à vérification de typage statique type C++.
Et pourtant, mon expérience personnelle, qui semble partagée, est que mes programmes C++ ont bien plus de bugs que mes programmes Python.
On peut réfléchir à d'autres aspects. Par exemple, une étude d'IBM montrait que le nombre de bugs produit par un programmeur donné par nombre de lignes tapées est constant quel que soit le langage utilisé.
Certaines constructions en python peuvent faire en 3 lignes ce qui prend une dizaine voire une vingtaine de ligne en C++. Ceci expliquerait peut-être cela, tout n'est pas dans le typage, statique ou pas, mais plus dans l'esprit du langage.
[^] # Re: Python et Google
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 0.
On parle d'un langage développé en Open Source, incidemment par des employés de google. On parle ensuite des limitations techniques de Python, notamment dans le cadre d'application qui doivent tenir une très forte montée en charge et tu ressors le vieux laïus du grand méchant google.
[mode offensif] Tu le sors à chaque fois qu'il y a qu'il y a marqué google dans un commentaire ?
[^] # Re: système et garbage collector?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 7.
Ca, c'est assez naïf comme vision. Justement, dans un jeu video où il y a beaucoup de temps réel, reporter un delete a plus tard peut être très important. Et si les delete se produisent de façon automatique, cela peut créer de vrais problèmes puisqu'il ne devient plus possible de le reporter.
[^] # Re: Python et Google
Posté par Philippe F (site web personnel) . En réponse à la dépêche Go : Un nouveau langage chez Google. Évalué à 6.
Par un des auteurs de Unladen Swallow :
Well, simple common sense is going to limit Python's applicability when operating at Google's scale: it's not as fast as Java or C++, threading sucks, memory usage is higher, etc. One of the design constraints we face when designing any new system is, what happens when the load goes up by 10x or 100x? What happens if the whole planet thinks your new service is awesome? Any technology that makes satisfying that constraint harder -- and I think Python falls into this category -- *should* be discouraged if it doesn't have a very strong case made in its favor on other merits.
[^] # Re: Certaines choses bizarres
Posté par Philippe F (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 2.
Le modèle de classe / méthode me fait penser à la simplicité de lua, ce qui permet de l'optimiser à donf sans passer par des tables de fonctions virtuelles.
Globalement, ça me plait.