Objective Caml est la principale variante du langage Caml. Du point de vue du langage, elle étend le noyau du langage Caml avec une couche orientée objets complète, ainsi qu'un système de modules puissant. Un système de types polymorphe avec inférence automatique des types assure la cohérence de ces traits. Le langage est entièrement développé et maintenu par l'INRIA. Il est distribué sous licence QPL 1.0 tandis que les bibliothèques sont sous licence LGPL 2.
En plus des sources, des binaires sont proposés pour GNU/Linux (format RPM, deb ou Gentoo) et pour Win32. Les binaires Mac OS X ne sont pas encore disponibles.
NdR: Merci à benja pour son journal. Les nouveautés principales de cette version (tirées du changelog) :
- Les variables d'instances dans les classes peuvent maintenant être déclarées virtual et implémentées dans des sous-classes.
- L'impression d'un historique de la pile d'appel lorsque le programme s'arrête sur une exception non rattrapée, auparavant disponible uniquement pour les programmes compilés en bytecode, est maintenant disponible pour les programmes compilés en code natif (fonctionne sur Intel/AMD et sur PPC, en 32 bits et en 64 bits).
- Nouveaux portages : Mac OS X, PowerPC, 64 bits; Microsoft Windows 64 bits (x64) utilisant les outils Microsoft PSDK; Microsoft Windows 32 bits utilisant les outils Visual Studio 2005.
- Le préprocesseur Camlp4 a été réimplémenté en grande partie et offre une nouvelle API pour les extensions de syntaxe, plus modulaire que l'ancienne.
- Un nouvel outil expérimental, ocamlbuild: c'est un gestionnaire de compilation qui automatise la construction d'applications et de bibliothèques OCaml.
- Référencer une interface compilée avec -rectypes depuis un module non compilé avec cette option est maintenant une erreur.
- Modification du "fragile matching" warning.
- Détection de dépassement de pile sur MS Windows 32 bits, Mac OSX PC et Intel.
Aller plus loin
- L'annonce sur le site de l'INRIA (5 clics)
- La page de téléchargement (7 clics)
- La licence (1 clic)
- Le changelog complet (2 clics)
- Pour creuser : les livres sur le langage (3 clics)
- DLFP : le journal d'origine (0 clic)
# Dommage...
Posté par MiniMoi . Évalué à 9.
J'ai appris le Caml Light en prépa, les 3 premières heures j'ai détesté, impossible de comprendre la syntaxe, la façon d'exprimer les choses (quand le cours commence par "pas de boucles" * , ça fait étrange).
Puis on découvre une autre façon de concevoir les choses, et finalement le retour à un autre langage est bien douloureux. En tout cas je pense que c'est une excellent idée de l'enseigner, ça permet de programmer de façon intelligente, mais pour le reste, c'est vrai qu'à chaque fois que j'ai voulu faire des "vraies" choses avec, j'étais mal à l'aise. En revanche pour prototyper un algorithme complexe, c'est idéal...
Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?
:-(
* Oui je sais les boucles existent, mais ce n'est pas l'esprit du langage
[^] # Re: Dommage...
Posté par Thomas . Évalué à 5.
Ca me rappelle un petit texte que j'ai bien aimé, _The rise of "worse is better"_
Un essai de Richard P. Gabriel:
http://www.jwz.org/doc/worse-is-better.html
L'histoire par l'auteur:
http://www.dreamsongs.com/WorseIsBetter.html
On trouve même un article sur Wikipedia:
http://en.wikipedia.org/wiki/Worse_is_Better
Ca n'a pas trop de rapport avec la dépêche elle-même mais c'est intéressant pour ceux qui ne connaissent pas.
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 3.
1. Le problème programmation impérative <-> programmation fonctionnelle
2. Les autres trais du langages.
Pour le premier point, c'est clair que quand on dis à un étudiant qui sait déjà programmer (par exemple en C) qu'on va programmer sans variables et sans boucles, ça lui fait bizarre.
En fait, je pense qu'un bon programmeur devrait maîtriser les deux styles de programmation car les deux ne sont pas adaptés à toutes les situations: écrire un produit de matrice de façon fonctionnelle, c'est ridicule et écrire un algo de résolution des tours de Hanoï impérativement, c'est l'horreur. De façon plus générale, je pense que pour manipuler des structures de données un peu complexes, l'approche fonctionnelle est supérieure et que pour beaucoup de choses plus basique l'approche impérative se justifie bien.
Pour ce qui est du second point, je trouve que
- la programmation par filtrage,
- avoir un système de modules paramètriques ,
- avoir un vrai typage fort,
- avoir un ramasse miettes pour la mémoire,
- ...
est vraiment très agréable.
Au final, je trouve dommage que les langages ayant du succès soient des langages assez basiques. Ceci dit, cela reste compréhensible car pour qu'un langage ait du succès, il faut qu'il possède une grosse communauté pour développer plein de bibliothèques. Or un langage trop évolué fait souvent appel à des concepts et des façons de programmer inhabituels et peu de développeurs vont s'y intéresser. Comme peut de développeurs s'y intéressent, la communauté reste réduite et le cercle vertueux de promotion du langage ne s'amorce pas.
Bref.
Je suis d'accord qu'OCAML est un bon langage sous utilisé.
[^] # Re: Dommage...
Posté par gasche . É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: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 3.
Et ne me dites pas que les boucles for ou while sont plus naturelles. J'ai assuré un TP d'algorithmique de base et au vu des problèmes de mes étudiants, je peux vous assurer que ce n'est pas le cas.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 4.
Mais je me lance
> 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)
On fait le produit des matrices mata et matb.
pour cela, on définit une fonction coeff li col qui donne le coefficient li,col de la matrice produit. Pour rappel, c'est mata(li,0)*matb(0,col)+...+mata(li,n)*mat(n,col)
Pour calculer ce coefficient, on utilise un fold_left qui prend en argument plein de trucs.
On voit entre autre apparaître (fun k->mata.(li).(k)*matb.(k).(col)). Si on appelle f cette fonction, le coefficient est donc f(0)+f(1)+f(2)+...+f(n).
Passons maintenant au fold_left. cette fonction prend en argument une fonction f, une valeur et une liste. Par exemple,
fold_left f 0 [1;2;3] = f (f (f (0 1) 2) 3
La fonction (+) est l'operateur + préfixé, c'est à dire (+) 1 2=1+2.
Pour additionner tous les éléments d'une liste, il suffit de faire un
fold_left (+) 0 l.
Si on recolle les morceaux, pour que la fonction coef retourne ce qu'il faut, il suffit que init n f tourne une la liste [f(0);f(1);...;f(n)]. Dans ce cas,
1. init (length matb) (fun k -> mata.(li).(k) * matb.(k).(col)) retourne la liste
[mata(li,0)*matb(0,col),...,mata(li,n)*mat(n,col)]
2. le fold_left (+) 0 ... rend la somme des éléments de la liste soit, le coefficient de li,col de la matrice.
Maintenant qu'on a une fonction coeff qui marche, il suffit d'utiliser init pour faire une jolie matrice. Si on part du principe qu'une matrice, c'est une famille de vecteurs, on construire un vecteur ligne, il suffit de faire un
init n k->coef li k.
On remarque que cette fonction a un paramètre (li). La fonction
li -> (init n k->coef li k) est donc la fonction qui rend le li-ème vecteur ligne de la matrice. En l'itérant à coup de init, on obtient une matrice.
Je passe l'utilisation du try with.
Bref, que d'explications pour un code de 6 lignes.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Sois un code pareil existe en lib, sois il n'est jamais écris comme ça.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par mickabouille . Évalué à 2.
Et c'està mon avis bien plus facile à comprendre qu'un gros truc en impératif où faut pister les effets de bord.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Tu veux me faire croire que cette exemple est plus clair que l'algo avec les 3 boucles embriqués ?
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par reno . Évalué à 3.
Ceci dit je me souviens d'un article sur une manière d'optimiser le 'jeu de la vie' au lieu de représenter le jeu classiquement par une matrice, on passe a une représentation "récursive" (transformation type 'divide and conquer' loin d'être triviale d'ailleurs).
Bon le resultat n'est pas plus lisible mais il y a un gros gain de perfomance.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Moi aussi, j'ai écris un code méga optimiser en C complètement illisible :
for(ii=0; ii<n ;ii=ii+K)
.for(kk=0; kk<n ;kk=kk+K)
..for(i=ii;i<ii+K;i=i+1)
...for(k=kk; k<kk+K ;k=k+1)
....tmp = A[i][k];
....for(j=0;j<n;j=j+1)
......C[i][j] = C[i][j] + tmp*B[k][j];
Et encore je suis gentil, j'ai viré du code asembleur x86 pour le prefetch.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
for(ii=0; ii<n ;ii=ii+K)
.for(kk=0; kk<n ;kk=kk+K)
..for(i=ii;i<ii+K;i=i+1)
...for(kkk=kk;kkk<kk+K;kkk+=4){
....tmp6 = A[i][kkk];
....tmp7 = A[i][kkk+1];
....tmp8 = A[i][kkk+2];
....tmp9 = A[i][kkk+3];
....for(j=0;j<n;j=j+128){
.....for(jjj=j;jjj<j+128;jjj+=2){
......C[i][jjj] += tmp6*B[kkk][jjj]+tmp7*B[kkk+1][jjj] + tmp8*B[kkk+2][jjj]+tmp9*B[kkk+3][jjj];
.....C[i][jjj+1] += tmp6*B[kkk][jjj+1]+tmp7*B[kkk+1][jjj+1]
+ tmp8*B[kkk+2][jjj+1]+tmp9*B[kkk+3][jjj+1];
}
Toutes ces boucles embriquées et ces indices dans tous les sens, c'est beau non ?! :)
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par Troy McClure (site web personnel) . Évalué à 2.
http://www.power.org/resources/devcorner/cellcorner/codesamp(...)
[^] # Re: Dommage...
Posté par gc (site web personnel) . Évalué à 1.
[^] # Re: Dommage...
Posté par gc (site web personnel) . Évalué à 2.
bon choix de noms de variables, de fonctions, indentation et style logiques et constants, egale grands progres (j'appelle ca l'autodocumentation)
[^] # Re: Dommage...
Posté par Chaddaï Fouché . Évalué à 2.
Personnellement je comprend ce code sans problème, pratiquement en le lisant. Ce n'est pas parce que j'ai un cerveau d'extraterrestre, c'est parce que j'ai déjà programmé en fonctionnel et j'ai l'habitude de raisonner avec des combinateurs de fonctions et des fonctions d'ordre supérieur.
Si tu n'as jamais fait que de l'impératif il n'y a rien d'étonnant à ce que tu ne comprenne pas ce code, mais es-tu véritablement certain que si on t'avait présenté le code impératif à trois boucle avant que tu ais commencé la programmation tu l'aurais mieux compris que ce code fonctionnel ?
Franchement je ne vois pas la difficulté, fold_left est une opération parfaitement naturelle, surtout avec un opérateur binaire comme ici, s'il avait appelé sa fonction coef 'coefficient_produit ligne colonne', tu aurais tout de suite compris de quoi il parlait...
--
Jedaï
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par Julien . Évalué à 1.
En classe, on apprend que pour A = B.C la valeur de A[i][j] est égale à la somme de B[i][k].C[k][j] pour k=1 à n.
Qui a parlé de boucle là ?
Soit, à la limite, on peu considérer que le "somme pour k de ... à ..." ressemble à une boucle, mais il n'y a pas de notion d'ordre contrairement à une boucle !
Par contre, les deux autres boucles, tu les as ajouté parce que c'est ta manière de penser en impératif.
----------
En fonctionnel, tu peux faire ca de la manière suivante (je prend pas la syntaxe CAML puisqu'elle fait peur)
soit les deux fonction B et C de [[1,n]]^2 dans R qui représentent les deux matrices du même nom (une fonction, une matrice, c'est la même chose finalement ...)
// calcule B[i][k].C[k][j] (on aurait pu en faire une fonction anonyme, mais ça fait peur ...
prod(B,C,i,j,k) := B(i,k)*C(k,j)
// la fonction A qui représente la matrice du même nom
// sum qui est classiquement fourni par une bibliothèque prend en paramètre deux entier (les bornes) et une fonction à un paramètre (prod dont on a fixé tous les paramètres sauf un)
A(i,j) := sum(1,n,prod(B,C,i,j))
[^] # Re: Dommage...
Posté par Thomas Douillard . Évalué à 2.
Héhé, ouais, si tu généralise la matrice pour qu'elle puisse être indicée par un ensemble quelquonque.
Genre soit la matrice Mij avec i,j ¤ {vert, bleu, rouge}
ou ... Mij avec i,j ¤ {R inter [0,1]}
dans ces cas là j'ai pas vraiment entendu parler de matrice ;)
[^] # Re: Dommage...
Posté par Julien . Évalué à 2.
[^] # Re: Dommage...
Posté par Thomas Gueze . Évalué à 2.
J'ai appris l'OCaml l'année dernière (je suis étudiant), et même si il rebute au début (notamment quand on a appris à programmer avec la méthode impérative), maintenant je trouve que c'est un langage qui vaut la peine d'être maitrisé.
C'est avec lui que j'ai appris l'approche fonctionnelle et une fois qu'on a appris les principes, c'est très agréable et pratique à utiliser.
[^] # Re: Dommage...
Posté par Dring . Évalué à 4.
"mais qu'est-ce que c'est que ce @@"
"c'est quoi ce width _ -> 0"
Et j'en passe. Bref, le concepteur du langage semble avoir pris un malin plaisir à aller à l'inverse de tout ce qui existait.
Peut-être que la syntaxe est formidable, qu'elle roxor des ours polaires, n'empêche qu'elle est illisible pour toute personne ayant fait de la programmation "classique" (c, basic, cobol, java, pascal, ...), et qu'à bien y regarder, on croirait que c'est fait exprès.
M'enfin, comme disait ma concierge, "pourquoi voir la méchanceté là où il n'y a généralement que la bêtise ?"
J'exagère et je provoque un peu (on est vendredi dans 30 minutes), mais mon sentiment, c'est que OCaml n'a aucune chance de s'imposer comme un langage majeur vu les handicaps qui lui ont été imposés en terme de syntaxe.
[^] # Re: Dommage...
Posté par gasche . É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 fmaz fmaz . Évalué à 3.
Pour le _ -> 0, c'est quelque chose de très puissant.
En OCAML, on peut faire de la programmation par filtrage (i.e. a coup de switch mais en beaucoup plus puissant).
Pour additionner les éléments d'une liste, on peut faire de la façon suivante:
let rec glop l=match l with
[] -> 0
| x::l2 -> 1+(glop l2)
le _ sert quand on ne moque du reste. Par exemple, pour tester si une liste ne contient qu'un seul élément (exemple débile, je sais), on peut écrire:
let foo l = match l with
_::[] -> true
| _ -> false
Dans l'exemple de la matrice, ce mécanisme est utilisé avec un mécanisme de récupérations d'erreurs.
Si on exécute un programme qui peut lancer des erreurs, on peut les rattraper à coup de try ... with
try
mon_code_principal
with
qu'est-ce que je fais en cas d'erreur
comme « mon_code_principal » peut lancer plusieurs type d'erreur, la section with
fait du filtrage sur le type d'erreur
try
mon_code
with
division_by_zero -> print "division par zéro = la tête à Toto"
| parse_error -> print "apprend à écrire banane !"
Dans le coup de la matrice, on a besoin de calculer la taille de la matrice. Il peut y avoir un problème avec une matrice vide et seulement dans ce cas. On fait donc un
try
length matb.(0)
with
_ -> 0
C'est tout.
[^] # Re: Dommage...
Posté par パパフラクス . Évalué à 3.
Par contre moi je ne m'habitue pas au développeurs qui ne prenne pas soin de nommer correctement les valeurs. Et ils sont assez nombreux chez les dev ocaml ;)
Haskell et Erlang ont des syntaxes qui mes semblent plus accessibles,
même si Haskell introduit par ailleurs aussi d'autres concepts tout aussi déroutants ;)
"mais qu'est-ce que c'est que ce @@"
Un truc bien avec ocaml, c'est qu'il y a un interpréteur.
Celui ci me dit que @@ est une fonction qui a ce type là
# let ( @@ ) f g x = f (g x);;
val ( @@ ) : ('a -> 'b) -> ('c -> 'a) -> 'c -> 'b =
On est bien avancé me direz vous (avec raison)
Je décode, c'est une fonction qui prends en argument
deux fonction f, et g, et une valeur x.
Les seules contraintes sur f et g, est que la "sortie" de g, doit être du type de l'"entrée de f". C'est pour cela qu'on voit que 'a apparait dans le typage de f, et de g.
La définition elle même est la même qu'en math: on applique g à x, puis on applique f au résultat
Exemple:
# let double x = 2 * x;;
val double : int -> int =
# let couple x = (x,x);;
val couple : 'a -> 'a * 'a =
# couple(double 2);;
- : int * int = (4, 4)
# (@@) couple double 2;;
- : int * int = (4, 4)
# (couple @@ double) 2;;
- : int * int = (4, 4)
La dernière forme est sous forme infixe.
On peut la décomposer pour mieux comprendre
# (couple @@ double);;
- : int -> int * int =
En effet, on est pas obliger d'appliqué complètment une fonction, au lieu d'avoir une valeur "simple" en résultat, on obtient alors une nouvelle fonction.
"c'est quoi ce width _ -> 0"
try .... with ...;;
permet de filtrer les exception.
Là ce qu'il fait c'est que s'il y a une exception, on retourne 0.
Bref, en tout cas il me semble clair que ça n'est pas un exemple idéal pour la programmation fonctionnelle:
l'auteur y introduit bcp de concepts d'un coup. Pour ma part, j'aurai essayé de faire plus clair, quitte à ecrire plus de lignes, et à nommée qq résultats intermediaires.
Mais je pense que Bluestorm a voulu nous montrer qu'il était possible d'écrire cela dans un langages fonctionnel,sans effet de bord, et non pas d'introduire progressivement les concepts de la programmation fonctionnelle.
Si on a jamais vu d'ocaml avant, je comprends que ça puisse faire mal au yeux ;)
[^] # Re: Dommage...
Posté par charled . Évalué à 1.
Si l'on veut s'éviter la peine de recoder une fonction Array.fold_left jouant sur deux tableaux (de toutes les façon, la fonction Array.fold_left est programmée en impératif), alors on peut simplement utiliser une référence qui facilite bien la tâche et qui montre bien que le caml et à la fois souple et évolué, car il sait profiter des bons aspects de plusieurs méthodes de programmation. Merci l'INRIA !
Je propose donc :
let produit mata matb =
....let coeff li col =
........let k = ref (-1) in
........(Array.fold_left (fun tot m -> incr k; tot + m * matb.(!k).(col)) 0 mata.(li)) in
....Array.init (length mata) ((fun f g x -> f (g x)) (Array.init (Array.length matb.(0))) coeff);;
[^] # Re: Dommage...
Posté par Jacques L. . Évalué à 1.
Euh ... non.
Démonstration :
- Tu bouges le petit pignon d'un cran vers la droite (1 -> 2, 2 -> 3, 3 -> 1) (ou vers la gauche, du moment qu'on garde le même sens) ;
- tu fais le (seul) mouvement possible entre les deux tours où le petit pignon n'est pas ;
Et tu recommences les deux étapes jusqu'à arriver à la solution.
[^] # Re: Dommage...
Posté par petitdragon . Évalué à 0.
Oui c'est vraiment dommage... C'est vraiment l'un des langages les plus complets au niveau concepts et l'un des mieux conçus.
> Pourquoi ce ne sont pas les meilleurs langages qui sont utilisés ?
Et les meilleurs systèmes d'exploitation ;-)
Il faudrait faire comme pour Linux, créer une communauté et nous battre pour le faire connaître et faire comprendre aux programmeurs Python ou PHP qu'ils pourraient faire des programmes beaucoup plus fiables...
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 2.
Le dernier exemple en date que j'ai sous la mais, c'est
le super ordonnanceur de monsieur Ingo Molnar qui
refait (en moins bien) ce qu'un universitaire à fait 11
ans avant lui.
cf. http://kerneltrap.org/node/8141. L'article cité par Ting
Yang est de 1996.
[^] # Re: Dommage...
Posté par chl (site web personnel) . Évalué à 4.
[^] # Re: Dommage...
Posté par Christophe Morvan (site web personnel) . Évalué à 4.
Ce qui est dommage c'est que l'universitaire n'ai pas envoyé de patch !
Le papier est de 96. Je ne pense pas que ce papier aurait pu donner lieu à un patch sur le noyau linux de 96. ;)
On peut imaginer que l'auteur du papier de 96 a depuis fait du chemin...
De plus son article trouve probablement des applications dans de nombreux autres domaines.
Aussi, c'est le propre de la recherche scientifique : produire des résultats qui trouveront une application ultérieurement. Chaque chercheur ne fait pas tout depuis l'archi théorique jusqu'à la mise en ½uvre pratique dans le système de tout un chacun.
Vu les messages, on peut raisonnablement penser que le patch en question verra le jour, et c'est ce qui compte.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 1.
Bref.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 3.
Avoir du code incorporé dans le noyau linux n'est que très peu valorisé académiquement. Un universitaire va donc faire un patch, faire des mesures et sortir un papier. Une fois le patch écrit, il y a beaucoup de boulot pour arriver à le faire incorporer au noyau. Il n'y a qu'a voir les problèmes de Con Kolivas pour faire incorporer son ordonnanceur, les frustrations et les rancoeurs que ça peut occasionner.
[^] # Re: Dommage...
Posté par Anonyme . Évalué à 2.
Et bien c'est bien dommage que tout le monde soit satisfait d'une publication. Je trouve ca assez symptomatique de la recherche : on fait un beau papier qu'on essaie de faire publier dans un magazine le plus prestigieux possible, après on se congratule entre chercheur, et puis après plus rien (bon, pas toujours, certes).
Il y a tant de belles choses a sortir des labo ! Personne ne va les chercher ... il faut les sortir soit même, comme, par exemple, faire son patch, et avoir la reconnaissance de l'industrie. Mais apparemment certains trouvent cela limite rabaissant.
[^] # Re: Dommage...
Posté par TeXitoi (site web personnel) . Évalué à 3.
Comme tu le dis, le problème, c'est pas vraiment que le chercheur ne cherche pas forcément à faire la promotion de sa recherche, c'est plutôt que personne n'en fait la promotion, et que personne ne va prendre les idées disponibles pour les appliquer.
En fait, c'est pas vraiment vrai : il suffie de voir les intégrations de Microsoft dans .Net des idées présentes dans OCaml, de regarder du coté de la recherche "appliqué", etc.
[^] # Re: Dommage...
Posté par Anonyme . Évalué à 2.
J'adore cette manière de retourner le problème. Mon discours était de justement dire que c'était aux chercheurs eux même de faire (et d'apprendre a faire) la promotion de leur recherche ... tous simplement parce que personne ne peut le faire ou le fera à leur place.
Mon idée était de dire qu'une application, même sommaire, est le meilleur moyen d'attirer l'attention pour faire la promotion. Comme personne ne peut le faire a leur place, les chercheurs doivent donc le faire eux même.
Et tu conclue par me citer un exemple avec un grand groupe industriel : les grand groupes sont les seules et uniques entités pouvant se permettre d'allouer du temps a se pencher et essayer de comprendre le travail des chercheurs. Est ce vraiment le modèle économique et social que le monde de la recherche souhaite ?
Il y aurait justement tellement d'ingénieurs/techniciens dans des entreprises plus modeste qui présenterais bien a leur patron des projets plus ambitieux ... si seulement il y avait quelque chose a présenter ...
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 6.
Certaines personnes sont douées pour chercher et trouver des trucs. Ce qu'elles produisent n'est certainement pas directement utilisable. Pour cela, il faut passer du temps pour polir, nettoyer, remettre en forme.
Ce travail de nettoyage, c'est plus celui d'un ingénieur de recherche. L'ingénieur doit évidemment travailler avec le chercheur.
Les chercheurs pourraient éventuellement passer du temps en polissage mais
- ce n'est pas ce qu'on leur demande. Il vaut mieux qu'ils inventent d'autres trucs que d'autres nettoieront ;
- ils ne sont pas forcément doués pour cela.
Je préfère qu'un Dijkstra, qu'un Knuth ou qu'un Tarjan passent leur temps à produire des trucs monstrueux qu'eux seuls peuvent trouver et que d'autres personnes fassent le lien.
Même au sein de la recherche la plus fondamentale, on retrouve ce genre de schéma. Pour parler d'un sujet que je connais bien.
1. Il y a 20 ans, 2 gars ont pondu une démo pour une vieille conjecture. La démo fait 600 pages. Pour une rapide introduction, voir http://en.wikipedia.org/wiki/Robertson-Seymour_theorem;
2. Un petit groupe de personne dont je fais parti passe beaucoup de temps à étudier cette démonstration pour bien la comprendre et pour la simplifier. C'est un bordel sans nom mais à force d'acharnement, sur ces 600 pages, on a réussi à faire fondre les 200 premières à moins de 40 pages
3. Ces 40 pages ont des implications très importantes en algorithmique théorique. Certains chercheurs essayent de faire les liens. On a donc maintenant de jolis algorithmes inutilisables pour plein de problèmes.
4. Certains chercheurs essayent de rendre ces algorithmes vraiment utilisable en pratique. Il existe maintenant des « proof of concept » super efficace pour certains problèmes particuliers.
5. Certains chercheurs commencent à écrire des bouquins « pour les masses » pour que certains ingénieurs de recherche apprennent ces concepts.
Avec un peu de chance, d'ici 20-30 ans, le travail commencé il y a 20 ans sera vraiment utilisé.
[^] # Re: Dommage...
Posté par Hal9000 . Évalué à 2.
Dans le public, il n'y a pratiquement pas d'ingenieurs de recherche tels que tu les decris. Et malheureusement, des boites privees qui financent des ingenieurs pour tirer quelque chose de la recherche academique, il n'y en a pas beaucoup non plus (du moins en France).
Les chercheurs peuvent donc se bercer d'illusions et affirmer que leur recherche sera appliquee dans quelques decennies, il est tres clair que dans 99% des cas (et meme probablement plus), si ils ne s'interessent pas a la valorisation de leurs travaux, personne d'autre ne s'y interessera non plus.
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 3.
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 2.
Pour citer un exemple célèbre, il suffit de voir la discussion entre Torvald et Tannenbaum.
Bref, je suis persuadé que certains ingénieurs sont prêts à regarder ce que font les chercheurs et que certains chercheurs sont prêts à aider les ingénieurs. Le principal problème, c'est qu'il n'y a pas de vraie culture de transfert et donc, c'est difficile.
[^] # Re: Dommage...
Posté par Anonyme . Évalué à 1.
Mais il y a aussi un paramètre : le temps. En france, les chercheurs n'ont pas (plus que ca) a justifier le temps qu'il allouent a telle ou telle activité. Le réflexe des chercheurs, bien naturel, est d'allouer le maximum de temps a l'activité la plus prestigieuse, prometeuse, et parce que après tout c'est leur boulot, la recherche.
Mais mise a part la pénalité sur l'avancement de leur travaux, les chercheurs ne perdent rien (du moins en france) a passer du temps sur une application. Alors que pendant ce temps là, les entreprises, et leurs ingénieurs, s'occupent a s'assurer de quoi manger, se loger et vivre leur vieux jour a l'abris. (Le chercheur déconnecté de la réalité a souvent tendance a ignorer que la plupart des entreprise ne marchent pas bien, et donc, pas trop de sous a dépenser ni de temps a perdre).
C'est pourquoi, même si je suis d'accord avec toi, le problème est bipolaire, j'estime que c'est plus aux chercheurs de faire l'effort, tout simplement par ce qu'ils peuvent se le permettre.
[^] # Re: Dommage...
Posté par argt (site web personnel) . Évalué à 5.
Je suis d'accord que les personnes qui font de la recherche appliquée devrait faire des efforts supplémentaires (pour leur propre bien) pour valoriser leur travail par des applications, mais évitons de généraliser de trop. En particulier:
Je fais une thèse dans un laboratoire de recherche, les gens s'intéressent en général...aux choses qu'ils aiment faire, qu'ils connaissent et qui s'accordent avec leur conviction, sans regard pour le prestige.
<exemple lourd>Par exemple, (je suis spécialisé en Cosmologie, relativité, désolé pour les exemples donc) la communauté scientifique s'accorde plus ou moins sur un scénario dit inflationiste de l'univers, une activité prestigieuse est d'essayer de faire des prédictions sur ce scénario. Deux des professeurs les plus renommés de mon groupe font des recherches inverses, sur une théorie sans inflation, donc beaucoup moins populaire.</exemple lourd>
Bref, tout ça pour dire que ta vision des chercheurs me semblent un peu réduite. De même, le la recherche académique dans de nombreux domaines est très dure, compétitive, et demande de passer de longues heures de travail, week end compris. Si tu as la vision du chercheur babacool qui donne deux heures de cours par semaine et se la coule douce, eh bien, je peux te dire que dans mon groupe de recherche, c'est très différent, un grand nombre de personnes viennent le week end pour bosser, rentre tous les soirs après 21h où reçoivent des engueulades par leur femme parce qu'ils ont encore passé la nuit dans leur bureau. Certes, on ne travaille pas comme des personnes en banque d'affaires, mais c'est pas dit qu'on puisse "se le permettre". En tout cas, pas tous.
[^] # Re: Dommage...
Posté par zlnix . Évalué à 0.
Mais bien le thème de l'informatique dans sont ensemble. L'informatique n'est pas vraiment une science dure comme la physique, les mathématiques, la médecine ect… hors la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible. Voilà pourquoi il existe les R&D, car si l'on se creuse vraiment la tête c'est de là que sort vraiment l'innovation. La question pourrait se poser encore autrement "les chercheurs informatiques sont ils vraiment utiles à partir du moment ou leurs travaux se basent sur de l'appliqué (job des ingénieurs en R&D).
Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas.
[^] # Re: Dommage...
Posté par Jean-Baptiste Mayer . Évalué à 5.
L'informatique est une branche des maths, l'informatique est à base de maths et toute l'informatique c'est des maths.
Or qui dit maths dit démonstration.
Allez, on va sortir les gros morceaux de la calculabilité (discipline fondamentale de l'informatique), avec le modèle de Turing (machine de Turing), comment on démontre que les machines de type RAM (le PC en est une) est également une machine de Turing.
On sort également la preuve qu'il n'existe pas d'antivirus (application du théorème diagonal de Gödel) ou qu'il est impossible de prouver en un temps raisonnable et de façon automatique qu'un programme de la machine de Turing est correct (vérification de code?).
Inutile? ultra utile au contraire! car tu va chercher une sémantique de langage de programmation qui sera (presque) aussi expressive que la machine de Turing, tout en se restraignant à la partie qui est prouvable de façon automatique.
Si tu n'a pas envie de changer de langage, alors on va appliquer des outils de vérification de code qui vont vérifier que 1. tu restes dans cette restriction qui est prouvable et 2. que la preuve est correcte.
Allons un peu plus loin: la démonstration est nécessaire: tu accepterais de monter dans un avion si son logiciel n'était pas prouvé correct?
Toute l'informatique est une histoire de démonstration. Les mauvais informaticiens sont le plus souvent de mauvais mathématiciens.
[^] # Re: Dommage...
Posté par Anonyme . Évalué à 2.
Il faut noter que la réciproque est beaucoup moins vraie :)
[^] # Re: Dommage...
Posté par chl (site web personnel) . Évalué à 2.
[^] # Re: Dommage...
Posté par lasher . Évalué à 2.
Pardon ? L'informatique, c'est une branche des maths (comme il a déjà été dit ailleurs). D'un côté, tu as les informaticiens théoriques ; par exemple, qui eut cru que, pour assurer qu'un bête
tout une algèbre avait été créée ? Et crois-moi, l'algèbre en question est loin d'être triviale. La sûreté des types (chose qu'on retrouve en OCAML, certes, mais aussi dans des langages aussi communs que Java...), c'est avant tout du lambda calcul, c'est à dire des maths (petite anecdote : Church, à l'origine du lambda-calcul, avait comme thésard un certain Turing, à l'origine des machines du même nom ... Et à eux deux, on peut affirmer qu'ils sont à l'origine des tous les langages informatiques ou presque).
De l'autre, tu as les chercheurs faisant de l'informatique plus appliquée : étant donné un certain type de machine, avec un certain type de processeur, qui possède un certain nombre de caractéristiques (superscalaire, vliw, multithreadé, que sais-je), comment faire pour obtenir la meilleure performance pour un type d'application donné avec une méthode la plus générale possible ?
Il y a trop de paramètres en jeu pour pouvoir répondre à cette question de manière théorique (latence des instructions, latence des accès mémoires, problèmes de faux-partage, de deadlocks, etc) ; on est donc obligé de mesurer la performance de la méthode d'optimisation élaborée.
En fait, je pense que l'informatique est une science au même titre que la physique : comme elle, elle possède deux extrêmes (théorie et application), et une infinité d'intéractions entre les deux.
Contrairement à la médecine ou la pharmacologie, par exemple, qui profite bien entendu des progrès effectués en physique et en chimie, mais qui sont essentiellement expérimentales.
« la vrai vocation des chercheurs universitaire c'est au moins de pousser leurs recherches à la production de quelque chose de tangible »
Pas vraiment ; quand tu es dans le domaine de la recherche fondamentale (en maths ou en physique par ex), tu ne peux pas t'attendre à avoir tout de suite une application plus ou moins directe. En info théorique non plus, globalement (le nombre de papiers d'info théoriques qui traînent des théorèmes et autres équations, mais qui ne comportent pas de ligne de code est loin d'être négligeable). Quand tu es dans le domaine des sciences appliquées, par contre, tu as bel et bien des possibilités ... d'application, et là le chercheur a plutôt intérêt à montrer que ses recherches fonctionnent. Le seul problème, c'est que le chercheur, une fois qu'il a montré que sa solution était viable, il a autre chose à faire comme ... trouver la réponse à un autre problème.
Le seul moyen que je vois pour « proprifier » le travail du chercheur, c'est d'avoir un/des ingénieurs de recherche dans le même labo, qui travaillent avec lui, et implémentent proprement un prototype une fois qu'on sait que ça fonctionne. Seulement voilà : un ingénieur de recherche, c'est pas gratuit, et à moins de pouvoir ensuite se faire des sous avec le prototype, je ne vois pas pourquoi les labos s'embêteraient avec l'embauche de ce genre de gens (ça arrive, ceci dit, même en France).
« Encore une fois, derrière recherche il y a "tentative de démonstration d'une théorie" et l'informatique ne se démontre pas. »
Bien sûr que si. Un algorithme, ça se prouve ; une complexité algorithmique, ça se démontre ; une méthode de parallélisation efficace sur un type d'architecture, ça se conçoit puis se mesure ; les compilateurs passent leur temps à prouver que ton code est (in-)valide, du point de vue du langage utilisé ; les bases de données fonctionnent grâce aux propriétés algébriques grâce auxquelles on assure certaines propriétés (intégrité relationnelle, etc.).
[^] # Re: Dommage...
Posté par reno . Évalué à 1.
Mouai, euh dans l'affaire Tannenbaum n'est pas en reste non plus question mépris: "c'est nul votre truc, ça ne marche que sur x86"..
Quand on voit que beaucoup plus tard, Minix3 n'est developpé en pratique quasiment que sur x86 ..
Sinon un theme de recherche que j'ai bien aimé c'est une meilleure intégration entre le gestionaire de mémoire virtuel et le ramasse miette, maintenant que la JVM est libre, ce serait faisable..
Je n'arrive pas a recuperer l'URL mais c'est le premier resultat de 'vm aware garbage collector' sur Google.
[^] # Re: Dommage...
Posté par charled . Évalué à 2.
Il ne faut pas oublier que la plupart des ingénieurs sont formés par des chercheurs ! Ce que vous dîtes est vrai pour les décideurs qui sont sorti des écoles il y a bien longtemps.
Sans compter que presque tous les chercheurs ne font pas que du théorique, et que bon nombre de publications (peut-être trop même) sont des applications de la recherche à des problèmes concrets mais "mal" résolus. En réalité, la communication ne passe pas mal entre la recherche et l'ingénierie, mais ça prend du temps et de l'énergie, et que les décideurs sont un peu dépassés et considèrent que ça marchait très bien comme ça. La plupart ne vont pas prendre le risque de faire utiliser une technologie que personne ne maîtrise encore sans en avoir déjà vu quelques démonstrations concluantes.
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 3.
Un certain nombre d'étudiants considère que la fac, c'est un truc chiant qui ne sert qu'à leur permettre de rajouter une ligne sur leur CV et surtout pas à apprendre quelque chose. Les trucs utiles, ils les apprendront sur le tas.
[^] # Re: Dommage...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
S'il pensait autrement, il ne serait pas à la fac mais dans une école d'ingé.
... /me s'enfuit en courant.
"La première sécurité est la liberté"
[^] # Re: Dommage...
Posté par Frédéric Lopez . Évalué à 6.
[^] # Re: Dommage...
Posté par iug . Évalué à 0.
L'infrasctructure sur laquelle travaille beaucoup de chercheurs est à base de logiciels produits par des universitaires : C, Unix, OCaml...
De nos jours, les initiatives comme OCaml se font de plus en plus rares. Les chercheurs sont devenus des managers, et il n'y a plus grand monde pour pondre des contributions intégrables dans une machine de production. Les thésards, trop pressés par leurs deadlines produisent du code de prototype rarement transformé en code de production.
C'était mieux avant.
[^] # Re: Dommage...
Posté par パパフラクス . Évalué à 2.
Python est un langage bien conçu, comparé au PHP. Et je ne vois pas en quoi un programme Python serait mois fiable qu'un programme Ocaml. Car de toute façon, même en Ocaml, j'imagine que tu écris aussi des tests unitaires. Le typage n'est pas tout, il ne vérifier pas que ce que tu fais est bien ce que tu dois faire.
J'aime bien Ocaml, mais dans la vie de tous les jours, Python est bien plus armé, notamment en ce qui concerne les librairies.
[^] # Re: Dommage...
Posté par benja . Évalué à 2.
[^] # Re: Dommage...
Posté par TeXitoi (site web personnel) . Évalué à 3.
# if 1 > 2 then "toto" + 1 else 1 + 1;; This expression has type string but is here used with type int #("toto" est souligné) Donc on voit bien qu'en python, le code marchera jusqu'au jour où le test donnera "true", alors qu'en OCaml, il ne compile même pas...[^] # Re: Dommage...
Posté par パパフラクス . Évalué à 1.
Bcp de pro-typage statique négligent cette partie, pendant que le système de type les protège. Je maintient qu'on peut écrire du code correctement typé, ms qui fait n'importe quoi.
[^] # Re: Dommage...
Posté par TeXitoi (site web personnel) . Évalué à 2.
Mais, d'expérience, les tests unitaires sont beaucoup moins utile qu'en python : je n'ai jamais fait ressortir une erreur grâce à un test unitaire, car une fois que ca compilait, ca faisait ce que je pensais avoir programmé. Bien sur, il reste des erreurs parfois, mais ça a toujours été des erreurs dans des cas relativement complexes non mis en valeur par des tests unitaires.
Ensuite, un gros avantage des tests unitaires, c'est de pas tout casser accidentellement. Or, très souvent, une telle erreur casse directement la compilation.
Bref, à mon avis, les tests unitaires sont indispensable au développement en python, alors que ce n'est qu'un plus en OCaml.
Pour conclure, je pense donc que grâce à son typage statique fort, un programme en OCaml est plus fiable qu'un programme en python, pour répondre à « je ne vois pas en quoi un programme Python serait mois fiable qu'un programme Ocaml » (j'aurai dû préciser que je répondai à cette phrase).
[^] # Re: Dommage...
Posté par karteum59 . Évalué à 3.
Cela dit, je trouve personnellement dommage de ne pas avoir la surcharge des opérateurs. Certains me diront que c'est à cause de l'inférence de type, mais ce serait bien si on pouvait quand même avoir la possibilité (le choix) d'avoir de la surcharge, quitte à expliciter les types lorsque le compilateur ne s'y retrouve pas...
Autre chose : il me semble qu'il n'était pas évident d'interfacer une lib C/C++ et du code CAML (faire gaffe au GC, etc...). ça a changé ?
Le jour où je pourrai utiliser '*' aussi bien pour les flottants que pour les matrices ou les entiers, le jour où je pourrai facilement interfacer du code C pour les parties critiques ou avec des bouts en asm, là je considèrerai CAML comme mon langage favori ! (j'ai oublié d'ajouter "le jour où QT4 et it++ seront accessibles depuis CAML"...)
P.S.: question subsidiaire : pourquoi ont-ils développé leur compilateur totalement eux-mêmes plutôt que de contribuer à GCC ? ça aurait rendu le langage accessible sur plein d'autres plates-formes... !
[^] # Re: Dommage...
Posté par MiniMoi . Évalué à 3.
Alors, pourquoi ne pas oublier le typage automatique ?
Parce que c'est la force principale de OCaml. Il est connu et reconnu que le typage fort, strict et automatique prévient de beaucoup d'erreurs. En fait je dirais presque que si un code Caml compile, alors il marche. C'est un peu faux évidemment, mais pas si loin que ça de la vérité. De plus le typage paramétrique est vraiment extrèmement plaisant à manipuler, par exemple pour faire des conteneurs standards, c'est 100x mieux qu'en C++.
Sinon pour utiliser "*" sur des matrices tu ne peux pas mais tu peux avoir une syntaxe plus sympa par exemple avoir *_ en faisant :
let prefix*_ a b = matrix_mul a b;;
let c = a *_ b;;
Sinon pour la question sur le compilateur je dirais que c'est lié au fait que OCaml soit à la base un projet de recherche, très ancien, non placé sous licence GPL.
Donc initialement lorsque le projet a démarré, gcc n'existait pas et était encore moins multilangages.
De plus il me semble que certaines spécificités des langages fonctionnels permettent des optimisations pas forcément très claires sur la représentation interne de gcc.
Enfin, il ne faut pas oublier que OCaml doit tourner à la fois sur une machine virtuelle et sur un compilateur, et ce genre de chose doit êter pus difficile à obtenir avec le même comportement en écrivant d'une part un front-end gcc et de l'autre une machine virtuelle.
[^] # Re: Dommage...
Posté par gasche . É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: Dommage...
Posté par MiniMoi . Évalué à 1.
Je viens de parcourir en diagonale les slides, et il semble que la forme de surcharge prévue soit un peu moins puissante que celle prévue par le C++ par exemple.
De plus je me demande si les concepteurs de OCaml iront faire ceci, car la preuve du noyau de OCaml serait sans doute à refaire, ce qui doit prendre un certain temps. Après je n'ai pas vu en détails, il suffirait peut-être d'adapter.
En tout cas ça va rendre l'UE "fondements de la programmation" plus difficile ;-)
[^] # Re: Dommage...
Posté par パパフラクス . Évalué à 1.
Et pourtant Haskell a aussi l'inférence de type. Je dirais donc que ça depend du modele de typage choisi.
En fait je dirais presque que si un code Caml compile, alors il marche.
oui, en tout cas il ne vas pas se vautrer ent laissant un core dump ;)
Mais on est pas a l'abris d'exception runtime. Et surtout, ton programme fait-il vraiment ce que tu veux qu'il fasse?
D'autre part, ocaml peut tourner en code natif, sur une machine virtuelle, ou en mode interprèté. Il me semble évident que que certaines parties du système sont communes à ces trois modes, et que le tout se marrie mal avec gcc(autant que je sache), donc autant utiliser le même code, tant qu'a faire.
La seul utilisation de gcc que je vois possible serait pour la génération de code natif, ms j'avoue que même là j'ai des doutes.
Je suis loin d'être un expert en gcc, et en compilation, ms par exemple, serait-il possible de générer du code optimisant la récursivité terminale avec gcc?
[^] # Quand même :)
Posté par fremo . Évalué à 1.
Il y a eu pas mal de discutions interessantes sur le sujet sur la ML de OCaml, par exemple:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/08/87b02(...)
ou
http://caml.inria.fr/pub/ml-archives/caml-list/2001/02/229ee(...)
[^] # Re: Dommage...
Posté par petitdragon . Évalué à 2.
Je suis en revanche d'accord avec toi sur QT4. Il manque clairement des bindings graphiques. Et lablGTK2 n'est pas assez documenté...
Cela dit, comme toujours dans le logiciel libre... rien n'empêche de monter un projet pour le faire...
[^] # Re: Dommage...
Posté par fmaz fmaz . Évalué à 2.
- utiliser *. pour les réels ;
- devoir déclarer le type de toutes les variables entières ou réelles ?
Franchement, *. est beaucoup plus économique. Après, c'est juste de la syntaxe et comme toujours, les programmeurs sont très attachés à leurs habitudes et si un langage décide d'utiliser # au lieu de * pour la multiplication, ils n'utiliseront pas le langage. C'est exactement la même chose que le fil de discussion sur les raccourcis sous vi et blender.
Dommage.
# Beurk, un langage impératif
Posté par Zakath (site web personnel) . Évalué à 6.
Vite, une injection de haskell !
Bon, on n'est pas vendredi mais ça avait pas l'air de démarrer alors je me dévoue...
[^] # Re: Beurk, un langage impératif
Posté par gasche . É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: Beurk, un langage impératif
Posté par gasche . É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 Gniarf . Évalué à 2.
[^] # Re: Beurk, un langage impératif
Posté par Peter Moulder . Évalué à 1.
(Cela dit, parfois on préfère écrire la version Θ(n log n).)
[^] # Re: Beurk, un langage impératif
Posté par Peter Moulder . Évalué à 1.
"it should be borne in mind that "purity" refers to the absence of RPLACA and RPLACD operations rather than the absence of side-effects"
(Traduction libre : "« Pureté », dans ce papier, indique l'absence d'opérations RPLACA et RPLACD plutôt que l'absence d'effets de bords.")
Tandis que dans le contexte de ce fil, ou bien dans le contexte des langages ocaml/haskell/mercury, les mots pur/impur indique l'absence/présence d'effets de bords.
[^] # Re: Beurk, un langage impératif
Posté par Zakath (site web personnel) . Évalué à 4.
Mon trollomètre a à peine tressauté en lisant ton message, peut mieux faire.
[^] # Re: Beurk, un langage impératif
Posté par gasche . É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 Zakath (site web personnel) . Évalué à 2.
[^] # Re: Beurk, un langage impératif
Posté par Tristram . Évalué à 2.
Mais avant que je ne raconte des conneries, mieux vaut aller sur wikipedia.
# Lisibilité et produit de matrices
Posté par judicael . Évalué à 6.
[^] # Re: Lisibilité et produit de matrices
Posté par Pierre Tramonson . Évalué à 2.
Suivi d'un tas de code incompréhensible...
Je ne suis pas sur que la démonstration soit convaincante.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Lisibilité et produit de matrices
Posté par Gniarf . Évalué à 2.
no, wait...
[^] # Re: Lisibilité et produit de matrices
Posté par fmaz fmaz . Évalué à 4.
Il part du principe qu'une matrice, c'est un tableau dont on veut remplir les cases.
Pour cela, il utilise la fonction
> let init_matrix f = Array.init n (fun i -> Array.init n (fun j -> f i j));;
qui prend en paramètre une fonction f à deux arguments et qui construit la matrice
f(0,0), f(0,1), f(0,2), f(0,3),...
f(1,0), f(1,1), f(1,2),...
f(2,0), f(2,1),...
f(3,0),...
Une fois qu'on a cette fonction, il suffit de donner en paramètre la fonction qui calcule le coëfficient. Je trouve cette approche très élégante.
Pour l'addition, c'est la fonction
> fun i j -> p1.(i).(j) +. p2.(i).(j)
qui me semble vraiment lisible.
Pour la multiplication, c'est la fonction
> fun i j -> sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
Cette fonction est un poil plus compliquée mais pas trop.
il a d'abord défini la fonction
sigma i j f ->
qui calcule f(i)+. ...+.f(j)
ainsi, sigma 0 (n-1) (fun k -> p1.(i).(k) *. p2.(k).(j))
calcule p1.(i).(0)*p2.(0).(j)+. ... +. p1.(i).(n-1)*p2.(n-1).(j), ce qui est bien la valeur voulue.
Pour définir la matrice identité, on utilise
fun i j -> if i=j then 1. else 0.
etc...
Bref, ce n'est pas parce que vous n'avez pas l'habitude de programmer de façon fonctionnelle que son code n'est pas élégant.
[^] # Re: Lisibilité et produit de matrices
Posté par gasche . É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: Lisibilité et produit de matrices
Posté par Moonz . Évalué à 2.
Heu...
On va dire que j'ai mal compris, là. Tu peux expliciter ? Parce que un compilo qui corrige tout seul des trucs, moi ça a plutôt tendance à me faire peur...
[^] # Re: Lisibilité et produit de matrices
Posté par MiniMoi . Évalué à 1.
Donc en fait si ton code compiles, il a beaucoup moins d'erreurs possibles que ton code C qui compile...
Par ailleurs la programmtion en Caml est souvent plus "sûre" car elle permet de coller de près aux concepts mathématiques. En effet de très nombreux algorithmes sont définis par des récursions, ou par "induction", ce qui se traduit littéralement en Caml...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.