Que pensez vous de F#?

[amnir]

Quelqu'un à t-il déjà utilisé le langage F# ?

http://research.microsoft.com/fsharp/fsharp.aspx

Qu'en pensez vous ?

[gorgonite]

Envoyé par amnir

Quelqu'un à t-il déjà utilisé le langage F# ?

http://research.microsoft.com/fsharp/fsharp.aspx

Qu'en pensez vous ?

jamais utilisé... langage crimosoft complètement fermé sans doute, comme d'habitude

[LLB]

De ce que j'ai lu, ils ont essayé de copier Caml. Ca a l'air moins abouti (normal), et y'a des fonctionnalités manquantes (c'est dommage). En revanche, ils ont introduit la surcharge de quelques opérateurs en built-in (+, -, *, /). Ca peut être agréable donc.
Si c'était compatible, ça pourrait être intéressant de bénéficier de .net (OCaml a assez peu de bibliothèques). Seulement, j'y crois pas trop à cette compatibilité...

Pour le moment, je reste sans hésiter sur OCaml.

[gorgonite]

Envoyé par LLB

De ce que j'ai lu, ils ont essayé de copier Caml. Ca a l'air moins abouti (normal), et y'a des fonctionnalités manquantes (c'est dommage). En revanche, ils ont introduit la surcharge de quelques opérateurs en built-in (+, -, *, /). Ca peut être agréable donc.
Si c'était compatible, ça pourrait être intéressant de bénéficier de .net (OCaml a assez peu de bibliothèques). Seulement, j'y crois pas trop à cette compatibilité...

Pour le moment, je reste sans hésiter sur OCaml.

pour infos, il parait qu'une version .net d'ocaml serait à l'étude...

[LLB]

Ca fait plusieurs mois que je n'utilise plus que ce langage et il me plaît beaucoup. Il manque encore de maturité, il n'est pas encore parfait, mais il me semble très prometteur.

En vrac, quelques fonctionnalités nouvelles, que j'apprécie beaucoup :
- syntaxe allégée, basée sur l'indentation (c'est en option)
- listes en compréhension (comme dans Haskell)
- augmentations de types (pour définir par exemple une fonction membre aux types sommes, ou autres types)
- surcharge d'opérateur, et ça, ça embellit la vie
- introspection, grâce à .Net
- affichage générique (print_any peut afficher n'importe quel type de variable)
- la bibliothèque StructuredFormat, pour redéfinir l'affichage du print_any (avec tout plein de fonctions, pour l'indentation, etc.)
- le type Seq (comme une liste, mais paresseuse, donc potentiellement infinie)
- et bien sûr, toute la bibliothèque .Net.

[funtix]

Salut
Pour ceux qui utilisent ou ont essayé F# qu'en pensez vous?

En France, on est assez mauvais... On a de bonnes idées mais elles ne sont pas exploitées a fond et mise en valeur. Je trouve que OCaml fait partie de ces projets qui gagnent à être connu. Microsoft a repris l'idée en créant F# : un OCaml à la sauce Microsoft...
J'ai un peu hésité à essayer car Microsoft à la facheuse tendance à ne pas respecter les standards. C'est le cas ici, puisque du code ocaml un temps soit peu important, ne compilera pas avec F# et l'inverse (F# vers ocaml) c'est pire (ajout de mots clés etc) ...

MAIS...
je débute en ocaml, et l'environnement F# est séduisant : complétion, type, coloration syntaxique, analyse de la syntaxe pendant la saisie, compilation facile, debug graphique etc...
Ca facilite pas de choses. Une bonne chose pour l'apprentissage!

Et puis vu F#, c'est du dotnet, c'est ouvert sur le framework .NET donc d'accéder à pas mal de choses.

Il se pourrait qu'avec F#, de nombreuses personnes découvrent ocaml à travers F#.

Quel est votre avis?

++

[gorgonite]

petite confrontation OCaml vs F# à partir de ce post http://www.developpez.net/forums/sho...2&postcount=24

[LLB]

Déjà, je te conseille de lire cette discussion (si ce n'est pas déjà fait) :
http://www.developpez.net/forums/sho...=237267&page=2

J'ai un peu hésité à essayer car Microsoft à la facheuse tendance à ne pas respecter les standards. C'est le cas ici, puisque du code ocaml un temps soit peu important, ne compilera pas avec F# et l'inverse (F# vers ocaml) c'est pire (ajout de mots clés etc) ...

Je ne suis pas d'accord. Il n'y a pas ici de "standard à respecter". F# est un nouveau langage (s'inspirant certes d'OCaml), je trouve normal qu'il prenne un certain nombre de libertés (sinon, on l'appellerait OCaml pour .Net). Xavier Leroy lui-même a conseillé à Don Syme de prendre des libertés et d'innover.

Mais c'est vrai qu'ils ont essayé d'être en partie compatibles. Ce qui est une bonne chose. Il est facile d'écrire du code qui fonctionne dans les deux langages. D'ailleurs, je crois que c'est le cas du compilateur F# : ce qui prouve que l'on peut écrire de grosses applications en restant compatible. Bien sûr, si tu prends un projet OCaml, il ne compilera pas directement en F#. Mais la conversion est plutôt simple (j'ai entendu des témoignages de gens qui ont converti d'assez gros projets).

La transition F# vers OCaml est plus dur... c'est normal. Tu aurais préféré qu'ils copient bêtement OCaml ? Non, l'intérêt est d'avoir un nouveau langage. Il est donc normal qu'ils aient ajouté des choses ! C'est même bien.

je débute en ocaml, et l'environnement F# est séduisant : complétion, type, coloration syntaxique, analyse de la syntaxe pendant la saisie, compilation facile, debug graphique etc...
Ca facilite pas de choses.

Oui, ça facilite beaucoup de choses sous Windows.

Une bonne chose pour l'apprentissage!

Pour l'apprentissage, je pense que le langage OCaml est bien plus adapté (plus rigoureux, plus cohérent, plus logique).

Il se pourrait qu'avec F#, de nombreuses personnes découvrent ocaml à travers F#.

Je dirais plutôt que : il se pourrait qu'avec F#, de nombreuses personnes découvrent le fonctionnel. Ce qui me semble être une très bonne chose. Je connais plusieurs exemples de personnes qui ont découvert F# alors qu'ils n'utilisaient que C#. Mais ça m'étonnerait fortement qu'ils passent à OCaml.

Quel est votre avis?

C'est un nouveau langage, donc ça ne peut être qu'une bonne chose. Les gens l'utilisent, ou pas, c'est à eux de choisir.

Personnellement, j'ai utilisé OCaml pendant des années, et j'utilise F# depuis 2 mois pour mon boulot. Il a un certain nombre de qualités et de défauts (notamment un manque de maturité) par rapport à OCaml. Je pense que OCaml reste plus intéressant pour le domaine de la recherche ; en revanche, la compatibilité .Net me semble un énorme atout pour F#, dans le domaine industriel.

[funtix]

J'ai suivi le lien que vous m'avez donné. C'est marrant puisque c'est de mon post initial que le thread s'est poursuivi sur F#. A l'époque je me posais la question de savoir quel langage choisir : ocaml ou scheme... Donc pour moi F# etait hors sujet.

Et puis j'ai fini par decouvir F#.

Pour l'apprentissage, je pense que le langage OCaml est bien plus adapté (plus rigoureux, plus cohérent, plus logique).

Tu peux préciser?

[LLB]

Les problèmes viennent d'une part du manque de maturité du langage (OCaml est vraiment abouti, F# est très récent) et d'autre part de la difficulté à concilier .Net et OCaml.

Caml est un langage fonctionnel (je ne parle pas de l'extension objet, vu que l'objet est n'est pas géré de la même façon en F#) ; alors que .Net est objet. Et les deux philosophies sont assez éloignées.

Au niveau du langage, on retrouve des différences entre les méthodes issues de .Net et les fonctions du langage et de ses bibliothèques propres. Je cite en vrac :
- les méthodes .Net sont très souvent surchargées, alors que les fonctions écrites en F# ne peuvent pas l'être (à l'exception des opérateurs, qui sont un peu particuliers)
- les fonctions du langage supportent l'évaluation partielle, mais pas les méthodes .Net (ce qui est normal : ce n'est pas possible, dans le cas général, de marier surcharge et évaluation partielle)
- les méthodes .Net ne sont pas des objets de premier ordre, contrairement aux fonctions du langage (par exemple, elles ne peuvent pas être directement passées en argument - il faut passer par une fonction anonyme). MAIS, cela est corrigé dans la prochaine version de F# (qui devrait être publiée d'ici une semaine).

Par ailleurs, OCaml est très abouti. Il existe un certain nombre de limitations arbitraires, dans le but de rendre le langage rigoureux.
F#, de son côté, a cherché à repousser ces contraintes, au prix parfois de la cohérence.

Par exemple, OCaml pose des contraintes sur la casse (pour la première lettre), interdit de réutiliser les mêmes noms de champs pour deux structures différentes, ne supporte pas la surcharge d'opérateurs.
F# n'a pas toutes ces limitations, mais cela se paie. On doit parfois ajouter des annotations de type pour que ça se passe bien.
Pour la surcharge d'opérateurs, la résolution de type se fait localement. S'il ne peut pas se décider localement, il utilise un type par défaut (généralement int) ou alors, il faut inliner la fonction (ce qui n'est pas toujours possible).
On se rend bien compte que le langage est du coup moins "pur" et qu'on touche directement les faiblesses du compilateur (pour ne pas montrer ses faiblesses, OCaml se cache derrière les contraintes arbitraires).

MAIS, F# est encore très récent, il évolue très rapidement. Et certains des problèmes que je cite devraient disparaître avec le temps.

[InOCamlWeTrust]

LLB a bien résumé, je crois, l'état des lieux.

Depuis quelque temps, je m'intéresse de très près à Haskell, et en particulier à GHC, le meilleur compilateur pour ce langage. Ma conclusion actuellement est sans appel : Objective Caml est bel et bien un langage non pas abouti, mais extrêmement abouti. Pourtant GHC est un sérieux rival, mais certaines choses font d'Objective Caml un langage de pointe, à commencer par sa capacité à se bootstrapper, ce qui le rend très portable, son garbage collector (une vraie merveille), ou encore sa librairie Unix, particulièrement complète et portable dans sa quasi entièreté y compris sur des systèmes non Unix.

La faiblesse d'Objective Caml aujourd'hui concerne son manque de moyens pour programmer des interfaces graphiques... et celà risque de faire, malheureusement, la différence avec F#.

mais certaines choses font d'Objective Caml un langage de pointe, à commencer par sa capacité à se bootstrapper, ce qui le rend très portable

Grmbl pardon ?? Ce qui fait que OCaml est portable, c'est qu'il a un compilo code-octet et que la machine virtuelle est écrite en C, et qu'il existe des compilo C pour tous les systèmes et toutes les architectures (à epsilon pres :-)). Sinon pour chaque proc, il faut évidement réécrire un backend différent. Bref, le bootstraping n'a pas grand chose à voir là dedans (surtout que la plupart des gens utilisent ocamlopt et non ocamlopt.opt, et donc la version code-octet.)

[InOCamlWeTrust]

Un compilateur bootstrappé est portable, étant donné que pour le construire tu n'as besoin que de très peu d'outils. Actuellement, pour construire ocamlopt tu n'as besoin que d'un compilateur C (pour construire la machine virtuelle et ocamlyacc, nécessaire), un shell compatible sh et make : ce n'est pas le cas de GHC par exemple, ce qui pose de gros problèmes de portabilité de ce compilateur, même si ça s'améliore à grands pas. Le fait d'avoir une machine virtuelle est un atout également, puisque ocamlc est déjà fourni en tant que byte-code dans la distribution, mais le bootstrapping joue plus qu'on ne pourrait le croire.

Envoyé par InOCamlWeTrust

Un compilateur bootstrappé est portable, étant donné que pour le construire tu n'as besoin que de très peu d'outils. Actuellement, pour construire ocamlopt tu n'as besoin que d'un compilateur C (pour construire la machine virtuelle et ocamlyacc, nécessaire), un shell compatible sh et make

Non non, je ne suis toujours pas d'accord ! Le compilo serait écrit en C et donc non bootstrapé dutout, juste compilé, ce serait pareil (et même encore plus simple :-)) Et il manque quelque chose aussi : tu as besoin d'être sur un processeur supporté (ce n'est pas le fait de "bootstraper" qui va inventer le code asm à générer et les optimisation à faire dessus ). Et c'est quand même bien ça le plus dûr, et qui fait que la version code octet est bien plus portable (il y a des compilo C pour toutes les architectures et tous les OS en gros, donc pas besoin de se fatiguer !)

[InOCamlWeTrust]

Si le compilateur est écrit en C, alors oui, il y a des chances que ce soit portable si les mecs n'ont pas fait de l'implementation-dependent ; le problème, c'est que dans le domaine des langages fonctionnels, on écrit le plus souvent son compilateur dans le langage implanté. Ce n'est pas suffisant pour se bootstrapper, comme le montre GHC, mais la capacité d'un langage à se compiler lui-même est déjà un gage de portabilité, que l'on crache du code-octet ou non.

[gorgonite]

Envoyé par InOCamlWeTrust

Si le compilateur est écrit en C, alors oui, il y a des chances que ce soit portable si les mecs n'ont pas fait de l'implementation-dependent

cela sera quand même assez difficile de ne pas avoir de morceaux implementation-dependent dans un compilateur ou un machine virtuelle en C... mais le fait qu'un compilateur existe déjà sur la plate-forme implique que les morceaux dépendants sont certainement dejà disponibles, et donc que quelques macros à la compilation régleront le problème du code portable

[LLB]

Je récupère un message tiré d'un autre thread, parce qu'il a plus sa place ici :

Envoyé par alex_pi

Je suis un bien piètre programmeur, je l'avoue volontier. Néamoins, je n'ai jamais une seule erreur de ségmentation, ou un seul plantage silencieux dans mes programmes. Pourquoi ? Parce que c'est tout simplement impossible dans le langage que j'utilise (sauf à se servir de l'infame module Obj ou Marshall, je vous l'accorde).

F# propose une alternative intéressante au module Obj. C'est le principe du boxing de .NET : on peut convertir (encapsuler) n'importe quelle valeur en objet (type obj). Et on peut récupérer la valeur plus tard. Ce qui est bien, c'est que l'on peut tester dynamiquement le type contenu.

Code :

1
2
3
4
5
6
7
8
9
> let rec foo = function
  | 0 -> box []
  | n -> box [foo(n - 1)];;
> foo 0;;
val it : obj = []
> foo 1;;
val it : obj = [[]]
> foo 2;;
val it : obj = [[[]]]

Code :

1
2
3
4
5
6
7
8
9
10
> let test x =
  match x: obj with
   | :? int -> printf "int\n"
   | :? string as s -> printf "string: %s\n" s
   | _ -> printf "unknown\n";;
val test : obj -> unit
> List.iter test [box 3; box "foo"; box 4.2];;
int
string: foo
unknown

Même chose pour le marshalling, il est safe.


Pour info, si des gens sont intéressés, une nouvelle version de F# est sortie aujourd'hui (slicing, arguments optionnels, arguments nommés, syntaxe light encore améliorée, etc.) :
http://blogs.msdn.com/dsyme/archive/...-released.aspx

On peut maintenant définir une classe, avec un constructeur, une variable locale et une méthode, en une seule ligne :

Code :

type Foo(x) = member f.square = x * x