Posté par Damien .
En réponse au journal Tango.
Évalué à 5.
l est préférable d'apprendre aux débutants que KDE n'est pas Gnome, que XFCE n'est pas WindowMaker
Pourquoi faire ? idéalement on n'en utilise qu'un, et de toute façon ils font tous plus ou moins la même chose... en tout cas, entre gnome et kde, à part que gnome est généralement bien mieux foutu que kde, ça reste un panel avec un menu start, des icônes, des applets et une barre de tâches... (*)
(*) un subtil troll se cache dans cette phrase, sauras-tu le retrouver avant que je -->[trop tard] ?
Non. En fait l'héritage multiple est bien. Ou plutôt serait bien si on savait l'implémenter correctement et rendre son utilisation claire dans le langage...
A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
Subtil troll :-) On peut faire des choses élégantes en C++ ?
Personnellement je trouve les mixins ou les traits [1] bien plus clairs que l'héritage multiple. En gros, un trait est un groupe de méthodes, de la même manière qu'une interface est un groupe d'opérations (envoyer un message = appeler une opération, et la méthode est le code effectivement appelé en fonction du type de l'objet récepteur).
Ça permet de réutiliser proprement du comportement (quand une classe utilise un trait c'est comme si elle incluait directement les méthodes, moyennant renommages ou oublis de méthodes si nécessaire, comme en Eiffel). Avec ça tu factorises tes méthodes gérant la sélection et la couleur de toutes les formes. Par contre comme un trait ne peut pas définir d'état, il faut que tu déclares ton attribut couleur toi-même (mais du coup plus de casse-tête ou de duplication d'attributs comme avec l'héritage multiple)
Passer du temps à écrire des tests, ça coûte moins cher que passer du temps à fixer des bugs tordus ou à refactorer sans filet.
Plus on détecte un bug tôt, plus il est facile à corriger (si ça se trouve, le code est même pas encore committé). Par contre si on détecte un bug alors que le logiciel est bien avancé, ça peut coûter très cher (si ça se trouve, la conception était foireuse dès le départ, faut tout refaire).
Ensuite, quand on a une batterie de tests sérieuse, on peut attaquer des modifs sans prendre trop de risques, car on peut vérifier régulièrement qu'on a rien cassé.
Bref, évidemment qu'écrire des tests ça coûte plus cher que faire l'autruche en se disant que "ça compile donc ça marche". À court terme. Mais allez dire à un manager à cheveux en pointes de dépenser des un peu de sous maintenant pour pas prendre le risque de devoir en dépenser plein plus tard...
J'irais même plus loin : le typage statique c'est une optimisation prématurée.
En fait le typage est juste un contrat comme un autre (et un peu un problème de documentation ou de nommage). Les systèmes de typage statique qui fournissent une réelle assistance plutôt qu'une contrainte sont rares et complexes (O'Caml j'en suis pas fana, mais j'ai lu du bien de Haskell...)
Poser des contrats (pré/post-conditions surtout, invariants un peu moins) sur les méthodes est TRÈS efficace pour localiser les erreurs : quand ça explose, le contrat localise très vite l'origine de l'erreur (et pas sa conséquence, comme avec une backtrace).
À mon avis, une approche très efficace à la fois pour éviter les bugs techniques et les problèmes de compréhension des specs est une combinaison de méthodes agiles / XP / test-driven-development avec un langage typé dynamiquement encourageant la conception par contrats.
Certains choix sont un peu déroutants au début (ce sont les apôtres de l'Asynchronous Programming, une méthode de gestion d'évenements sans Threads).
Et justement en python c'est l'horreur, parce que la syntaxe ne permet pas les méthodes anonymes (et lambda a des limitations si je ne m'abuse)...
En gros ils essayent de faire des continuations sans avoir le support dans le langage (ou en tout cas sans les utiliser...). Pour voir ce que ça peut donner quand c'est bien fait, il faut voir Seaside [1], qui réussit à masquer complètement l'asynchronisme.
Bref, franchement, Twisted m'a pas convaincu, surtout que c'est quand même assez bas niveau ; c'est génial pour faire des applis qui doivent utiliser plein de protocoles différents, mais pour du web c'est pas assez spécialisé (oui, je suis fan de RubyOnRails :)
En Smalltalk les Array sont pas prévues pour être redimensionnées ; je suppose qu'elles sont implémentées à la C avec toutes les données bien contigues en mémoire. Par contre évidemment ça contient des références d'objets donc c'est intéressant seulement pour les objets immédiats comme les petits entiers ou les caractères. Peut-être qu'il y a d'autres astuces, je sais pas.
On peut quand même redimensionner une Array, mais c'est fait violemment : on en alloue une autre, on copie le contenu, et on met à jour la référence. Vous avez bien lu, la référence change, c'est pas une double indirection. La représentation du tas est prévue pour être facilement parcourue/mise à jour et les objets peuvent bouger en mémoire. Ça permet en particulier au GC de défragmenter, et de garder une image compacte.
Disclaimer : Prendre avec des pincettes ce que je rapporte ci-dessus, c'est ce que j'ai compris/intuité d'une courte exploration du langage, je sais pas si ça marche aussi bien que ça pourrait mais les idées sont intéressantes.
Les préconditions sont là pour ça
En fait, les contrats en général... c'est très utile pour localiser les bourdes dans le code. Il faut juste un moyen propre de les exprimer et de compiler sans pour les versions finales. Évidemment en Eiffel c'est facile :)
mouais ça fait quand même 2h qu'il est dessus là, pour un repo CVS d'à peine 1400 révisions...
et il me fait des «Can't decode commit message as utf8.» de temps en temps aussi.
Je me suis mis à SVK aussi. Pour les aspects techniques (star-merge etc) je sais pas trop, je m'en sers pas... Par contre avoir subversion comme backend est un gros gros avantage: on peut utiliser des branches SVK chez soi même pour des projets avec un repository 'officiel' sous Subversion. Je crois qu'il y a moyen de mirrorer un projet CVS aussi, mais que c'est moins transparent qu'avec Subversion.
Je suis curieux de voir ce que ça va donner en effet... surtout si avec linux, la PS3 devient utilisable comme machine d'appoint, ça fera une bonne occase pour me consoler du passage forcé au CPU du côté obscur :-]
Cela dit je vois mal comment exploiter les SPU pour autre chose que du multimédia/dsp/gros calcul ; 256K ça m'a pas l'air gros, et si il faut swapper des pages entre SPU et mémoire principale juste pour lancer un programme de base... la bande passante est sympa mais quand même...
La compilation c'est aussi un obstacle à certains outils... par exemple dans rails, ./script/console t'ouvre un interprète dans le contexte de l'appli. En smalltalk c'est courant de coder dans le débogueur.
Bien sûr c'est possible dans une certaine mesure et grâce à des artifices subtils (le compilo d'eclipse, zerolink dans XCode...) mais ça n'est pas aussi simple et clair qu'en ruby/python/smalltalk.
Pas forcément... le typage statique a des inconvénients aussi (flexibilité, verbosité) et je suis pas certain que ça soit plus utile que des tests bien faits, surtout si on considère les autres avantages des tests (ça fait de la doc, des exemples de code, en test-first ça aide aux specs, c'est utile pour refactorer etc.)
À côté de ça le typage statique ne dispense pas de faire des tests... avoir une étape de compilation allonge le cycle de développement, etc
pour les feeds, c'est un problème de temps du devel de typo... je compte le faire dès que j'ai l'esprit libre (càd. début juillet) mais libre à quiconque de proposer des patches, c'est du libre!
[^] # Re: Ben moi
Posté par Damien . En réponse au journal Tango. Évalué à 5.
Pourquoi faire ? idéalement on n'en utilise qu'un, et de toute façon ils font tous plus ou moins la même chose... en tout cas, entre gnome et kde, à part que gnome est généralement bien mieux foutu que kde, ça reste un panel avec un menu start, des icônes, des applets et une barre de tâches... (*)
(*) un subtil troll se cache dans cette phrase, sauras-tu le retrouver avant que je -->[trop tard] ?
[^] # Re: Je n'ai qu'une chose à dire
Posté par Damien . En réponse au journal rails: un module d'identification. Évalué à 2.
[^] # Re: Mes deux centimes ...
Posté par Damien . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
Non. En fait l'héritage multiple est bien. Ou plutôt serait bien si on savait l'implémenter correctement et rendre son utilisation claire dans le langage...
A cause du manque de l'héritage multiple, je ne sais pas comment faire ça élégamment en Java.
Subtil troll :-) On peut faire des choses élégantes en C++ ?
Personnellement je trouve les mixins ou les traits [1] bien plus clairs que l'héritage multiple. En gros, un trait est un groupe de méthodes, de la même manière qu'une interface est un groupe d'opérations (envoyer un message = appeler une opération, et la méthode est le code effectivement appelé en fonction du type de l'objet récepteur).
Ça permet de réutiliser proprement du comportement (quand une classe utilise un trait c'est comme si elle incluait directement les méthodes, moyennant renommages ou oublis de méthodes si nécessaire, comme en Eiffel). Avec ça tu factorises tes méthodes gérant la sélection et la couleur de toutes les formes. Par contre comme un trait ne peut pas définir d'état, il faut que tu déclares ton attribut couleur toi-même (mais du coup plus de casse-tête ou de duplication d'attributs comme avec l'héritage multiple)
[1] http://www.iam.unibe.ch/~scg/Research/Traits/(...)
[^] # Re: du pognon pour les tests unitaires et les assertions. libre
Posté par Damien . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
Plus on détecte un bug tôt, plus il est facile à corriger (si ça se trouve, le code est même pas encore committé). Par contre si on détecte un bug alors que le logiciel est bien avancé, ça peut coûter très cher (si ça se trouve, la conception était foireuse dès le départ, faut tout refaire).
Ensuite, quand on a une batterie de tests sérieuse, on peut attaquer des modifs sans prendre trop de risques, car on peut vérifier régulièrement qu'on a rien cassé.
Bref, évidemment qu'écrire des tests ça coûte plus cher que faire l'autruche en se disant que "ça compile donc ça marche". À court terme. Mais allez dire à un manager à cheveux en pointes de dépenser des un peu de sous maintenant pour pas prendre le risque de devoir en dépenser plein plus tard...
[^] # Re: Mon avis de moi
Posté par Damien . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.
J'irais même plus loin : le typage statique c'est une optimisation prématurée.
En fait le typage est juste un contrat comme un autre (et un peu un problème de documentation ou de nommage). Les systèmes de typage statique qui fournissent une réelle assistance plutôt qu'une contrainte sont rares et complexes (O'Caml j'en suis pas fana, mais j'ai lu du bien de Haskell...)
Poser des contrats (pré/post-conditions surtout, invariants un peu moins) sur les méthodes est TRÈS efficace pour localiser les erreurs : quand ça explose, le contrat localise très vite l'origine de l'erreur (et pas sa conséquence, comme avec une backtrace).
À mon avis, une approche très efficace à la fois pour éviter les bugs techniques et les problèmes de compréhension des specs est une combinaison de méthodes agiles / XP / test-driven-development avec un langage typé dynamiquement encourageant la conception par contrats.
[^] # Re: Dynamisme de Python
Posté par Damien . En réponse au journal Python on rails. Évalué à 3.
Et justement en python c'est l'horreur, parce que la syntaxe ne permet pas les méthodes anonymes (et lambda a des limitations si je ne m'abuse)...
En gros ils essayent de faire des continuations sans avoir le support dans le langage (ou en tout cas sans les utiliser...). Pour voir ce que ça peut donner quand c'est bien fait, il faut voir Seaside [1], qui réussit à masquer complètement l'asynchronisme.
Bref, franchement, Twisted m'a pas convaincu, surtout que c'est quand même assez bas niveau ; c'est génial pour faire des applis qui doivent utiliser plein de protocoles différents, mais pour du web c'est pas assez spécialisé (oui, je suis fan de RubyOnRails :)
[1] http://seaside.st(...)
# l'embarras du choix?
Posté par Damien . En réponse au journal Python on rails. Évalué à 2.
-> [scaphandre amianté]
[^] # Re: La memoire goulot d'etranglement
Posté par Damien . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 2.
En Smalltalk les Array sont pas prévues pour être redimensionnées ; je suppose qu'elles sont implémentées à la C avec toutes les données bien contigues en mémoire. Par contre évidemment ça contient des références d'objets donc c'est intéressant seulement pour les objets immédiats comme les petits entiers ou les caractères. Peut-être qu'il y a d'autres astuces, je sais pas.
On peut quand même redimensionner une Array, mais c'est fait violemment : on en alloue une autre, on copie le contenu, et on met à jour la référence. Vous avez bien lu, la référence change, c'est pas une double indirection. La représentation du tas est prévue pour être facilement parcourue/mise à jour et les objets peuvent bouger en mémoire. Ça permet en particulier au GC de défragmenter, et de garder une image compacte.
Disclaimer : Prendre avec des pincettes ce que je rapporte ci-dessus, c'est ce que j'ai compris/intuité d'une courte exploration du langage, je sais pas si ça marche aussi bien que ça pourrait mais les idées sont intéressantes.
[^] # Re: I had a dream...
Posté par Damien . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 2.
En fait, les contrats en général... c'est très utile pour localiser les bourdes dans le code. Il faut juste un moyen propre de les exprimer et de compiler sans pour les versions finales. Évidemment en Eiffel c'est facile :)
conclusion arrêtes de coder en C
Exactement...
[^] # Re: Améliorations
Posté par Damien . En réponse au journal Agenda du Libre: export au format iCal. Évalué à 1.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 1.
et il me fait des «Can't decode commit message as utf8.» de temps en temps aussi.
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 1.
urf, en effet, it does o_O
bon OK, rubyforge est ptet pas d'un répondant exemplaire non plus :-)
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 1.
Je crois que je tenais cette idée du wiki SVK, qui n'est peut-être plus à jour :
http://svk.elixus.org/?SVKCVS(...)
PS. je me suis mis à SVK avec l'article de Scott Laird:
http://scottstuff.net/blog/articles/2005/07/07/distributed-developm(...)
http://typo.cdlm.fasmz.org/articles/2005/07/15/distributed-version-(...)
[^] # Re: Arch est le premier, mais pas le seul
Posté par Damien . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 4.
[^] # Re: faudrait lire les sources avant de les citer...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 2.
[^] # Re: J'ai hate...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 1.
(via /. : http://hardware.slashdot.org/article.pl?sid=05/06/29/1854207(...) )
[^] # Re: faudrait lire les sources avant de les citer...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 0.
[^] # Re: faudrait lire les sources avant de les citer...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à -1.
heink ?
[^] # Re: J'ai hate...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à 4.
Cela dit je vois mal comment exploiter les SPU pour autre chose que du multimédia/dsp/gros calcul ; 256K ça m'a pas l'air gros, et si il faut swapper des pages entre SPU et mémoire principale juste pour lancer un programme de base... la bande passante est sympa mais quand même...
# faudrait lire les sources avant de les citer...
Posté par Damien . En réponse à la dépêche Port de Linux sur le processeur Cell. Évalué à -4.
[^] # Re: Une photo
Posté par Damien . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
https://linuxfr.org/comments/590906.html#590906(...)
faut pas poster à des heures impossibles comme ça Pascal :)
[^] # Re: Ruby On Rails
Posté par Damien . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 4.
Bien sûr c'est possible dans une certaine mesure et grâce à des artifices subtils (le compilo d'eclipse, zerolink dans XCode...) mais ça n'est pas aussi simple et clair qu'en ruby/python/smalltalk.
[^] # Re: Ruby On Rails
Posté par Damien . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
[^] # Re: Ruby On Rails
Posté par Damien . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 1.
À côté de ça le typage statique ne dispense pas de faire des tests... avoir une étape de compilation allonge le cycle de développement, etc
[^] # Re: Après avoir testé rails...
Posté par Damien . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
pour les feeds, c'est un problème de temps du devel de typo... je compte le faire dès que j'ai l'esprit libre (càd. début juillet) mais libre à quiconque de proposer des patches, c'est du libre!