Le B ça suxx - Page 2

./30 > Je te réponds en détail demain (si j'y pense ).

Flanker (./23) :
sérieusement ?

ben, microsoft a des labos de recherche. ces labos contiennent des chercheurs, ie des gens pas trop cons. c'est normal qu'ils s'intéressent au Langage avec un grand L.
(ps : ce post est un troll, en fait je suis plus tant que ça un intégriste de caml dans la vie)

Je savais que MS avait des labos qui s'intéressaient au ML, mais pas au OCaml .. moi qui pensais que ce langage était destiné à resté confiné dans les facs françaises ...

bah y a des gars de microsoft research qui travaillent sur le plateau du Moulon à Orsay, hein ^^, donc presque « dans une fac française » (c'est à 50 ou 100 m du bâtiment où j'ai la plupart de mes cours). En fait ils sont dans des locaux de l'inria futurs. (D'ailleurs je suis allé dans leur labo, et dans leur salle principale il y a un grand jeu de go, un jeu d'échecs géant et une table de ping-pong, c'est à ça qu'on reconnaît que c'est un truc privé )

oui enfin le type qui a fait ça est à cambridge, pas à orsay ^^

(tiens en visitant sa page je suis tombé sur http://blogs.msdn.com/dsyme/archive/2006/08/16/ActivePatterns.aspx , décidément c'est des gens bien )

BookeldOr (./31) :
./30 > Je te réponds en détail demain (si j'y pense ).

raté

C'est qui ? parce qu'apparemment les gens qui travaillent à Orsay (comme Cédric Fournet) appartiennent officiellement à microsoft research cambridge (enfin ceci dit ils sont effectivement pas très nombreux, la plupart des gens de Cambridge sont vraiment à Cambridge ^^)
sinon, oui, ils font des trucs bien chez MSR, j'avais commencé à regarder C-oméga il y a quelques mois, depuis j'ai pas eu le temps de continuer à m'y intéresser mais ça avait l'air de bien poutrer (déjà c'est inspiré du join-calculus qui poutre, donc... ) : http://research.microsoft.com/Comega/doc/comega_whatis.htm

[]Tout ça ne vaut bien sûr pas CDuce, mais bon[/]

ah oui ça a l'air sympa

(HS : tiens sinon c'est marrant C# 3.0 rajoute des lambda-expressions qui peuvent soit être considérées comme des fonctions anonymes normales, soit comme des arbres syntaxiques ^^ []mais ça ne vaut pas tunes, bien sûr[/])

Pollux (./30) :

BookeldOr (./25) :
Dans F#, le pattern matching ne me convainc pas du tout

qu'est-ce qu'il a ? (je connais pas trop F#, c'est juste ton post qui m'y a fait penser)

Sinon, il y a un port de OCaml pour .Net qui fonctionne assez bien (mais les sources ne sont pas encore ouvertes, ça ne devrait pas tarder), c'est assez rigolo d'ailleurs comme fonctionnement, ça reconstruit les types du lambda code (en fait les types sont virés dès le passage du typeur dans le processus de compilation d'OCaml).

le truc de PPS ? ça change qqch, concrètement, de recalculer les types ? je suppose que le parseur n'a pas bcp d'infos en plus, à part éventuellement des downcasts manuels qui n'ont pas d'influence sur le lambda-code...

BookeldOr (./26) :
Ah, et surtout, d'un point de vue runtime, la VM .Net n'est pas faite pour le fonctionnel bien typé (cf. managed code) efficace.

oui, je me souviens avoir entendu ce genre de choses, mais je me souviens plus exactement ce qui pose pb, tu as un lien ?

1. Désolé, je confondais avec Nemerle, je ne me suis pas penché sur celui de F# ...
2. Oui celui de PPS, ben recalculer les types c'est un peu bête, ça aurait été malin d'embarquer les types dans le lambda code...
3. Volà le lien http://www.google.com/ (dsl, un peu la flemme là )

Alors, vous en pensez quoi de F# ?
Personnellement, il me semble beaucoup plus utilisable qu'OCaml pour faire de vraies applications. En plus, le langage est bien plus accessible (syntaxe plus claire, surcharge, etc.).

Quant au pattern-matching, il est équivalent à celui d'OCaml. C'est pareil, même syntaxe, à une différence notable près : F# gère les active patterns depuis quelques semaines. Cela permet d'étendre le principe de pattern matching et de décomposer les types de la façon que l'on souhaite.

Pour alimenter le troll :
http://test.blog2geek.com/pourquoi-f-plutot-qu-ocaml--764.html

en gros ce lien c'est "ouin ouin je suis sous windows ouin ouin"

c'est plutot "Microsoft a rendu le caml utilisable"

mais bon j'y toucherais pas pour autant

Il n'y a pas que Windows (sachant que F# est portable). Juste que le support d'OCaml pour Windows est vraiment décevant, alors que Windows est quand même une plateforme très utilisée (à défaut d'être bien...).

Je pense surtout qu'OCaml est un très bon langage, mais qu'il est peu utilisable en général (i.e. autre que pour les chercheurs et les étudiants).

Mais si tu as des arguments contre, je t'écoute.

LLB (./42) :
Je pense surtout qu'OCaml est un très bon langage,

beuhahahahahahahahahahahahaha.

OCaml quand ça compile, ça s'arrête juste à la première erreur, donc tu crois qu'il y a peu d'erreurs.
OCaml indique très mal les erreurs, résultat, il faut trouver un éditeur de textes un poil élaboré pour pister les erreurs.
OCaml couplé à Emacs c'est un calvaire à utiliser.

tiens... LLB, OCaml... c'est un troll made in epita ça encore ?

Là, tu ne critiques pas le langage, mais le compilateur. Je pense qu'OCaml, en tant que langage, est bien conçu (avec un bémol pour la surcharge). Les problèmes, c'est ce qu'il y a autour : bibliothèques, environnement de développement, etc.

Et c'est justement là, la principale différence avec F#.

Zephyr :

Mmmh concernant le langage alors :

quand on définit un type genre type Machin = Prout of (int*int) | Zob of (Prout*Prout);; ça tourne très souvent aux parenthèses imbriquées imbriquées.
D'ailleurs pourquoi terminer une fonction OCaml par ";;" ?
Le langage est trop fortement typé et les messages d'erreur peu explicites (quand c'est pas du genre "Cette fonction s'utilise avec le type XY mais est utilisée avec le type XY ()")
On est obligé de faire du if then else, pas de if then (remarque, y'a les fonctions de filtrages pour ça mais bof quoi).

Yoshi Noir (./43) :

LLB (./42) :
Je pense surtout qu'OCaml est un très bon langage,

beuhahahahahahahahahahahahaha.

OCaml quand ça compile, ça s'arrête juste à la première erreur, donc tu crois qu'il y a peu d'erreurs.
OCaml indique très mal les erreurs, résultat, il faut trouver un éditeur de textes un poil élaboré pour pister les erreurs.
OCaml couplé à Emacs c'est un calvaire à utiliser.

Ben justement F# n'est pas censé avoir ces problèmes puisque c'est grosso modo comme C# pour l'IDE ^^

Yoshi Noir (./46) :
quand on définit un type genre type Machin = Prout of (int*int) | Zob of (Prout*Prout);; ça tourne très souvent aux parenthèses imbriquées imbriquées.

là tes parenthèses sont inutiles...

D'ailleurs pourquoi terminer une fonction OCaml par ";;" ?

pour rien, normalement c'est pas nécessaire ^^ (sauf si tu suis ta fonction par autre chose qu'une déclaration)

(quand c'est pas du genre "Cette fonction s'utilise avec le type XY mais est utilisée avec le type XY ()")

ça c'est parce que tu définis deux fois le type XY...

On est obligé de faire du if then else
, pas de if then (remarque, y'a les fonctions de filtrages pour ça mais bof quoi).

si ton then renvoie un unit je crois que le else est bien optionnel (sinon évidemment si tu renvoies autre chose qu'un unit caml peut pas deviner la bonne valeur...)

Yoshi Noir (./46) :
On est obligé de faire du if then else, pas de if then (remarque, y'a les fonctions de filtrages pour ça mais bof quoi).

C'est faux et ça montre que tu n'as rien compris aux concepts du langage.
"if A then B else C" est une expression qui renvoie une valeur, et qui est donc typée. Pour un type quelconque, ça n'a pas de sens d'omettre le else, quelle valeur choisir dans le cas où le test serait faux ? Pour le type unit en revanche (ie quand on veut faire un "if then else" style C, qu'on execute juste pour les effets de bord mais pas pour le résultat), on peut omettre le else, et "if A then B" est équivalent à "if A then B else ()" quand B est de type unit.

quand on définit un type genre type Machin = Prout of (int*int) | Zob of (Prout*Prout);; ça tourne très souvent aux parenthèses imbriquées imbriquées.

Ben... non?

Prout(1,2)
Zob(0,-1)

D'ailleurs pourquoi terminer une fonction OCaml par ";;" ?

Seulement dans le top-level.

Le langage est trop fortement typé

Le langage est strictement typé, c'est une qualité

et les messages d'erreur peu explicites

C'est le problème du compilateur, pas du langage.

(quand c'est pas du genre "Cette fonction s'utilise avec le type XY mais est utilisée avec le type XY ( )")

Tu as défini deux fois le même type, c'est crade.

On est obligé de faire du if then else, pas de if then

ben non...

if true then ();;

Simplement, quand il n'y a pas de else, la clause "then" doit être de type unit (ce qui est logique).


(cross)

Merci Pollux pour les réponses.

En effet, les ";;" ne servent à rien et sont déconseillés (ils servent juste en mode interactif pour indiquer la fin de la commande, quand on utilise l'environnement basique).

Et le else est en effet optionnel quand c'est un type unit (comme dans presque tous les langages...).

En C, ce sont 2 syntaxes totalement différentes: foo?bar:baz contre if (foo) bar; else baz;.

Hippopotame (./49) :

quand on définit un type genre type Machin = Prout of (int*int) | Zob of (Prout*Prout);; ça tourne très souvent aux parenthèses imbriquées imbriquées.

Ben... non?

Prout(1,2)Zob(0,-1)

Sauf qu'attention, c'est pas vraiment Prout(1,2) mais plutôt Prout (1,2), donc après si on veut s'en servir comme d'une seule unité il faut faire (Prout (1,2))
(en fait c'est sans doute à ça que yoshi faisait référence, je croyais qu'il parlait de la définition du type)

et les messages d'erreur peu explicites

C'est le problème du compilateur, pas du langage.

Un peu aussi quand même : le langage ne fournit pas assez d'informations pour lire le cerveau du programmeur en cas de problème de type
(alors qu'en C, les type sont notés explicitement dans le code donc le problème ne se pose pas)

Pollux (./52) :
Sauf qu'attention, c'est pas vraiment Prout(1,2) mais plutôt Prout (1,2), donc après si on veut s'en servir comme d'une seule unité il faut faire (Prout (1,2))

Ton Prout tu l'appelles essentiellement comme argument d'une fonction.
Dans ce cas ça donne f(Prout(1,2)), je ne crois pas que ça soit davantage parenthésé que la majorité des langages...

Je trouve qu'en général caml aurait plutôt tendance à être moins parenthésé :
f(Bidule 12);;

prout_add (Prout (1,2)) (Zob (0,1)) (Zob (0,-1)) c'est quand même assez lourd en parenthèses ^^

Zob(0,-1))(comparé à Prout(1,2).add(Zob(0,1),)

Ouais mais ta dernière ligne on n'y comprend rien, c'est de l'objet ça n'a aucun sens. En plus ça casse la symétrie.

je savais que ça te ferait plaisir

c'est comme en lisp les parenthèses on finit par ne plus les voir

kestuveux, le premier prof à m'avoir parlé d'objets l'a fait d'une manière tellement traumatisante !

> (alors qu'en C, les type sont notés explicitement dans le code donc le problème ne se pose pas)

On *peut* mettre les informations de type explicitement. Donc, ça ne peut pas être un défaut. En général, on ne les met pas, parce que ça améliore la lisibilité et ça rend le code plus court.
Par ailleurs, avec un bon éditeur (genre Visual Studio pour F#), il suffit de passer la souris sur n'importe quel identifiant pour voir son type.

Pour les parenthèses, y en a pas plus que dans les autres langages (pas de comparaison avec Lisp !). On peut trouver des exemples et des contre-exemples, mais en moyenne, y en a pas tant que ça.
Compare :
f 3 4 5
avec
f(3, 4, 5);


Pour la notation objet avec le point, hé bien, cette notation est supportée par F#. En général, on peut convertir du code C# en code F# très simplement : on vire les ";", les informations de types et les parenthèses en trop, et beaucoup de code C# fonctionne (dans le corps d'une fonction, par exemple ; pas les déclarations de types).

Bon, je salue l'effort d'avoir fait un pavé, mais franchement ton article n'est pas terrible.
Y'a la critique de la lib standard, soit, mais elle revient très souvent donc c'était pas forcément la peine de le répéter , et moi je préfère une lib standard petite mais principalement fonctionnelle à la lib .Net.
Ensuite, la surcharge, je suis de ceux qui sont contre dans le cas général, ça crée des confusions, par contre pour les opérateurs standard, là si tu y tiens, ça se fait en 2 lignes de p4.
Ce qui nous mène au point primordial suivant : pas de f#p4.
Et puis, moi quand j'ai besoin de faire un programme certes pas le plus rapide mais avec de très bonnes performances quand même, j'hésite rarement à le faire en ocamlopt plutôt qu'en C. F# pose un problème de perfs quand on utilise beaucoup le style fonctionnel (et ça n'est pas la faute du langage, juste la vm .Net qui n'est pas du tout faite pour).
Tu parles de menhir, il faut voir qu'il n'est pas encore totalement au point, qu'il n'a pas les mêmes perfs qu'ocamlyacc donc il n'est pas ntégrable tout de suite, et puis il utilise un système de types trop expressif qui l'oblige à générer du caml non typable (donc avec des casts).
Quant à l'argument "c'est moins bien sous windows"... ben j'ai eu à faire du caml sous windows, j'ai simplement mis un emacs pour avoir le mode tuareg, et c'est fini, et y'a un plugin eclipse pour ocaml, qui d'ailleurs est l'objet d'un google SoC cette année (il me semble, enfin c'était une proposition en tout cas).
Et puis ocaml, c'est gratuit, c'est libre, emacs et tuareg, c'est gratuit, c'est libre, ...

Enfin bon, critique générale : il est très facile de critiquer ocaml dans pas mal de domaines, mais tu es passé à côté