Tu sais qu'il est possible d'utiliser un WM personnalisé avec KDE ? Ce n'est pas parce que Kwin est utilisé par défaut que c'est le seul !
Il suffit de renseigner la variable $KDEWM. J'ai testé avec e16 et wmaker, ça marche très bien (kicker est pas bien intégré, mais à la rigueur osef).
Je ne sais pas si c'est aussi rose sous les WM euh non conventionnels à la Ion, mais à mon avis ça vaut le coup d'essayer, quitte à tripoter un peu KDE et/ou le WM pour que ça cohabite pas trop mal
D'ailleurs, je trouve rigolo de constater que ce qui rend son code beaucoup plus lisible que le mien là haut, c'est qu'il colle plus aux méthodes usuelles en mathématique; par exemple, la fonction sigma qui me paraît au premier abord le mélange obscur d'un init et d'un fold_left, est en fait plus naturelle à utiliser dans ce contexte que les init et les fold_left qui vont bien, parce qu'elle reflète l'écriture mathématique.
Ma deuxième erreur a été de ne pas extraire le principe du double init : lui donner un nom (ici init_matrix) aide indéniablement à la compréhension.
À mon humble avis, si la syntaxe était vraiment ce qui change la donne en programmation, ça se saurait...
Pour ma part, je trouve la syntaxe du Basic repoussante de loin, et pourtant, ce sont des langages assez utilisés. Avec Perl c'est encore plus vrai.
La syntaxe, avec un peu d'habitude ça s'apprivoise, et après il n'y a plus de problème.
Le problème à mon avis ce n'est pas OCaml ou Haskell ou Ruby ou je ne sais quel langage à la syntaxe "trop différente", c'est l'habitude qu'on pris les programmeurs C/C++/PHP/Java de n'utiliser essentiellement qu'une seule syntaxe (avec des variations), au point de leur faire pousser des cris parce qu'il y a un _ dans le langage !
Si le plus dur quand on apprend la programmation fonctionnelle, c'était de s'habituer à voir des _ dans les fichiers sources, ça se saurait....
Par ailleurs, pour info, le @@ n'existe pas dans la librairie standard OCaml, c'est juste un truc défini ici pour la composition de fonctions. Si tu as une autre suggestion plus mainstream-friendly, sachant que ° n'est pas accepté, ça peut toujours se changer.
Et oui en effet il n'y aura JAMAIS de surcharge des opérateurs (oui, je sais, il ne faut jamais dire jamais) parce que sinon on ne permet pas l'inférence de type, et le polymorphisme paramétrique. J'ai étudié dans un cours l'algorithme de typage, et il apparaît clairement que la surcharge ne permettrait plus de résoudre le système des contraintes, et de typer une expression.
Par ailleurs, on peut aussi parler du Haskell qui a des moyens de surcharge assez poussés, et qui conserve bon an mal an une partie de son inférence de type. Par ailleurs, ils ont plein de trucs encore plus affreux comme le polymorphisme de second ordre et compagnie (mais il me semble qu'on l'a aussi en OCaml à quelques endroits, je l'ai juste jamais utilisé) qui doivent bien mettre à mal l'inférence des types. Mais elle a survécu : elle est pas totale, mais elle a survécu.
Turing complete ça veut dire qu'on peut faire les même chose dedans, mais pas forcément avec la même efficacité.
Brainfuck est Turing complete (me semble-t-il), et pourtant il sera moins efficace algorithmiquement (par exemple mettre un nombre N dans une case mémoire a une complexité plus grande que O(1), ce qui n'est pas le cas avec des nombres pas trop grands dans la plupart des autres langages).
Le papier qui indique une borne inférieure de complexité moins intéressante avec un algo fonctionnel pur qu'un algo impératif tient donc toujours.
Évidemment, ça ne concerne pas Haskell, qui n'est pas un langage fonctionnel pur, comme tu dis :p
(par contre je suis pas sûr que le hack de l'UnsafePerformIO suffise pour échapper à la preuve de l'autre, mais on sait jamais ce qu'on peut faire avec ces trucs tordus...)
On peut aussi, pour faire plus sérieux, citer un papier ( http://citeseer.ist.psu.edu/pippenger96pure.html ) où il est montré qu'il existe (au moins) un algorithme pour lequel un algo fonctionnel pur est au mieux en O(n log n), alors qu'il existe une version impérative en O(n).
(après, ça n'enlève rien au mérite du Haskell, ni aux langages fonctionnels purs, mais là il faut défendre OCaml, alors tous les coups sont permis, voilà tout)
Je suis pas d'accord, et je trouve ça super douteux.
Le libre pour moi c'est de la connaissance. Alors que ça tourne sur X systèmes libres c'est très bien, mais si on sait pas comment ça marche, ça sera toujours moins bien qu'un truc codé avec des machins douteux, mais ouvert, et modifiable, etc...
En plus C#/.NET c'est Microsoft, c'est le démon, bien sûr, mais ça a peut-être des qualités aussi, c'est pas comme si tu nous parlait d'un programme dans un vieux Visual Basic ou autres. Il y a sûrement de la connaissance dedans.
Franchement, je comprend pas trop ce qui peut pousser quelqu'un à trouver un programme closed source portable plus libre qu'un programme open source.
Dans le cas d'un parcour d'un tableau (une liste, un vecteur, ...) on ne devrait jamais à mon sens utiliser de for mais utiliser des constructions du type
montab.each()
Une liste, c'est un tableau ? hérétique ! :p
Je suis pas vraiment convaincu par l'utilisation des each() à tout vent :
- quand on une liste, on fait souvent des manipulations un peu complexes (récursives, toussa), qui sont bien représentées par les map, fold_left et fold_right, mais pas vraiment par each. Évidemment, il y a toujours des cas d'itération simple, mais je pense qu'ils sont largement minoritaires et que ça ne vaut pas le coup de mettre l'emphase dessus
- quand on a un tableau, on fait plus que juste le parcourir linéairement (sinon, on utiliserait une liste) : on a souvent besoin de l'indice, et on se retrouve souvent à modifier la case en question. Donc ça demande déjà pour avoir un truc un peu utile de passer deux argument au each : l'indice et la valeur. À ce moment là, le each est déjà assez lourd pour qu'un for soit syntaxiquement au moins aussi agréable
Par exemple :
tab.each { |i,v| tab[i] <- v + tab[(i + 1) % len] }
for i from 0 to len - 1 do { tab[i] <- tab[i] + tab[(i+1) % len] }
Dans ce cas très simple, je suis pas convaincu que le each soit plus simple à écrire et à lire (j'ai pris une syntaxe pseudo-ruby au pif, mais ça ne change pas grand chose je pense), il n'apporte pas grand chose, à part une gestion implicite des indices (c'est bien) et un paramètre supplémentaire contenant la valeur de la case actuelle (je suis pas convaincu que le rapport réflexion_supplémentaire/gain_lisibilité soit intéressant).
L'avantage principal des itérateurs, si j'ai bien compris, c'est qu'on peut les utiliser de manière plus ou moins transparente sur plusieurs type de données différent (tableaux, tables de hachage, listes à la rigueur). Dans l'idée c'est bien, mais en pratique je trouve que les structures de données que l'on manipule en même temps sont suffisamment différentes pour ne pas avoir besoin de méthodes de manipulations communes : si on commence à implémenter each sur un arbre binaire, c'est qu'il y a un petit problème de conception en général.
Dans le cas d'itération (et donc là il y a une certaine disymétrie), écrire 1.to(10) ne me choque pas vraiment mais on peut très bien remplacer par une écriture du type : (1..10).each
L'asymétrie n'est pas tant syntaxique que sémantique (hum, je connais pas assez la sémantique pour parler de ça, mais là je pense que c'est vrai ^^) : dans son exemple l'objet auquel on envoie un message, c'est 1, et 10 n'est qu'un argument. C'est fondamentalement asymétrique.
À mon avis, l'écriture (1..10).each bloc suggère plus une fonction curryfiée où (each 1 10) est une fonction prenant un bloc et lui appliquant l'itération, qu'un appel objet.
Lisaac*. Tout y est objet, comme en ruby, même le booléen.
En lisaac, le for est un message de INTEGER
1.to 10 do { i.print;};
Justement, je trouve pas ça si génial que ça moi. Avec ta méthode, du point de vue du sens, le for est un truc qui concerne la première borne : c'est sa méthode qu'on utilise, et à laquelle on donne la deuxième borne et le bloc en arguments (c'est pas forcément la bonne terminologie, mais c'est pas grave).
Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...
En Ocaml/Haskell par exemple, on peut faire ça pour pas cher. Si on ne fait pas d'effet de bords, le "for" n'a à priori pas grand sens, mais imaginons que le for fonctionnel renvoie la liste des valeurs générées par le bloc à chaque itération :
let rec for low up bloc =
if low = up then []
else bloc low :: for (low + 1) up bloc
En Haskell, si on crée un alias de for nommé "to", on peut même faire des contorsions syntaxique amusantes, par exemple
1 `to` 10 $ bloc
(On peut faire pareil en OCaml si on donne un nom d'opérateur à for : 1 >> 10 $ bloc, par exemple)
Je pense que cette asymétrie forcée est un des grands problèmes de l'objet.
prend le cas du lambda calcul. si tu dit que
f (x) = x + x (x etant un reel par exemple)
ce n'ai pas pour faire quelque test que ce soit, mais juste pour definir la fonction f (de type R -> R ).
Oui mais justement, en maths "f(x) = x + x" c'est pas une déclaration de fonction, c'est pas grand chose. Pour déclarer une fonction on fait ça proprement (Soit f : x -> x + x) ou avec une équation (Soit f telle que pour tout x, f(x) = x + x), mais on balance jamais "f(x) = x + x", c'est pas rigoureux.
Heu, je serais plutot en desaccord, ou je ne connais pas de langage retournant plusieur valeur. Peux tu m'eclairer la dessus car en reflechissant a quoi cela pourrait ressembler, je ne m'en fait pas du tout une idée possitive.
Il parle sans doute des tuples (let proches x = (x + 1, x - 1)) qui permettent de renvoyer des aggrégats d'objets de types potentiellement distincts, et alors ce n'est pas vraiment "plusieurs valeurs en même temps", c'est juste une valeur qui en contient plusieurs autres, et qui est légère (syntaxiquement) à manipuler (pas comme un struct ou un tableau ou...).
en haskell, en utilisant des compréhensions de liste :
[o3 | o2 <- listeo1 o1, o3 <- listeo3 o2, predicat o3]
On peut faire la même chose en ocaml, mais il n'y a pas de sucre syntaxique pour ça (bien qu'il soit possible de le rajouter avec une extension camlp4) :
filter predicat (concat (map liste3 (liste2 objet1)))
Dans les deux cas, on considère liste2 et liste3 comme des fonctions qui renvoient les listes quand tu leur donne l'objet.
Je me réponds tout seul, mais on m'a indiqué Infra Recorder ( http://www.framasoft.net/article4388.html ) depuis. J'y penserai la prochaine fois (et à retourner voir sur Framasoft avant de faire quoi que ce soit, aussi).
Mouaif... Ça est et ça va être de moins en moins vrai. Si une distribution sort sans driver proprio ou mp3, ça fait un "scandale". Les distributions 100 % libre sont rares et leur succès assez limité.
Je crois que t'exagères un peu, là. Regarde, sur un bureau linux moyen, combien des logiciels sont libres ? Je dirais 99% au feeling, après ça dépend de si tu prends en compte leur importance (par exemple un driver graphique ça compte pour pas beaucoup de logiciels mais c'est assez important), mais dans tous les cas ça reste largement au dessus des 95%
Et sur Windows ? J'ai du utiliser un Windows récemment, et j'ai eu besoin de deux logiciels : un graveur de CDs (un truc qui sache graver une iso bootable de distribution linux), et un lecteur de PDF. J'ai cherché pendant un temps non négligeable à chaque fois, mais j'ai rien trouvé.
Là-bas (du côté obscur, quoi), c'est le monde du Shareware avec version d'évaluation, voire du freeware.
Alors non, tu es peut-être très en colère à cause des drivers proprios et du mp3 inclus dans les distros, mais les distributions Linux/BSD et cie restent un paradis pour les amateurs de logiciel libre.
Je ne dis pas que ça rend les pratiques douteuses tolérables, les drivers proprios c'est mal et il faut les combattre, mais il ne faut pas faire dans le pessimisme à outrance non plus.
Il me semble que ni Gimp ni Gaim ne sont des logiciels gnomes : même sans aller jusqu'à "il n'y a pas de dépendances gnome donc c'est pas gnome", il me semble que gimp est antérieur à gnome, et aucun de ces deux logiciels ne revendique un lien avec ce bureau sur leur site web.
Pourquoi ne pas contacter l'auteur du bench pour lui soumettre ton hypothèse ? Rien n'indique le changement serait significatif, mais ça vaudrait le coup d'essayer.
Ta remarque paraît pertinente, et jusqu'à présent il s'est montré tout à fait prêt à tester d'autres configurations pour améliorer son benchmark. S'il n'est pas déjà au courant, ton hypothèse l'intéressera sûrement.
Sauf si on dit que les objectifs de la GPL sont la liberté. D'ailleurs c'est pas de la mauvaise foi, j'en suis convaincu :)
L'obligation de conserver la licence pour les travaux dérivés est expliquée (par Stallman lui-même) comme une obligation de faire profiter à la communauté de ses travaux.
Elle peut donc être vue comme une marque de communautarisme (ce qui ne change pas le fait que la GPL est tournée vers la liberté : il y a des obligations qui vont avec, voilà tout); d'ailleurs à une époque je ne sais plus qui parlait de "commonism".
Pour continuer le lien obligations<->communauté (mais attention, ça devient vaseux et je ne garantis plus rien), on pourrait dire que la BSD raisonne à l'échelle de l'indivu (tu es libre de faire un peu tout ce que tu veux avec, tant que tu respectes les auteurs du code), et que la GPL raisonne à l'échelle d'une communauté (tu es libre de faire ce que tu veux tant que respecte les auteurs du code, mais aussi les membres de la communauté en les rendant libre de profiter de *ton* code).
D'où, peut-être, le lien avec le communisme. Mais il ne faut pas oublier que le libéralisme aussi est basé sur une approche globale : si tout le monde raisonne selon son intérêt personnel, et n'est pas entravé dans sa démarche, alors globalement on aura une solution optimale. C'est le "et n'est pas entravé dans sa démarche" qui montre qu'il y a là aussi des obligations à respecter (libre concurrence toussa) qui proviennent d'un point de vue global.
Bah c'est une astuce réthorique parce que tant qu'on ne donne pas d'arguments profonds pour montrer que le communisme c'est tout gentil tout beau et qu'au fond il n'y a vraiment rien de totalitaire là dessous, c'est pas convaincant. Ça reste du jeu sur "oui mais communisme ça commence pas pareil que stalinisme/maoisme, donc c'est différent", sans arguments.
Un bon argument pour dire que ces propos sont douteux, c'est le fait que je me souviens très bien les avoir sorti moi-même à une époque où j'y connaissais encore plus rien que maintenant. Il est vraiment à la portée du premier venu !
J'ai pas dit le contraire non plus, parce que n'ayant pas lu/étudié Marx je ne pense pas être en mesure de juger.
Par contre je sais qu'à une époque c'était à la mode de dire "Ah mais c'est la faute à Staline, c'est un méchant fourbe assoiffé de pouvoir, le bon vieux Lénine était vachement plus gentil, moi je me revendique pas Staliniste mais Léniniste", et que quand j'avais étudié la question (avec le formidable et puissant outil historique qu'est un manuel d'histoire de terminale), bah j'avais découvert que contrairement à ce que disaient ces réthoriciens-là, Lénine il était pas si gentil que ça, en fait.
Depuis, je me méfie.
Je voudrais pas dire, mais le communisme c'est quand même un bon exemple du truc que tout le monde (ou presque) a pensé être une bonne idée à la base, mais qui s'est cassé la gueule à chaque fois (URSS, Chine, Cuba...). (un peu comme le Hurd, quoi :-° ). Alors peut-être qu'avant de recommencer à sortir les vieux tiroirs "oui mais le Karl d'origine il était trop sympa, je suis pour le retour aux sources", il faudrait faire une petite pause pour réfléchir, et se demander si dans le fond, il n'y a pas un problème quelque part.
Je n'ai pas dit que c'était le cas, mais on parle d'un sujet à propos duquel la présomption d'innocence ne s'applique plus : à mon avis, c'est au marxisme de prouver qu'il est cool, et pas à moi de prouver que ça donne lieu au totalitarisme (j'en serais bien incapable, par ailleurs).
Ne serait-ce que par respect/considération pour les gens qui y ont cru aussi, depuis un endroit moins douillet que chez vous, puis ont un jour du faire leur "auto-critique" et sont allés crever dans un camp (ou fusillés ou pendus).
(Par ailleurs, le but d'un troll politique c'est de pas être d'accord, non ? Alors si vous moinssez tous mes messages ça risque d'être nettement moins rigolo)
Entre les gros beaufs, les fachos-fachos-et-demi, les droitiers assumés et les incultes totaux
Ouais en gros, vive les intellectuels de gauche, et les autres c'est tous des cons. Ou, plus nuancé et plus efficace, c'est tous des "excellents codeurs mais qui n'ont pas de culture politique donc j'ai plus raison qu'eux".
L'article ressemble à une subtile variante de l'astuce réthorique vachement utilisée :
« ah mais là tu me parles du stalinisme, tout le monde sait que c'est mal, le goulag toussa j'aime pas non plus, mais moi je parle du communisme, du marxisme, la vraie belle pure gentille idée qu'on avait avant que le méchant Staline vienne totalitariser tout ça »
Va faire un tour, tu verras que c'est bourré de trucs potentiellement cools.
(en particulier la team de haskell/MLiens : http://research.microsoft.com/research/ppt/ )
Il faut bien reconnaître que MS a le nez pour dé^Wembaucher des chercheurs qui tuent.
À priori je n'ai pas vu ça chez Google (peut-être parce qu'ils sont plus spécialisés et font des trucs qui me rendent moins curieux) ou dans d'autres grosses boîtes.
C'est d'ailleurs bien dommage que le modèle fortement décentralisé de l'Open Source ne soit pas plus propice à l'établissement d'activités scientifiques sur le long terme. On peut reposer sur les universités, mais on pourrait sûrement faire mieux (vu qu'il y a des boîtes prêtent à mettre de l'argent dedans).
# « pour revenir à mon bureau KDE »
Posté par gasche . En réponse au journal Mixer Ion et les WM classiques?. Évalué à 6.
Il suffit de renseigner la variable $KDEWM. J'ai testé avec e16 et wmaker, ça marche très bien (kicker est pas bien intégré, mais à la rigueur osef).
Je ne sais pas si c'est aussi rose sous les WM euh non conventionnels à la Ion, mais à mon avis ça vaut le coup d'essayer, quitte à tripoter un peu KDE et/ou le WM pour que ça cohabite pas trop mal
[^] # Re: Lisibilité et produit de matrices
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 2.
D'ailleurs, je trouve rigolo de constater que ce qui rend son code beaucoup plus lisible que le mien là haut, c'est qu'il colle plus aux méthodes usuelles en mathématique; par exemple, la fonction sigma qui me paraît au premier abord le mélange obscur d'un init et d'un fold_left, est en fait plus naturelle à utiliser dans ce contexte que les init et les fold_left qui vont bien, parce qu'elle reflète l'écriture mathématique.
Ma deuxième erreur a été de ne pas extraire le principe du double init : lui donner un nom (ici init_matrix) aide indéniablement à la compréhension.
[^] # Re: Dommage...
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 2.
Pour ma part, je trouve la syntaxe du Basic repoussante de loin, et pourtant, ce sont des langages assez utilisés. Avec Perl c'est encore plus vrai.
La syntaxe, avec un peu d'habitude ça s'apprivoise, et après il n'y a plus de problème.
Le problème à mon avis ce n'est pas OCaml ou Haskell ou Ruby ou je ne sais quel langage à la syntaxe "trop différente", c'est l'habitude qu'on pris les programmeurs C/C++/PHP/Java de n'utiliser essentiellement qu'une seule syntaxe (avec des variations), au point de leur faire pousser des cris parce qu'il y a un _ dans le langage !
Si le plus dur quand on apprend la programmation fonctionnelle, c'était de s'habituer à voir des _ dans les fichiers sources, ça se saurait....
Par ailleurs, pour info, le @@ n'existe pas dans la librairie standard OCaml, c'est juste un truc défini ici pour la composition de fonctions. Si tu as une autre suggestion plus mainstream-friendly, sachant que ° n'est pas accepté, ça peut toujours se changer.
[^] # Re: Dommage...
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 3.
C'est marrant parce que justement pour l'occasion de la 3.10 je suis allé farfouiller un peu sur le site de l'INRIA, et sur la page perso du type qui a refait camlp4 on trouve :
http://gallium.inria.fr/~pouillar/talks/overloading-searchin(...)
Par ailleurs, on peut aussi parler du Haskell qui a des moyens de surcharge assez poussés, et qui conserve bon an mal an une partie de son inférence de type. Par ailleurs, ils ont plein de trucs encore plus affreux comme le polymorphisme de second ordre et compagnie (mais il me semble qu'on l'a aussi en OCaml à quelques endroits, je l'ai juste jamais utilisé) qui doivent bien mettre à mal l'inférence des types. Mais elle a survécu : elle est pas totale, mais elle a survécu.
[^] # Re: Beurk, un langage impératif
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 1.
Brainfuck est Turing complete (me semble-t-il), et pourtant il sera moins efficace algorithmiquement (par exemple mettre un nombre N dans une case mémoire a une complexité plus grande que O(1), ce qui n'est pas le cas avec des nombres pas trop grands dans la plupart des autres langages).
Le papier qui indique une borne inférieure de complexité moins intéressante avec un algo fonctionnel pur qu'un algo impératif tient donc toujours.
Évidemment, ça ne concerne pas Haskell, qui n'est pas un langage fonctionnel pur, comme tu dis :p
(par contre je suis pas sûr que le hack de l'UnsafePerformIO suffise pour échapper à la preuve de l'autre, mais on sait jamais ce qu'on peut faire avec ces trucs tordus...)
[^] # Re: Beurk, un langage impératif
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 4.
(après, ça n'enlève rien au mérite du Haskell, ni aux langages fonctionnels purs, mais là il faut défendre OCaml, alors tous les coups sont permis, voilà tout)
[^] # Re: Beurk, un langage impératif
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 2.
import System.IO.Unsafe
import Data.IORef
cast :: a -> b
cast x = unsafePerformIO $ writeIORef r x >> readIORef r
..........where r = unsafePerformIO $ newIORef $ error "pwned le puriste"
[^] # Re: Dommage...
Posté par gasche . En réponse à la dépêche OCaml 3.10.0 est sorti. Évalué à 6.
open Array
let ( @@ ) f g x = f (g x)
let produit mata matb =
....let coeff li col =
........fold_left ( + ) 0
............(init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)))
....in
....init (length mata) (init (try length matb.(0) with _ -> 0) @@ coeff)
100% tableaux non mutables (non mutés, en tout cas).
[^] # Re: bloups
Posté par gasche . En réponse au journal Paint.NET sous GNU/Linux avec Mono. Évalué à 5.
Le libre pour moi c'est de la connaissance. Alors que ça tourne sur X systèmes libres c'est très bien, mais si on sait pas comment ça marche, ça sera toujours moins bien qu'un truc codé avec des machins douteux, mais ouvert, et modifiable, etc...
En plus C#/.NET c'est Microsoft, c'est le démon, bien sûr, mais ça a peut-être des qualités aussi, c'est pas comme si tu nous parlait d'un programme dans un vieux Visual Basic ou autres. Il y a sûrement de la connaissance dedans.
Franchement, je comprend pas trop ce qui peut pousser quelqu'un à trouver un programme closed source portable plus libre qu'un programme open source.
[^] # Re: QT/GTK
Posté par gasche . En réponse à la dépêche GNOME et Ubuntu pour l'informatique mobile et embarquée. Évalué à 1.
[^] # Re: ma vie va peut être changer
Posté par gasche . En réponse au journal Notre nouveau aimé président .. Évalué à 2.
[^] # Re: Ruby
Posté par gasche . En réponse au journal A mort les boucles. Évalué à 1.
Une liste, c'est un tableau ? hérétique ! :p
Je suis pas vraiment convaincu par l'utilisation des each() à tout vent :
- quand on une liste, on fait souvent des manipulations un peu complexes (récursives, toussa), qui sont bien représentées par les map, fold_left et fold_right, mais pas vraiment par each. Évidemment, il y a toujours des cas d'itération simple, mais je pense qu'ils sont largement minoritaires et que ça ne vaut pas le coup de mettre l'emphase dessus
- quand on a un tableau, on fait plus que juste le parcourir linéairement (sinon, on utiliserait une liste) : on a souvent besoin de l'indice, et on se retrouve souvent à modifier la case en question. Donc ça demande déjà pour avoir un truc un peu utile de passer deux argument au each : l'indice et la valeur. À ce moment là, le each est déjà assez lourd pour qu'un for soit syntaxiquement au moins aussi agréable
Par exemple :
tab.each { |i,v| tab[i] <- v + tab[(i + 1) % len] }
for i from 0 to len - 1 do { tab[i] <- tab[i] + tab[(i+1) % len] }
Dans ce cas très simple, je suis pas convaincu que le each soit plus simple à écrire et à lire (j'ai pris une syntaxe pseudo-ruby au pif, mais ça ne change pas grand chose je pense), il n'apporte pas grand chose, à part une gestion implicite des indices (c'est bien) et un paramètre supplémentaire contenant la valeur de la case actuelle (je suis pas convaincu que le rapport réflexion_supplémentaire/gain_lisibilité soit intéressant).
L'avantage principal des itérateurs, si j'ai bien compris, c'est qu'on peut les utiliser de manière plus ou moins transparente sur plusieurs type de données différent (tableaux, tables de hachage, listes à la rigueur). Dans l'idée c'est bien, mais en pratique je trouve que les structures de données que l'on manipule en même temps sont suffisamment différentes pour ne pas avoir besoin de méthodes de manipulations communes : si on commence à implémenter each sur un arbre binaire, c'est qu'il y a un petit problème de conception en général.
L'asymétrie n'est pas tant syntaxique que sémantique (hum, je connais pas assez la sémantique pour parler de ça, mais là je pense que c'est vrai ^^) : dans son exemple l'objet auquel on envoie un message, c'est 1, et 10 n'est qu'un argument. C'est fondamentalement asymétrique.
À mon avis, l'écriture (1..10).each bloc suggère plus une fonction curryfiée où (each 1 10) est une fonction prenant un bloc et lui appliquant l'itération, qu'un appel objet.
[^] # Re: Ruby
Posté par gasche . En réponse au journal A mort les boucles. Évalué à 1.
Justement, je trouve pas ça si génial que ça moi. Avec ta méthode, du point de vue du sens, le for est un truc qui concerne la première borne : c'est sa méthode qu'on utilise, et à laquelle on donne la deuxième borne et le bloc en arguments (c'est pas forcément la bonne terminologie, mais c'est pas grave).
Moi, je trouve ça laid. Je vois pas pourquoi dans un for, il y aurait une asymétrie entre la première et la deuxième borne.
Dans l'idée, je trouve beaucoup plus joli d'exprimer le for comme une fonction qui dépend des bornes et du bloc :
let for debut fin bloc = ...
En Ocaml/Haskell par exemple, on peut faire ça pour pas cher. Si on ne fait pas d'effet de bords, le "for" n'a à priori pas grand sens, mais imaginons que le for fonctionnel renvoie la liste des valeurs générées par le bloc à chaque itération :
let rec for low up bloc =
if low = up then []
else bloc low :: for (low + 1) up bloc
En Haskell, si on crée un alias de for nommé "to", on peut même faire des contorsions syntaxique amusantes, par exemple
1 `to` 10 $ bloc
(On peut faire pareil en OCaml si on donne un nom d'opérateur à for : 1 >> 10 $ bloc, par exemple)
Je pense que cette asymétrie forcée est un des grands problèmes de l'objet.
[^] # Re: Ruby
Posté par gasche . En réponse au journal A mort les boucles. Évalué à 2.
Oui mais justement, en maths "f(x) = x + x" c'est pas une déclaration de fonction, c'est pas grand chose. Pour déclarer une fonction on fait ça proprement (Soit f : x -> x + x) ou avec une équation (Soit f telle que pour tout x, f(x) = x + x), mais on balance jamais "f(x) = x + x", c'est pas rigoureux.
Il parle sans doute des tuples (let proches x = (x + 1, x - 1)) qui permettent de renvoyer des aggrégats d'objets de types potentiellement distincts, et alors ce n'est pas vraiment "plusieurs valeurs en même temps", c'est juste une valeur qui en contient plusieurs autres, et qui est légère (syntaxiquement) à manipuler (pas comme un struct ou un tableau ou...).
[^] # Re: Python ...
Posté par gasche . En réponse au journal A mort les boucles. Évalué à 2.
[o3 | o2 <- listeo1 o1, o3 <- listeo3 o2, predicat o3]
On peut faire la même chose en ocaml, mais il n'y a pas de sucre syntaxique pour ça (bien qu'il soit possible de le rajouter avec une extension camlp4) :
filter predicat (concat (map liste3 (liste2 objet1)))
Dans les deux cas, on considère liste2 et liste3 comme des fonctions qui renvoient les listes quand tu leur donne l'objet.
[^] # Re: Site vachement bien foutu
Posté par gasche . En réponse au journal Get The Facts Returns !. Évalué à 2.
[^] # Re: Site vachement bien foutu
Posté par gasche . En réponse au journal Get The Facts Returns !. Évalué à 3.
Je crois que t'exagères un peu, là. Regarde, sur un bureau linux moyen, combien des logiciels sont libres ? Je dirais 99% au feeling, après ça dépend de si tu prends en compte leur importance (par exemple un driver graphique ça compte pour pas beaucoup de logiciels mais c'est assez important), mais dans tous les cas ça reste largement au dessus des 95%
Et sur Windows ? J'ai du utiliser un Windows récemment, et j'ai eu besoin de deux logiciels : un graveur de CDs (un truc qui sache graver une iso bootable de distribution linux), et un lecteur de PDF. J'ai cherché pendant un temps non négligeable à chaque fois, mais j'ai rien trouvé.
Là-bas (du côté obscur, quoi), c'est le monde du Shareware avec version d'évaluation, voire du freeware.
Alors non, tu es peut-être très en colère à cause des drivers proprios et du mp3 inclus dans les distros, mais les distributions Linux/BSD et cie restent un paradis pour les amateurs de logiciel libre.
Je ne dis pas que ça rend les pratiques douteuses tolérables, les drivers proprios c'est mal et il faut les combattre, mais il ne faut pas faire dans le pessimisme à outrance non plus.
[^] # Re: Logiciels maisons vs logiciels multi-plateforme
Posté par gasche . En réponse à la dépêche Sortie de GNOME 2.18 « Simplement magnifique (Simply Beautiful) ». Évalué à 5.
[^] # lui proposer ?
Posté par gasche . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 3.
Ta remarque paraît pertinente, et jusqu'à présent il s'est montré tout à fait prêt à tester d'autres configurations pour améliorer son benchmark. S'il n'est pas déjà au courant, ton hypothèse l'intéressera sûrement.
[^] # Re: Re:
Posté par gasche . En réponse au journal Linux, communiste, ou non :p. Évalué à 1.
L'obligation de conserver la licence pour les travaux dérivés est expliquée (par Stallman lui-même) comme une obligation de faire profiter à la communauté de ses travaux.
Elle peut donc être vue comme une marque de communautarisme (ce qui ne change pas le fait que la GPL est tournée vers la liberté : il y a des obligations qui vont avec, voilà tout); d'ailleurs à une époque je ne sais plus qui parlait de "commonism".
Pour continuer le lien obligations<->communauté (mais attention, ça devient vaseux et je ne garantis plus rien), on pourrait dire que la BSD raisonne à l'échelle de l'indivu (tu es libre de faire un peu tout ce que tu veux avec, tant que tu respectes les auteurs du code), et que la GPL raisonne à l'échelle d'une communauté (tu es libre de faire ce que tu veux tant que respecte les auteurs du code, mais aussi les membres de la communauté en les rendant libre de profiter de *ton* code).
D'où, peut-être, le lien avec le communisme. Mais il ne faut pas oublier que le libéralisme aussi est basé sur une approche globale : si tout le monde raisonne selon son intérêt personnel, et n'est pas entravé dans sa démarche, alors globalement on aura une solution optimale. C'est le "et n'est pas entravé dans sa démarche" qui montre qu'il y a là aussi des obligations à respecter (libre concurrence toussa) qui proviennent d'un point de vue global.
[^] # Re: Mouais...
Posté par gasche . En réponse au journal Linux, communiste, ou non :p. Évalué à 4.
Un bon argument pour dire que ces propos sont douteux, c'est le fait que je me souviens très bien les avoir sorti moi-même à une époque où j'y connaissais encore plus rien que maintenant. Il est vraiment à la portée du premier venu !
J'ai pas dit le contraire non plus, parce que n'ayant pas lu/étudié Marx je ne pense pas être en mesure de juger.
Par contre je sais qu'à une époque c'était à la mode de dire "Ah mais c'est la faute à Staline, c'est un méchant fourbe assoiffé de pouvoir, le bon vieux Lénine était vachement plus gentil, moi je me revendique pas Staliniste mais Léniniste", et que quand j'avais étudié la question (avec le formidable et puissant outil historique qu'est un manuel d'histoire de terminale), bah j'avais découvert que contrairement à ce que disaient ces réthoriciens-là, Lénine il était pas si gentil que ça, en fait.
Depuis, je me méfie.
Je voudrais pas dire, mais le communisme c'est quand même un bon exemple du truc que tout le monde (ou presque) a pensé être une bonne idée à la base, mais qui s'est cassé la gueule à chaque fois (URSS, Chine, Cuba...). (un peu comme le Hurd, quoi :-° ). Alors peut-être qu'avant de recommencer à sortir les vieux tiroirs "oui mais le Karl d'origine il était trop sympa, je suis pour le retour aux sources", il faudrait faire une petite pause pour réfléchir, et se demander si dans le fond, il n'y a pas un problème quelque part.
Je n'ai pas dit que c'était le cas, mais on parle d'un sujet à propos duquel la présomption d'innocence ne s'applique plus : à mon avis, c'est au marxisme de prouver qu'il est cool, et pas à moi de prouver que ça donne lieu au totalitarisme (j'en serais bien incapable, par ailleurs).
Ne serait-ce que par respect/considération pour les gens qui y ont cru aussi, depuis un endroit moins douillet que chez vous, puis ont un jour du faire leur "auto-critique" et sont allés crever dans un camp (ou fusillés ou pendus).
(Par ailleurs, le but d'un troll politique c'est de pas être d'accord, non ? Alors si vous moinssez tous mes messages ça risque d'être nettement moins rigolo)
[^] # Re: et OpenBSD, c'est crypto-maoïste
Posté par gasche . En réponse au journal Linux, communiste, ou non :p. Évalué à 10.
Ouais en gros, vive les intellectuels de gauche, et les autres c'est tous des cons. Ou, plus nuancé et plus efficace, c'est tous des "excellents codeurs mais qui n'ont pas de culture politique donc j'ai plus raison qu'eux".
# Mouais...
Posté par gasche . En réponse au journal Linux, communiste, ou non :p. Évalué à -9.
« ah mais là tu me parles du stalinisme, tout le monde sait que c'est mal, le goulag toussa j'aime pas non plus, mais moi je parle du communisme, du marxisme, la vraie belle pure gentille idée qu'on avait avant que le méchant Staline vienne totalitariser tout ça »
Facile à dire.
[^] # Re: Cool
Posté par gasche . En réponse au journal FreeCol, clone libre de Colonization. Évalué à 2.
(mais je n'ai rien contre le poisson en général)
[^] # Re: impossible !!!
Posté par gasche . En réponse au journal Linux, Windows, le matériel et les drivers. Évalué à 6.
http://research.microsoft.com/research/default.aspx
Va faire un tour, tu verras que c'est bourré de trucs potentiellement cools.
(en particulier la team de haskell/MLiens : http://research.microsoft.com/research/ppt/ )
Il faut bien reconnaître que MS a le nez pour dé^Wembaucher des chercheurs qui tuent.
À priori je n'ai pas vu ça chez Google (peut-être parce qu'ils sont plus spécialisés et font des trucs qui me rendent moins curieux) ou dans d'autres grosses boîtes.
C'est d'ailleurs bien dommage que le modèle fortement décentralisé de l'Open Source ne soit pas plus propice à l'établissement d'activités scientifiques sur le long terme. On peut reposer sur les universités, mais on pourrait sûrement faire mieux (vu qu'il y a des boîtes prêtent à mettre de l'argent dedans).