Antoine a écrit 5722 commentaires

Tu nous parle de détail d'implémentation

Faux. Ce sont des aspects de la sémantique de ces langages qui sont officiels, documentés, testés et maintenus, et les développeurs compétents les ont à l'esprit quand ils écrivent du code. Exactement comme la façon dont sont invoqués les opérateurs comme ==.

J'ai franchement l'impression que tu connais peu ce dont tu parles, et la discussion devient assez ennuyeuse et stérile.

Pas d'expérience perso mais ça pourrait t'intéresser : http://www.blogeee.net/2011/05/test-asus-eeepad-transformer-tf101-2/

Précisément dans le cas où la GPL est distribuée avec. Il s’agit bien du contrat utilisateur—distributeur. Dans cette licence il y est bien mentionné que l’utilisateur peut réclamer les sources et que le distributeur s’engage à les donner. Non ?

Ce qui permet de faire respecter la GPL, c'est le droit d'auteur (ou copyright). À savoir que si quelqu'un ne respecte pas la GPL, un des auteurs (n'importe lequel) peut porter plainte en contrefaçon.

Maintenant si tous les auteurs sont d'accord pour s'asseoir sur le respect de la GPL, je ne pense pas que l'utilisateur (non-auteur) puisse faire grand'chose.

Je risque pas de faire de faute frappe. L'ide complete, et meme s'il complete pas, le compilo me gueulera dessus.

Eh bien, dans ce cas, on peut imaginer que l'IDE soit également capable d'indiquer les chaînes valides pour la fonction open().

Et si tu tapes z a la place de w, par exemple (idee a la con), qu'est ce qu'il se passe?

Le même genre de choses que si tu te gourres d'une lettre dans le nom d'un fichier passé à la même fonction (*). Je ne comprends pas trop ce genre d'arguments, la qualité principale que tu cherches dans un langage de programmation est d'éviter les fautes de frappe ? Il y a des choses plus importantes...

(*) en pratique:

>>> open("LICENSE", "z")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: mode string must begin with one of 'r', 'w', 'a' or 'U', not 'z'

Le open admet les flags sont : r, w, a, +, u et U. On peut très bien avoir rw+U, le tout en unicode évidement. Il faut les parser caracyère par caractère parce que j'imagine que l'ordre n'est pas figé.

Oui, et donc ? Tu penses que parser une chaîne de 4 caractères (fussent-ils unicode) est un problème ? Le coût est absolument minuscule, surtout par rapport au coût de l'ouverture du fichier proprement dite.

Honnêtement tu as des notions de programmation bas niveau pour sortir ce genre d'âneries ?

D'ailleurs l'appelle système (qui ajoute beaucoup plus de contrôle sur l'utilisation des fichiers) utiliser des constantes.

Oui, et il est aussi plus bas niveau. Ce n'est pas un hasard.
J'ajouterai que Python est un langage de haut niveau, et que Java prétend en être un.

C'est faux, si tu n'ouvre ton fichier que dans des cas précis, il va falloir que tu entre dans ce cas précis pour arriver à le détecter.

C'est à ça que servent les tests unitaires. Si tu n'as pas de tests pour cette partie du code, il y a certainement d'autres bugs plus retors qui s'y baladent, et qui ne seront pas détectés par une phase de compilation.

Chercher à être compacte à l'extrême n'a pas de sens.

C'est toi qui vois des extrêmes partout. J'ai parlé de compromis. Un code compact est important, à la fois pour la lisibilité (un code long et verbeux est beaucoup plus pénible à lire) et la facilité d'écriture.

Le mode U ou u n'a rien d'intuitif.

Il ne serait pas plus intuitif avec une option de cinquante caractères dédiée. Dans les deux cas, il faut lire la doc une première fois pour savoir ce que ça fait.

Contrairement à ce que semblent penser les développeurs Java, nommer les choses de façon verbeuse ne remplace pas une documentation.

Chercher à gagner 5 à 10 caractères en perdant en lisibilité, en performance et en fiabilité, ça n'a pas de sens.

On n'y perd pas, justement, sauf dans une vision naïve de la programmation où la compilation suffit à détecter les bugs et où gagner une fraction de microseconde à l'ouverture d'un fichier est important.

tu sais que x.foo(y) est un envoie de message alors que x == y est spécifique à chaque langage.

Sauf que cet "envoi de message" n'a justement rien à voir d'un langage à l'autre. Il faut arrêter de penser qu'il y a un "modèle objet" commun à tous ces langages.

(en C++, par exemple, les méthodes sont non-virtuelles par défaut; en Python, une méthode peut être définie sur l'instance et masquer celle définie sur la classe; etc.)

Il faut en tout cas leur reconnaître un certain courage, à tout vouloir réimplémenter un peu n'importe comment. Et si dans les gens du Web on inclut avant tout le W3C, je dirais que oui ils sont franchement nuls.

Ah, au temps pour moi. Je parlais du client, qui s'appelle Empathy.

Et des fans d'emacs sur facebook.
http://www.google.com/search?hl=fr&q=site%3Afacebook.com%20emacs

C'est pas parce qu'il y a pleins de bugs qu'on ne détecte qu'à l'exécution qu'il est mauvais d'en découvrir avant

C'est un compromis. Ce bug se manifeste de façon immédiate, évidente et déterministe (*). Il est contre-productif d'alourdir les écritures sous prétexte de le détecter à la compilation.

(*)

>>> f = open("LICENSE", "r")
>>> f.write("bar")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: File not open for writing

En plus la gestion par chaîne oblige à parser cette chaîne derrière là où en C++, on a de simples tests binaires.

On va gagner une fraction de microseconde à chaque ouverture de fichier, chouette.

C'est pas parce que tu te rendras qu'au runtime qu'ouvrir ton ficher de cache en lecture seule, c'etait une mauvaise idée, qu'il est inutile de s'assurer a la compile que t'essayes pas d'utiliser un flag qui n'existe pas a cause d'une faute de frappe.

Heu, Java invente ses propres problèmes à résoudre.
Autant c'est facile de faire une faute de frappe avec StandardOpenOption.CREATE_NEW (c'est bien ça ?), autant avec "wb" il faut le vouloir.

Et ça te permet d'avoir des flags un peu plus compréhensible pour le developeur (rb j'ai aucune idée de ce que ça veut dire).

Ben, vu 1) la simplicité des chaînes de flags à passer à open(), 2) que ce sont les mêmes dans beaucoup de langages (cf. le fopen() du C), et 3) qu'ouvrir un fichier est une opération courante, ça se retient très très vite.

Tu peux aussi m'expliquer qu'il faudrait remplacer ls par listDirectoryContents qui est vachement plus lisible.

(pour mémoire : "r" pour read et "b" pour binary)

Surtout quand ton API est orientée stream plutôt que fichier et que des sous classes entre en jeu.

Encore une conception Javaesque. Tu peux très bien avoir une pile de classes orientée stream, comme dans Python 3, tout en cachant le tout derrière une fonction open() bien commode.

cf. http://docs.python.org/py3k/library/io.html

il est assez trivial de faire de l'appel de méthode paramétrique en Python.

Qu'est ce donc ?

Un exemple fictif facilement compréhensible :

class HTTPServerConnection:

    def handle_request(self, request):
        meth_name = "handle_" + request.method.upper()
        meth = getattr(self, meth_name, self.handle_other)
        return meth(request)

    def handle_GET(self, request):
        # etc.

    def handle_POST(self, request):
        # etc.

    def handle_other(self, request):
        # on arrive ici si la méthode HTTP n'est pas
        # reconnue

Il faut déclarer les fonctions avant et garder la cohérence entre le nom des fonctions et leur appel

L'idée avec ce genre d'idiome c'est que tes fonctions sont le plus souvent privées (histoire de découpler l'API de tes détails d'implémentation), donc il n'y a pas de raison de changer le nommage.

Il y a plein de bugs qu'on ne peut découvrir qu'au runtime. Penser qu'on gagne quelque chose à rendre beaucoup plus complexe une chaîne de flags triviale telle que "rb" me semble totalement idiot. Surtout que c'est un truc qui apparaîtra dès que tu écris un test unitaire.

La verbosité par rapport à un truc du genre:

f = open("/tmp/file.txt", "rb")

(le StandardOpenOption.BIDULE étant particulièrement lourd, tout de même)

Il y a des langages à qui on ne le reproche pas et qui pourtant ne gèrent pas du tout de switch (comme python).

En même temps, si tu veux un équivalent de switch sur une chaîne de caractères, il est assez trivial de faire de l'appel de méthode paramétrique en Python. Ou si tu veux utiliser des fermetures, avec un dictionnaire.

Et pour référence, le mail en anglais d'origine (plus lisible pour la plupart qu'un résumé en allemand, AMHA) :
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00931.html

Merci, j'irai jeter un oeil.

Sinon, kde4.7 est la première version à proposer Telepathy pour la messagerie instantané. Est-ce que l'on pourrait avoir un retour des utilisateurs de gnome ?

Un retour de quoi ? J'utilise toujours Pidgin, vu que je ne vois pas trop ce que Telepathy apporte, et que les réimplémentations de fonctions existantes par Gnome me font peur.

Malgré l’intensité du problème, la solution n’a jamais vraiment décollée. Les raisons incluent :

De mon point de vue deux problèmes :

• peu/pas de fournisseurs indépendants qui aient l'air fiables (robustesse, respect de la vie privée, etc.)
• difficile d'installer son propre serveur OpenID (il n'y a pas l'air d'y avoir une implémentation bien maintenue et simple à installer)

Du coup, j'ai abandonné OpenID.

C'est vrai que c'est beaucoup plus beau, au temps pour moi.

D'autre part si c'est pour un serveur ou une grosse station, on peut aussi faire du Raid 1 (miroir) avec deux disques durs plus un SSD, qui sert alors de cache.

Le SSD ne sert pas de cache, il sert de stockage pour les partitions définies en miroir (il n'a pas le comportement adaptatif d'un cache).

Cette bidouille ne règle absolument pas le problème posé, à savoir que les SSD ont une capacité beaucoup plus faible que les disques magnétiques à prix égal : si tu n'as besoin que de la capacité du SSD, pourquoi ajouter un disque magnétique plus gros mais plus lent ?

Et donc, ça avale automatiquement l'exception sans rien faire?

Ça me rappelle le "@" de PHP : tout le monde va se mettre à l'utiliser histoire de ne pas passer trop de temps à débugger les problèmes sous-jacents.

OutputStream out = p.newOutputStream(EnumSet<OpenOption>.of(StandardOpenOption.CREATE_NEW));

Toute la beauté de Java condensée (?) en quelques caractères.

Maintenant, ils peuvent commencer a vraiment bosser :)

Avec ce qu'ils ont sur la table, ce n'est pas très pratique, si ?