Vivi a écrit 819 commentaires

Je viens de lire la news reuters, c'est pitoyable

"Chad Dickerson, responsable de la division des relations avec les programmeurs chez Yahoo, a estimé qu'il s'agissait du plus important logiciel dont le code source était rendu public depuis qu'internet existe."

Euh moi je lis pas ça dans la news Reuters, je vois:

Chad Dickerson, head of the Sunnyvale company's software developer relations program, said he believed that the open approach to programming represented the biggest single Web software ever to be opened up for public development.

Ce qui ne veut rien dire, parce que the open approach to programming c'est pas un software. Bref, à mon avis le type de Yahoo essayait de dire que le développement collaboratif c'était de la balle et le type de Reuters a tout mélangé.

... ne me permet pas de conclure que XCB va accélérer dix fois GTK+ en non déporté.

... et même en déporté. La Xlib n'est pas complètement synchrone non plus (pour s'en convaincre, voir l'aide de n'importe quelle appli GTK+, en particulier l'option --sync Make X calls synchronous).

GTK+ fait déjà pas mal attention à limiter les "round-trips" entre le client et le serveur.

Gnome est passé à Subversion

non pas encore, il y a eu des problèmes lors de la migration est c'est repoussé pour l'instant.

L'article est un peu réducteur.

Bof non je trouve pas. Le paragraphe que tu cites s'appelle "What functional programmers can learn from SSA" et s'adresse donc aux gens qui font du fonctionnel ; ça explique justement que les notations utilisées par la communauté SSA peuvent être utile pour les programmeurs de langage fonctionnels. Ce n'est donc pas un "détournement", c'est juste identifier un aspect du SSA qui peut être profitable dans un autre contexte. Ce n'est pas le propos de l'auteur de réduire le SSA à des flowcharts.

Le SSA n'est pas plus qu'une représentation possible d'un programme
oui et ? L'auteur ne dit pas le contraire.

Enfin bon le but de l'article est de montrer l'équivalence entre ces deux notions: transformation SSA et programme fonctionnel. Pas que la technique SSA est issue du fonctionnel.
Quand une même notion est découverte indépendemment par des approches différentes il y a souvent des choses intéressantes à tirer de "l'autre approche".

Il ne save même pas ce que c'est que bash ni même ce qu'est un shell.

Euh ... il me semble que bash.org ne fait pas du tout référence au shell mais au verbe anglais to bash qui veut dire "casser" (au sens de Brice) en argot.

Oui bon après, ça dépend des détails. Olivier a une version assez élaborée mais dans ce cas précis ça peut s'écrire en une ligne aussi en caml:

Array.map print_endline (Sys.readdir (Sys.getcwd ()))

J'ai du mal à voir en quoi faire des transformations sur des données structurées est l'apanage des langages fonctionnels.

C'est pas exactement ça. Le principe des langages fonctionnels est de travailler avec des valeurs (non modifiables) et non avec des variables (au sens d'emplacement mémoire) modifiables. Le SSA impose qu'une variable ne soit écrite une seule fois, d'où la similarité avec les langages fonctionnels.

cf. Andrew W. Appel, SSA is Functional Programming http://www.cs.princeton.edu/~appel/papers/ssafun.ps

The SSA conversion algorithm is really...converting a C or Fortran procedure into a well-structured functional program with nested scope.

Il faudrait aussi comparer l'efficacité d'un programme compilé avec le compilo Ocaml et un équivalent F# (Il doit bien y avoir un JIT ou quelque chose comme ça, non ?).

Bah déjà tu peux comparer la vitesse d'exécution du bytecode OCaml et celle du programme F# sur le CLR.

Enfin c'est intéressant comme comparatif, ça casse un peu le mythe du "on peut implémenter n'importe quel langage avec .NET".

Sinon on peut citer OCamIL comme projet similaire: http://www.pps.jussieu.fr/~montela/ocamil/ modifier le compilo OCaml pour lui faire générer du bytecode pour .NET.

Sans parler du manque de ressource évident pour le développement de la Fedora, avec Alan Cox qui propose de jeter Evolution dans la poubelle

Ah ? Fedora serait donc la seule distrib à distribuer Evolution ? Ce problème de mainteneur n'existe pas avec Debian ?

C'est couillon quand même parce que Muine est trés bien je trouve http://muine-player.org/wiki/Main_Page

Sur ce genre de sondage internet, elle se situe à mon avis à +/-20% :
t'as une marge d'erreur à nous donner sur ton estimation de la marge d'erreur ?

Je crois que je risque d'attendre encore longtemps avent qu'il n'intégre Last.fm

Euh y'a déjà un plugin Last.fm. Bon ça ne fait que soumettre la musique que Rythmbox joue, pas d'écouter les radios.

Je l'ai, il est trés bien en effet, avec une bonne progression entre les chapitres. Il y a des implémentations en OCaml pour les systèmes de types présentés. Et si je me souviens bien il y a des exercices (corrigés à la fin pour certains).

Euh non, l'album Oxygène date de 1976.

1. tu séquences

Non mais tu séquences quoi ?

Enfin bref, ce que tu racontes est complètement irréaliste.

cf. http://www.redhat.com/archives/fedora-announce-list/2006-Jun(...) :

* new printing system (new system-config-printer, cups 1.2, new GTK+
printing technology)

donc il ne s'agit pas de cups (FC5 a déjà cups 1.2) mais de la GUI de configuration (system-config-printer) et je pense du support de l'impression dans GTK+ 2.10.

Parce qu'on parle bien de libre

dans mon dictionnaire, libre est un adjectif et quand on dit le libre, c'est pour "le logiciel libre". Là l'article évalue le caractère collaboratif ou non du processus de développement. C'est quand même pas pareil.

L'article met bien de côté le côté technique, alors pourquoi mettre dans le même panier la licence du code avec les caractéristiques du processus de développement ?

En fançais on évite les problèmes de sens du mot free en anglais, c'est franchement pas la peine d'en créer en surchargeant le mot libre comme vous le faites.

GNAT Pro : 0% libre

hé ben ... si c'est pas de l'intégrisme tout ça. C'est du GPL, c'est libre. Ce n'est peut-être ni collaboratif ni ouvert ... mais c'est du logiciel libre.

ouais enfin bon le meilleur moyen ça reste d'utiliser le bon algorithme, à savoir celui en log(n) appels récursifs.

en chameau, en utilisant la bibliothèque de calculs avec les grands nombres, ça donne ceci:

open Num

let pmul (a, b) (c, d) =
let ac = a */ c in
(ac +/ a */ d +/ b */ c,
ac +/ b */ d)

let rec pow x a n =
if n = 0
then a
else
pow
(pmul x x)
(if n mod 2 = 0 then a else pmul a x)
(n / 2)

let fib n =
if n < 0 then invalid_arg "fib" ;
fst (pow (Int 1, Int 0) (Int 0, Int 1) n)

let _ =
print_endline (string_of_num (fib 100000))


Pour cacluler fib(100000) chez moi ça va 10× plus vite qu'avec l'algo linéaire.

Aparté tu veux dire ?

... c'est comme pour tout ce qui est implémenté via une bibliothèque: il faut avoir des bindings !

En l'occurence, tu pourrais utiliser ocamlsdl : http://ocamlsdl.sf.net/

Quant à la bibliothèque Graphiqcs, ça utilise XBell, je sais pas trop comment ça marche.

Attention, les compilateurs sont bootstrapés et les bibliothèques standard aussi mais les runtimes sont en général écrits en C (c'est le cas de OCaml en tout cas).

1/ en général, c'est pas un virus c'est une bactérie: Agrobacterium tumefaciens

2/ ils n'y a pas de risques que l'OGM infecte d'autres plantes, la transfection par Agrobacterium se fait en laboratoire et on sait précisément quel ADN est intégré au génome de la plante.

C'est ça. Les graines vendues sont des "hybrides F1", des hybrides de première génération obtenus par croisement entre deux lignées pures (homozygotes). Les graines produites par ces plants (génération F2) ne sont plus homogènes comme la F1 et en général perdent leurs qualités.

Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.

OK mais tout ceci n'est pas à strictement parler un problème de syntaxe. Cela tient plutôt à la manière dont ces deux langages gèrent le polymorphisme, le typage, etc. Ce n'est pas quelque chose qui peut s'améliorer en changeant uniquement la syntaxe (ie. la représentation en chaîne de caractères du programme), ça a aussi à voir avec toute la sémantique du langage.

Effectivement, si OCaml avait des type classes comme Haskell, cela permettrait une syntaxe plus légère. Mais il ne faut pas se focaliser sur la syntaxe actuelle comme si les concepteurs l'avait voulue exactement ainsi, qu'ils se fichent des aspects pratiques, etc. Les aspects problèmatiques de la syntaxe sont surtout des conséquences d'autres limitations du langage plutôt que erreurs de conception. (AMHA)

- il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité.

mais ... c'est comme ça dans tous les langages. C'est comme si tu nous faisait un vélo parce qu'en C, pour parser les expression arithmétiques genre 2 + 4 * 5 parfois il faut des parenthèses et parfois on peut les omettre. Les différentes règles de la grammaire ont des priorités, si ça ne correspond pas à ce que tu veux, il faut rajouter les parenthèses ... c'est tout.

Par exemple, l'opérateur produit pour les types * à une priorité plus faible que l'application, du coup string * string list est parsé comme string * (string list) ; si tu veux une liste de paires de string, il faut l'écrire (string * string) list. C'est le même principe que pour les expressions arithmétiques : tu retiens les priorités des opérateurs les plus courants et sinon tu mets des parenthèses. Je vois pas trop ce qu'on peut reprocher à OCaml sur ce point.

Autre exemple: l'expression if/then/else. Quand on écrit if e1 then e2 ; e3, l'expression e3 n'est pas dans la branche then, elle est au même niveau que le if ; il faut mettre des parenthèses (ou un begin/end) si on veut obtenir la séquence e2 ; e3 dans le then. Mais c'est à peu près le même comportement qu'en C avec if (cond) i1; i2;: il faut des {} pour regrouper i1 et i2.

Je n'ai pas pour but de démolir OCaml.

... et je ne prétends pas que OCaml soit sans défaut. Comme souvent c'est une question de compromis : la syntaxe n'est sans doute pas la meilleure qui soit mais les autres atouts du langage en valent largement la peine.