Guillaume Laurent a écrit 1148 commentaires

En effet si on regarde ms office et staroffice, ils sont lourds, a peine 5% des fonctionnalités sont utilisés courement,

Oui, mais c'est jamais les mêmes 5%.

http://www.joelonsoftware.com/news/20020407.html(...)

Ecrire du code coute très cher. Si MS ajoute une feature à Office, c'est en général parce qu'il y a des clients qui l'ont demandé et qui sont près à payer pour l'avoir.

Auquel cas, quel est l'intérêt d'une interface comme décrit dans l'article sur des choses plus simples comme celles-ci ?

En pratique, il y a plus d'une méthode commune aux deux classes, et tu veux qu'elles dérivent de la même classe, pas seulement pour des question de typage mais aussi parce que ça explicite bien ce que tu veux faire, et c'est beaucoup plus maintenable. Par ailleurs tu peux plus facilement tester les paramètres qu'on te passe avec un truc du genre

if (machin.implements(telle_interface))
... ok
else
throw
end

Entre

class Foo
open()
close()
end

class Bar
open()
close()
end

et

Interface Stream
open()
close()
end

class Foo implements Stream
...
end

class Bar implements Stream
...
end

le 2nd cas est quand même plus clair, non ? Plus tu en dis au langage sur comment s'organisent tes classes, mieux c'est.

Je crois que tu devrais lire le Design Patterns :-).

Mais avec un typage dynamique, peu importe que tu sois en présence de la classe toto ou de la classe titi, car si tu fais machin.méthode(truc) il se débrouillera dans les deux cas.

Je ne comprends toujours pas. Je présume que "machin" est un nom d'objet d'un certain type (class toto ou titi).

Partant de là, en Python ou n'importe quel autre langage objet, soit les classes toto et titi définissent la méthode 'méthode' prenant un 'truc' comme argument et ça passe, soit non et tu te prends une erreur à la compil dans le cas d'un langage fortement typé comme C++, ou une exception au runtime dans le cas d'un langage comme Python ou Ruby. Que tu ais un typage dynamique ou pas ne change rien au fond du problème, il faut que toto et titi aient la même interface.

Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme

def appelle_la_methode_foo (obj, arg)

obj.foo(arg)

end

va passer, qu'on lui passe un objet toto ou titi. Là oui, c'est vrai. Mais le but de ce type de pattern est un peu plus complexe que ce cas là :-).

Personnellement, j'utilise plutôt Python, et le typage dynamique autorise tout ça sans avoir à s'emmerder à taper des trucs en plus.

Je ne suis pas sur de comprendre. Peux-tu donner un exemple concret ?

Du code peut très bien être OpenSource et soumis à une licence interdisant sa modification, ou la distribution de sa modification.

Non.

http://www.opensource.org/docs/definition_plain.html(...)

est bien un exemple que les initiatives similaires à celles de CodeWeavers sont à bannir (et à condamner) du monde linux.
Elles ne font que donner aux anti-linuxiens des arguments contre l'autosuffisance de notre système et des applications Libres.

C'est sur qu'en lisant ça, on a pas l'impression que Linux est une secte, mais alors pas du tout.

Ce qu'on leur reproche, c'est de l'avoir nié catégoriquement

J'ai pas souvenir de ça... URL ?

Maintenant, qu'une personne en ait marre qu'on tire sur ms, ça me laisse toujours perplexe.

Peut-être parce que sur LinuxFR ça sombre dans le parfait ridicule. Parmi tout ceux qui râlent contre MS, y en a combien qui font réllement quelque chose pour le libre ? Coder, traduire ou écrire de la doc... autre chose que de se branlotter le display à coup de thèmes imbitables juste pour dire "oui mais sous Linux on a le choix d'avoir une UI de daube" et de refaire comme sur

http://membres.lycos.fr/azerty0/tdc.html(...)

Ruby est plus puissant, plus souple, mais moins lisible [...]


Ah.

Python est plus lisible[...] Mais trop verbeux: les self partout BEURK!
Guido aurait pu faire une exception et utiliser un $ ou un @ pour distinguer les variables des attributs et les methodes des fonctions..

Justement, Ruby n'a pas besoin de 'self' partout, et '$' et '@' sont utilisés pour distinguer entre les variables globales et membres. C'est entre autre pour ça que finalement il est plus lisible que Python (les itérateurs ça aide beaucoup aussi, et ne pas avoir à mangler les noms de méthodes pour simuler le private/public également :-).

La priorité des opérateurs dans la résolution des expressions

Oui. C'est expliqué dans l'URL de mon post précédent.

Parce que si c'est ça, pour une bête boucle, y'a pas vraiment de différence.

Lis l'URL.

Sinon sur le plan style, en général on utilise {} pour les trucs très simple sur une ligne, et do end pour les blocs plus complexes.

do end et {} n'ont pas la même précédence :

http://www.rubycentral.com/book/language.html(...)

(recherche "Blocks, Closure, and Proc Objects")

Et puis honnetement, les return implicite, ca sux

cf. réponse sur les regexps inline :-).

ah un dernier truc qui me chiffone : la doc.

Là c'est vrai, celle de Python est mieux foutue. Mais le "pickaxe book" (celui dont tu parles) est plutôt bien écrit, ça compense. Il y a aussi une quick ref dispo chez O'Reilly.

et j'aime pas les 'inline regexp'.

C'est pas important. La seule question au final c'est de savoir si ça t'aide ou pas pour écrire et relire du code. Et pour autant que j'ai pu le constater, ça aide.

Alors même si je l'utilise pas, je ne peux pas empecher tout le monde de l'utiliser.

A l'usage, je t'assure que ça n'est vraiment pas un problème pour la lisibilité.

Je crois pas que les commentaires ruby a la rdtool soit accessibles a l'execution.

Non, mais comme je te le disais c'est assez facile à ajouter. Je suppose qu'ils seront disponible en standard dans une version ultèrieure.

a = %w{kikoo les amis}

C'est un shortcut, t'es pas obligé de l'utiliser...

et le fait de pouvoir mettre ou pas les parenthèses

Ça au contraire c'est génial, ça aère énormément le code.

les docstrings inexistantes

Si tu parles de la doc embarquée, elle y est. Si c'est spécifiquement d'un string qu'on met dans la définition d'une classe, il y a un exemple sur comment les ajouter dans le "pickaxe book". Et ça n'est pas ce genre de détail qui fait la différence sur la vitesse de développement.

Bof. Ça te permet juste d'écrire un peu plus rapidement des scripts "jetables", et même dans ce cas la syntaxe est plus clean que celle de Python :-).

C'est ce que je pensais avant d'essayer Ruby :-).

Non non, HEINTAIGRISSTTE.

> linufr est devenu un ramassi d'INTAIGRITE

Et le niveau de l'orthographe est en chute libre (sans compter celui de la syntaxe).

Non, ça c'est une autre. Il y a à ma connaissance 2 videos de Ballmer, une ou il cavale sur scène et il fini complètement essouflé, et l'autre ou il martèle "developers developers developers". Les deux sont édifiantes :-).

Tu as ce genre d' "exhuberance" dans beaucoup de boites américaines, c'est pour ainsi dire dans leur culture.

Quand au coté "lavage de cerveau", la communauté Open Source n'est pas en reste non plus :-).

En plus de ne pas être constructifs pour un sous, revoir encore et encore la même chose est un poil lourd.

Parce que tu trouves que les commentaires sur les autres news sont d'un meilleur niveau ? :-)

Exec passe par un fork de toute facon

Non, exec() et fork() sont deux appels indépendants. En général pour lancer un autre programme on fait un fork() suivi d'un exec() (ce que fait un shell qui lance une commande par exemple), mais il y a des cas ou on veut faire un exec() directement.

Mais creer un processus a partir de soi n'a que peu d'interet par rapport au thread a part de charger un autre code => donc un autre executable.

Non plus. Historiquement, les serveurs sous Unix fonctionnent comme ça. Un process père qui écoute en attente de connection, et à chaque connection il forke un fils qui la traite. C'est un peu plus lourd que des threads, mais plus facile à programmer et plus fiable.

Même si son calendrier est "excessif", le mécanisme qu'il révèle reste très pertinent.

Sauf que la baisse de prix du matériel dont il parle n'existe pas.

Depuis des années le prix d'une machine de bureau est dans une fourchette de 750 à 1800 euros (5 à 15kf). Les machines augmententent en puissance, mais le prix reste à peu près stable.

Ah. Pourtant sur

http://lwn.net/2001/0830/a/esr-on-va.php3(...)

la première phrase est "VA's announcement that it would be selling proprietary add-ons to SourceForge
has gotten big coverage".

La encore j'ai l'impression qu'on ne parle pas de la même chose. Je parle de Source Forge en tant que logiciel, par le service sur sourceforge.net (lequel n'est pas du tout payant, et dont le coté propriétaire reste très discutable :-).

Ah mais bien sur suis-je bête, il ne s'agit que d'add-ons, pas du logiciel lui-même, donc ce n'est nullement comparable.

Me voilà rassuré alors.

Ben oui, justement, Sun gagne des milliards (quoique, ces derniers temps, il me semble qu'ils serrent un peu les fesses) parce qu'ils ont une politique commerciale classique, c'est à dire qu'ils font payer leur produits :-).

J'ai l'impression que tu juges ça dans l'optique "c'est mal de faire du propriétaire, Sun gagne des sous donc ils n'ont aucune excuses, mais VA oui parce qu'ils sont dans la dèche". C'est pas du tout de ça que je parle. Il s'agit juste de noter que ESR a deux avis opposés sur deux décisions commerciales très semblables (rendre payant un produit dont il existe un équivalent libre).

1) pBpG fait l'amalgame entre ESR et VA

Faudrait lui demander confirmation mais bon, dans les fait tu as

- Sun va rendre Star Office payant, l' "expert" ESR dit que c'est une connerie.

- VA rends Source Forge payant, ESR dit que c'est un mal nécéssaire :

http://lwn.net/2001/0830/a/esr-on-va.php3(...)

Il ne s'agit pas de faire l'amalgame entre ESR et VA, juste de faire remarquer que le bonhomme n'est pas toujours cohérent.