lasher a écrit 2732 commentaires

Oui enfin je peux aussi ecrire un interpreteur C, c'est pas pour ca que le langage a ete prevu pour ca...

LLVM n'est vraiment pas fait pour ça ...

Tu confonds pas avec Windows 7 starter ?

Ta tendance est documentée par des faits réels ? (je veux dire pas forcément significatifs statistiquement, mais réels, quoi)

« Je vois l'idée. Ça serait tellement beau un monde où l'on puisse résister à une puissance occupante sans risquer sa peau, et où un site comme Wikileaks soit doté d'une conscience absolue du Bien et du Mal qui permette de juger ce qu'il est bon ou pas de divulguer. Un monde dans lequel, en 1940, l'état allemand est forcément le Mal et où les USA c'est le Bien. »

Justement il ne s'agit pas trop de dire qui a tort ou raison (et ce n'est pas moi qui ai fait référence aux collabos, je te rappelle... :-)). Il se trouve qu'en l'occurrence, en 1944, les deux grands libérateurs de l'Europe (et ce, indépendamment de leur « valeur » politique dans les années qui suivent) ce sont les USA et l'URSS.

« Malheureusement je suis certain que si les nazis avaient gagné leur guerre et maintenu leur emprise sur l'Europe, la majorité des français trouveraient aujourd'hui parfaitement normal de soutenir l'idéologie nazie, et notre point Godwin serait de comparer quelqu'un aux juifs. Ça ne m'empêche pas de considérer l'idéologie nazie comme une horreur, mais j'essaie de garder ce recul et cette part de doute ;+) »

J'essayais justement de prendre cet exemple (WW2), dans un contexte où l'on sait que l'idéologie primait très clairement sur la logique vers la fin [1], et qui donc aurait très clairement tout fait pour punir les maychants résistants (là où d'autres se seraient peut-être juste dit « putain ça va mal, limitons les dégâts »).

D'une part, WikiLeaks ne peut divulguer que ce qu'on lui porte à voir -- i.e., s'ils n'ont que les noms des résistants, et pas ceux des collabos, ils brisent un certain équilibre en les révélant (c'est d'ailleurs ce que certains détracteurs reprochent au WikiLeaks réel [2]). Du coup dans mon scénario original sous licence CC-BY-SA ;-), seule l'Allemagne nazie gagnent à avoir des infos compromettantes. Peut-être que 3 ans plus tard, on aura les autres infos, bien sûr, mais en attendant, si WL diffuse les noms, plutôt que de simplement expliquer le procédé par lequel l'operation Overlord a pu être mise en place (ce qui, honnêtement, est bien plus intéressant, objectivement -- mais ce n'est que mon avis bien sûr), ben nos petits résistants risquent d'avoir chaud aux miches. Enfin, admettons que Wikileaks divulgue à la fois les noms des collabos et des résistants. Super, on aura le droit à un bain de sang.

« Tout ça pour dire que, AMHA, ce n'est pas vraiment à Wikileaks ou aux journalistes qui font le tri de décider s'il est bon ou pas de divulguer telle ou telle information. »

C'est dommage, parce que justement c'est le boulot des journalistes de faire un tri de façon à ce que le rapport signal/bruit soit le meilleur possible. L'important ce sont les actes, les causes et les conséquences. Dire « houla, vous savez, moi, je ne fais que dumper 3To de câbles diplomatiques, p'tet ben que y'a des opérations en cours, avec des gens qui risquent leur vie dans le lot, mais bon, c'est la vie hein, et puis, ils l'ont choisi. », c'est irresponsable.

Irresponsable, oui, car :
1. Ils n'ont pas choisi de mourir, ils ont choisi de risquer leur vie et potentiellement de perdre la vie selon un risque calculé : la probabilité qu'un « journaliste » diffuse le nom de tous ceux qui œuvrent à la libération d'un pays par exemple (et là, je ne vise aucun pays, mon exemple est purement hypothétique), je ne vois pas en quoi ça informe mieux la population. Que le mec s'appelle François, Benjamin, Rachid, ou Boubakar, ça change quoi ? Mis à part qu'en publiant son nom on le grille et on l'empêche de faire son boulot, voire on le met plus en danger qu'il ne l'était avant, bien sûr.
2. Ceux qui sont des informateurs ne sont que les messagers. Ça fait depuis un bon moment que les messagers ne sont pas censés être zigouillés pour rien. Révéler leur identité revient à mettre une cible sur leur tête. C'est d'ailleurs pour cela que l'on permet aux journalistes de ne pas révéler leurs sources.

« Wikileaks qui prend partie, et décide de sauver telle vie mais pas telle autre, de révéler les secrets de tel diplomate mais pas de tel berger afghan, ce n'est pas ça que j'en attends. »
La différence entre le berger et le diplomate, c'est le verre blindé de la voiture du diplomate. Si H. Clinton est explicitement citée, c'est que, au pire, elle devra démissionner de son poste (je m'en fais pas trop pour elle, même si ça finissait par arriver, elle trouvera facilement un autre job).

Il ne s'agit pas de dire de quel parti est Wikileaks, puisque le principe-même du site est de dénoncer des scandales. Mais il y a une différence entre citer les noms de gens qui sont déjà dans la sphère publique, et qui a priori ne risquent pas plus d'être cités à nouveau, et des gens qui pensent faire leur devoir en donnant des informations à une autorité quelconque, qui leur semble légitime/capable de rétablir « l'ordre » (quel qu'il soit) / etc, mais qui n'ont pas les moyens matériels de le faire eux-même.

Ce que tu proposes, c'est plus ou moins ce que fait Électre (dans la pièce éponyme de Giraudoux). Elle veut faire éclater la vérité à tout prix, même celui de la destruction de son pays [3]. Alors, je suis à fond pour elle, dans le cadre de la pièce, et parce que je ne suis pas obligé de vivre dans la Grèce Antique avec les barbares à ses portes. Mais dans la vraie vie, justement, la plupart des démocraties sont obligées de composer, faire des compromis avec les différentes populations qui composent leur peuple, ainsi qu'avec les peuples voisins. Électre aurait vu cela comme un mensonge, une souillure qu'il faut laver à tout prix. Électre est pure, et réclame une justice impartiale mais aussi impitoyable. Bref, Électre n'est finalement pas tout à fait humaine. :-)

[1] Au moins pour Hitler -- d'autres personnes de son état major avaient bien compris à quel point ils étaient dans la merde, et ce, dès 1943)
[2] Ce à quoi je réponds justement que non, je ne vois pas de problème, puisque les journalistes ont fait tout ce qui était possible (au moins d'après ce qu'ils disent) pour montrer la vérité sans pour autant exposer au danger des gens qui n'ont pas forcément mérité de se prendre une balle.
[3] Pour ceux qui ne connaîtraient pas l'histoire de la pièce: Électre est la fille du roi Agamemnon, et de Clytemnestre. Cette dernière aide son amant, Égiste, à tuer Agamemnon, et prend sa place en tant que régent. Je passe sur la pièce en elle-même, mais vers la fin, Égiste se révèle en tant que véritable souverain, au moment où Électre comprend enfin qui a tué son père. Elle confronte Égiste, qui ne nie pas. Il lui demande juste d'attendre la fin du conflit avec les barbares, et lui promet qu'ensuite il se soumettra de lui-même à Électre et au peuple. Électre refuse, et fait éclater la vérité.

« Bon désolé pour "l'ado" il me semblait, de mémoire, qu'elle avait 15 ou 16 ans au moment où elle a fait l'amour avec Polansky. 13 c'est un peu jeune pour notre culture. (notre culture pas dans le sens "la vision que nous avons" mais bien dans le sens "développement intellectuel permettant une conscience réelle").. donc il a niqué avec une mineure, une bien réelle.
De là à dire que c'est un viol... »

13 ans, c'est déjà l'adolescence. Mais c'est aussi un viol. La loi US le dit (elle a moins de 18 ans au moment des faits, donc c'est un viol). Et même la loi française le dirait (elle a moins de 15 ans, donc c'est un viol). Ce que ce n'est pas, c'est un acte pédocriminel (comme certains -- notamment aux USA -- voudraient nous faire croire).

Bon. Je trouve que juste t'inutiler n'est pas suffisant, dans le sens où ce genre de réaction mérite réponse.

Puisque tu fais déjà des tentatives de Godwinage de loin, reprenons ta référence. Imaginons WikiLeaks qui existe en 1939. En juillet 1944, WikiLeaks diffuse les noms de gens qui ont aidé les USA à préparer leur entrée sur le sol Français un mois plus tôt, pour une opération en Normandie. L'état allemand de l'époque est encore en place, et il se sait plus ou moins condamné à terme, mais autant partir avec un BANG. Donc du coup, ils s'assurent que le maximum de résistants, etc., se retrouvent vraiment désolés d'avoir résisté...

Tu vois l'idée ?

Pourtant Java a la classe aussi ! :-/

Ben justement, une fibre (qui est un thread léger) peut s'exécuter sur un processeur séparé. Ce qui fait qu'une co-routine ne peut pas s'exécuter sur un cœur/thread matériel différent tient plus à l'absence de support du matériel, pour le coup.

Il faut ensuite pouvoir garantir que l'espace mémoire pris par ton implémentation fonctionnelle est bornée. De plus, tu vas bien être obligé d'acquérir des ressources à un moment donné, qui sont de « nature impérative » (réseau, disque, etc.); comment gères-tu ce cas (en parallèle) ? Je ne dis pas que ce n'est pas possible hein (Erlang est un bon exemple de langage qui fait ce qu'il faut), mais ça implique un certain niveau de synchronisation entre tes instances de fonctions, et ça a un coût à l'exécution en temps et en espace.

Alors, soyons bien d'accord: je sais à quel point un compilateur ça trompe énormément. Je sais entre autres parce que je bosse au même niveau (juste au-dessus du matériel, ou dans le compilateur).

Cela étant dit: si tu prends n'importe quel guide sur l'optimisation de code (disons le manuel d'Intel sur la question par exemple http://www.intel.com/Assets/PDF/manual/248966.pdf, ou le site de A.Fog, http://www.agner.org), ou surtout des manuels plus haut-niveau (pour les gens qui ne veulent/peuvent pas passer le temps qu'il faut à micro-optimiser leur code), les méthodologies proposées impliquent souvent de compiler à différents niveaux d'optim (-O0,..., -O3), et de prendre un jeu d'essai représentatif -- bref, de faire à la main ce que certains compilateurs (icc, et normalement gcc aussi, par exemple) savent faire depuis un moment: de la compilation guidée par profilage.

De plus, que -O3 puisse ralentir un programme, je le crois volontiers; qu'il donne des résultats faux (ou même que l'optimisation a eu un effet de bord surprenant, disons), à moins d'un bug dans le compilateur, c'est plutôt que l'utilisateur a fait des hypothèses quant au langage/à la machine qu'il utilise (je parle d'expérience).

Concernant la cohérence et l'élégance d'un langage et sa prévisibilité, je ne suis pas certain de comprendre ce que tu veux dire par là. La plupart du temps (mais clairement pas toujours), plus de concision implique plus de clarté, mais cela suppose néanmoins une compréhension du langage, et de comment il fonctionne. J'ai l'impression qu'une bonne partie des reproches faits aux langages « différents » (qu'ils soient fonctionnels, tels que ML, Haskell, LISP, déclaratifs tels PROLOG, ou bien juste « glu » genre Perl) est qu'ils ne fonctionnent pas comme leurs cousins impératifs tirés du C. J'ai exactement le même problème avec Fortran par exemple, et pourtant il n'est pas si éloigné du C que ça (en supposant qu'on passe à Fortran 90 au minimum pour avoir la forme libre de syntaxe).

Oups, problème de copier-coller: http://www.spinellis.gr/blog/20090420/

Gna gna gna, même pas vrai. :-) Le jargon, c'est le même que le tiens: « hash », « tableau », « scalaire ». :-)

Ben oui, si y'a sous-typage sémantique, c'est qu'on va au-delà de la syntaxe. :)

Donc ta balise, ce n'est plus une simple chaîne de caractères, c'est un type à part entière (et je te parle même pas des schémas, qui permettent justement de typer « pour de bon » le contenu de tes balises et de t'affranchir du « tout est chaîne »). Je te renvoie lâchement ici : http://cduce.org/papers.html pour plus d'infos, mais je t'avoue que l'article initial (« semantic subtyping ») est franchement difficile à lire. Y'a une version plus sympa (« A gentle introduction to semantic subtyping »), qui fait l'impasse sur le moteur de pattern matching, mais qui reste difficile à lire.

Dans tous les cas, tu te retrouves avec un type qui contient d'autres types (c'est ce que montre l'article original: il prouve ce qui était pure conjecture par ailleurs : il y a une relation ensembliste entre un type et ses sous-types).

Au final, si tu as un arbre XML à traiter (par exemple pour trouver une certaine information), CDuce (et d'autres langages, genre XQuery, à supposer qu'ils bénéficient du même genre de fonctionnalités que CDuce dans leur implémentation) devrait être capable de rapidement élaguer l'arbre, pour rapidement trouver une réponse à la recherche faite dans le document.

' _ ' c'est pas le nom pour dire « n'importe quel argument » ?

Oui enfin là je ne te suis pas du tout hein. Java a un typage fort pour les objets. Le système de types en interne suit les règles de l'art en ce qui concerne le typage (cf le bouquin de Benjamin Pierce).

Et qu'il n'existe pas d'outils en Java pour correctement vérifier qu'une variable est non-null est une chose. Typiquement lors de l'écriture d'une méthode, un IDE comme Eclipse signalera toute variable susceptible d'être non-initialisée, à l'exception des variables passées en paramètre. Après, qu'il faille un outil pour vérifier que l'articulation des méthodes (le graphe d'appel des fonctions quoi) passe bien des arguments non-null (en supposant que ce ne soit pas autorisé), c'est un autre problème... Cela dit je n'ai pas fait de Java depuis longtemps, et je me demande si les ajouts syntaxiques au langage (annotations, etc) ne permettent pas de détecter ce genre de trucs ...

Mmmh, si le compilateur est capable d'inférer tout seul les types ou les champs qui devraient être initialisés sans que l'utilisateur ait quoi que ce soit à faire, je ne vois pas où est le problème (je ne parle pas d'un langage en particulier).

Le truc, c'est que ce qui te semble simple, voire évident, dans le code que tu as montré se transforme en code spaghetti à force de rajouter une condition par-ci ou une autre par-là. C'est ce que je voulais dire par « laisser le compilateur briller là où il le peut ». Un exemple tout bête: une multiplication de matrice.

Le code original (naïf et tout):

void matmul(const size_t m, const size_t n, const size_t k,
                    const double alpha, const double *a, const double *b,
                    const double beta, double *c)
{
    for (size_t i = 0; i < m; ++i)
       for (size_t j = 0; j < n; ++j)
            for (size_t l = 0; l < k; ++l)
                c[i*n+j] = beta * c[i*n+j] + alpha * a[i*k+l] * b[l*n+j];
}


Bon, tu peux t'embêter à faire tout un tas d'optimisations super intelligentes (et connues depuis 30 ans), du genre promotion scalaire, inversion de boucles, et tuilage, etc., ce qui pourrait donner un truc du genre :


void matmul(const size_t m, const size_t n, const size_t k,
                    const double alpha, const double *a, const double *b,
                   const double beta, double *c)
{
    for (size_t i = 0; i < m; ii += TILE_I)
        for (size_t l = 0; l < k; l += TILE_L)
            for (size_t j = 0; j < n; j += TILE_J)
                for (size_t ii = i; ii < MAX(i+TILE_I,m); ++ii)
                    for (size_t jj = j; jj < MAX(j+TILE_J,n); ++jj) {
                        acc = c[ii*n+jj] * beta;
                       for (size_t ll = l; l < MAX(l+TILE_L,k); ++ll) {
                            acc = c[ii*n+jj] + alpha * a[ii*k+ll] * b[ll*n+jj];
                        }
                        c[ii*n+jj] = acc;
                    }
}


Bon, je ne dis même pas que ce code est optimal (il est loin de l'être). Un bon exemple concernant ce genre de transformations se trouve ici : http://www.spinellis.g/blog/20090420/

Cependant, si je te dis que y'a toute une théorie qui existe déjà concernant les nids de boucle, et que ce genre d'optimisation peut-être faite par le compilateur sans que tu aies à lever le petit doigt, tu seras content non ? Ben le typage fort permet justement ce genre d'optimisations (enfin pas le tuilage, mais d'autres transformations/simplifications de code). Du coup quand je te vois faire ce que tu fais en JS (ou je ne sais quel autre langage), en rajoutant condition après condition et en disant « facile ! » en fonction de ce qu'on te dit que le compilateur sait déjà faire, je tique un peu. :)

Excuse-moi de te demander pardon, mais si Voici et Jeune & Jolie parlent du bouclier fiscal, le niveau des magazines de merde a bien remonté.

Super, et donc tu aimes jouer aux super-programmeurs, et faire des trucs qui peuvent être faits automatiquement. Wouhou...

Y'a suffisamment de cas où le compilateur ne fait pas bien son boulot pour lui laisser l'occasion de briller quand c'est plutôt chiant à faire à la main, tu ne trouves pas ?

Tu as raison, et on devrait aussi changer C/C++/Java/etc pour que "a < c" s'écrive "a lessThan c". Bon, c'est de la taquinerie, mais je trouve que justement, ce qui fait la force d'un langage (et qui le démarque des autres) c'est justement une partie de sa syntaxe et sa façon d'exprimer les choses. Ça passe aussi par des symboles bizarres, parfois. C'est aussi l'une des raisons pour lesquelles j'aime Perl, là où d'autres le détestent: tous ces marqueurs ($,@,%,...), ça les perturbe, alors qu'après pas mal de temps à les avoir manipulés, moi je trouve ça naturel.

« [...] Ajoute à ça un typage statique fort qui possède de charmantes propriétés (comme la reconstructibilité : de toute expression tu peux déduire le type, tu n'es pas obligé de l'annoter - pas de déclarations chiantes comme en C ou autres). »

Mmmh, je trouve que c'est un peu déloyal de parler comme ça, à la limite de la malhonnêteté. [1] En OCaml, il y a bien inférence de type, mais dans le cas où tu mélanges différents types dans une fonction, et que tu n'as pas défini les interactions entre tous les types possibles que ta fonction accepte (le produit cartésien quoi), ben ce que renvoie ta fonction est un objet de type incomplet au mieux, qu'il faudra définir complètement par la suite. Quand tu n'as que quelques types à gérer tu t'en fous, mais dès que le nombre d'interactions entre types devient un peu complexe, ça commence à devenir pénible.

C'est pour ça que des langages type C, C++, Java, etc., déclarent les types des arguments etc. : pour « casser » la pénibilité en cas d'arguments multiples (entre autres choses hein). Et pourtant, si l'on excepte les types primitifs [2], Java utilise aussi la sûreté des types [3].

Mais quand on considère certains types de structures de données, genre (au pif) XML [4], ben là, chaque balise est un type, et dans un document XML classique, des types et des sous-types, y'en a ... fiou, tout plein. C'est là qu'interviennent des trucs (à ma connaissance pas implémentés dans les langages populaires, fonctionnels, ou impératifs) : le sous-typage sémantique. Y'a un langage preuve de concept qui a été créé pour l'occasion: CDuce. Il est dérivé des langages ML (d'ailleurs je crois bien qu'il nécessite OCaml pour être bootstrapé), mais sait correctement élaguer l'arbre des types/sous-types liés à un type donné. Fin bref, c'est très loin pour moi, tout ça, et mieux vaut aller voir de ce côté-là: http://cduce.org/

Tout ça pour dire que oui, OCaml est très bien, oui, il sait faire de l'inférence de type, mais clairement, non, ce n'est pas la panacée (par contre j'aime beaucoup son moteur de pattern matching pour le code, mais c'est une autre histoire).

[1] Je rigole hein ! :-)
[2] Oui, je sais, c'est un peu facile de dire ça ...
[3] Sur les objets donc... faire int toto = 3.2; va toujours fonctionner « à la C » et tronquer la valeur pour la stocker en tant qu'entier dans toto.
[4] XML qui inclut donc des types dans les types, ces types étant instanciés/présents (ou pas) en fonction des documents, etc.

Mmmh, si tu as un langage qui implémente réellement une forme forte de typage, alors en théorie, même si tu as un bug, celui-ci violera certainement les loi de ton typage et du coup ton programme plantera proprement. À comparer avec les langages à typage faible (par exemple le C), qui grogneront peut-être s'ils sont sympa à la compilation, sous forme de warning, mais qui malgré tout laisseront passer certaines conversions implicites. Du coup tu peux te retrouvé « coincé » à l'exécution, avec un programme qui va te donner des résultats faux, ou bien qui ne terminera jamais, etc.

Le typage fort ne fait pas tout bien sûr, mais il assure presque à tous les coups que ton programme se terminera en cas de bug lié aux types. Je ne compte plus le nombre de fois où j'ai expliqué à des étudiants à quel point ils étaient chanceux d'avoir un bug reproductible en C (que j'adore par ailleurs)... :-)

« Attention, il n'y a pas de coroutines en Go, mais des Goroutines. Ce sont une sorte de threads légers qui peuvent communiquer entre eux via des channels. »

Oui enfin, une co-routine c'est justement un thread léger, généralement impossible à préempter à moins d'une exception ou que la coroutine elle-même décide de le demander... Ça me semble 'achement proche des Goroutines. :)

C'est à la fois peu et beaucoup quand on considère que ce genre de processeur est produit en relativement petite quantité comparé aux machins type Pentium 4 à l'époque ... :)

Et pour la version dual core de l'Itanium 2, Intel n'en avait pas produit assez initialement et avait fourni des préversions initialement (avec la promesse de les remplacer par des versions finales quand elles seraient prêtes ...)

Ça m'étonne pas mal, vu que le CEA a un peu acheté la production d'Itanium 2 à une époque pour son cluster (~ 4000 processeurs bi-cœur)