Bonjour,

pour quelqu'un qui a connait très bien le C#, apprendre le F# m'apporte quoi? est ce que ça vaut le coup?

merci

ça t'enseigne un langage moderne. oui.

C# n'est pas moderne?

C# est récent mais dans les concepts utilisés, il n'est pas spécialement moderne. F# (qui est une sorte de clone de Caml) apporte un certain nombre de concepts intéressants et peu répandus. Donc c'est toujours intéressant de voir plusieurs style de programmation.

A noter que F# est open source depuis hier.

"A noter que F# est open source depuis hier. "

C'est vrai. Et même si ça avait été promis au début de son développement, c'est quand même impressionnant pour un produit microsoft qui est distribué dans visual studio.

apprendre F# ou ocaml est ce que ça revient au même?
F# n'est autre que ocaml utilisant le framework .net ?

non les langages sont quand même un peu différent : ocaml est plus "pur" et plus simple, plus efficace pour des programmes très fonctionnel (du à son GC optimisé pour ce genre de chose contrairement à celui de .NET qui n'est pas fait pour le taux d'allocation d'un programme fonctionnel). Par contre F# à un grand nombre de fonctionnalité qui ne sont pas dans Caml (de la surcharge, une représentation des valeur plus efficace pour faire du calcul numérique), sans compter l'accès à .NET.

Le cœur de ces deux langage est le même et apprendre l'un des deux permet d'apprendre l'autre assez rapidement.

c'est décidé alors, merci

J'avais commencé à étudier un peu F#, j'avais trouvé ça très bien conçu et très intéressant comme langage, mais ça m'avait aussi plus l'air d'être un outil par et pour des universitaires que pour des industriels. Peut-être est-ce que je me trompe ?

La plupart des développements professionnels pour dotnet sont fait en C#, si F# c'est devenu open source c'est surtout parce que ça fait un bide.

Bref la majorité des développements dotnet sont fait en C#, ensuite en VB.NET ou en C++, le reste c'est microscopique.

Bref chacun à ses objectifs et ses gouts, mais si c'est pour trouver du boulot la majorité des offres pour dotnet c'est C#.

c'est vrai, mais je voulais apprendre un nouveau style de programmation, une autre façon de concevoir mes progs

cependant j'ai fait un peu de recherche sur la toile et je pense que je vais apprendre haskell après je verrai pour F#

Tutoriel haskell : http://gorgonite.developpez.com/livres/traductions/haskell/gentle-haskell/

oui merci, j'ai déjà commencé à apprendre les bases. sinon je voulais savoir si j'ai bien fait de commencer par un langage fonctionnel pur?

C'est un très vaste sujet que de savoir par quel style de programmation débuter.

Tout le monde ou presque a son avis, et tout le monde avance des arguments convainquants.

Mon point de vue, de manière succinte (c'est rare, profitez en ! , c'est qu'il faut obligatoirement (j'allais dire impérativement) à un moment ou à un autre passer un moment à étudier un (bon) langage fonctionnel, et si possible le plus pur soit-il.
Et si possible, avant de se faire pourrir complètement la tête avec les langages objets, à mi chemin entre l'inexpressivité la plus totale pour des problèmes non antropomorphiques et le délire purement commercial.
(Mais bien sur, il faudra quand même regarder un langage objet à un moment, au moins pour comprendre les (pauvres) idées sous jacentes).

Après, quant à me prononcer entre commencer par un langage impératif ou un langage fonctionnel, je dirais que pour apprécier pleinement la beauté des langages fonctionnels, et l'abstraction qu'ils amènent, je pense qu'il est intéressant d'avoir vu avant des choses un peu moins sophistiquées, des choses un peu plus bas niveau, plus proche de la machine; et donc de commencer peut-être par un langage impératif.

Tu y utiliseras des pointeurs, tu y alloueras toi même ta mémoire, et tu verras qu'il y a un fossé entre un type abstrait algébrique et les possibilités de création de type offertes par ce genre de langage.

Alors, en découvrant un langage fonctionnel, tu verras comment des considérations d'un peu plus haut niveau peuvent permettent de représenter des choses qu'il était peu naturel de représenter avec des langages impératifs.

"La plupart des développements professionnels pour dotnet sont fait en C#, si F# c'est devenu open source c'est surtout parce que ça fait un bide. "

Il est possible que ça fasse un bide, mais il est quand même beaucoup trop tôt pour le dire. F# est sorti il y a tout juste 6 mois (avec Visual Studio 2010, avant c'était seulement un projet de recherche de microsoft). Si ça marche, on ne le verra que dans des années.

"Il est possible que ça fasse un bide, mais il est quand même beaucoup trop tôt pour le dire. F# est sorti il y a tout juste 6 mois (avec Visual Studio 2010, avant c'était seulement un projet de recherche de microsoft). Si ça marche, on ne le verra que dans des années."

La grande question pour savoir si ça va marcher ou non est : est-ce que les industriels vont le préférer aux langages C# et VB.Net ou pas ?
Et le choix que feront les industriels reposera principalement sur la rapidité et le coût de développement d'une application, mais pour l'instant, il est souvent plus rapide de concevoir quelque chose avec un langage objet qu'avec un langage fonctionnel. De plus former des programmeurs expérimentés et efficaces en C++/Java/C# à un nouveau paradigme pour lequel ils seront débutants, ça a un coût non négligeable en temps et en argent).
Si les universités décident de former des étudiants à OCaml ou F# et que le développement et la maintenance d'application s'avère plus rapide dans ces langages, alors peut-être que les industries adopteront ces nouveaux langages, mais pour l'instant je doute qu'elles le fasse.

"pour l'instant, il est souvent plus rapide de concevoir quelque chose avec un langage objet qu'avec un langage fonctionnel"

Je me demande bien d'où tu tire ça... En tout cas probablement pas de ton expérience personnel (je me trompe ?) si tu as effectué des proets d'une certaines envergure dans ces deux paradigmes, ni de l'expérience d'entreprise qui auraient elles aussi essayées les langes fonctionnelles.

Il y en a peu, mais les rares entreprises qui font l'essai des langages fonctionnels ne probablement jamais en arrière. Deux exemples dans le monde OCaml (mais il y en a certainement d'autre et aussi dans le monde Haskell, etc.) :
http://www.janestcapital.com/technology/ocaml.php
http://www.lexifi.com/technology/ocaml

Pour te citer, "le développement et la maintenance d'application *s'avèrent* plus rapide dans ces langages" (l'emphase est de moi).

La question de la formation est effectivement un problème. Les deux boites ci-dessus font de la finance et peuvent se permettre d'embaucher des chercheurs et/ou de former eux même leur programmeurs aux langages fonctionnels (généralement bien plus couteux (les programmeurs) que pour des langages objets par exemple). Mais les FAC forment aux langages fonctionnels, si ces formations prennent un côté un peu plus industrielle, il n'y aura pas de problème pour les industries pour recruter des programmeurs.

Les entreprises sont encore trop peu nombreuses à s'intéresser à ce genre de langage. Sur mes 5 années de fac, j'ai fait du Caml pendant presque 4 ans et au final ça fait sourire certains recruteurs quand je mentionne Caml sur mon CV.

Je sais, je suis moderateur et je ne devrais pas troller...

Mais les langages fonctionnel c'est un truc de matheux. Et 90% des developpeurs sur le marcher c'est des billes en maths. Le nombre de fois que j'ai entendu des conneries comme "ca monte et ca descend alors ca doit etre un sinus" de developpeur dans l'industrie est impressionnant.
Une grand majorite de developpeur ne comprennent rien a rien et font la plupart de leur developpement par copier/coller/bidouillage jusqu'a ce que ca marche. Et apres ils font des legos, il y a deux boites noires et on les branche ensemble. vous m'voyez!

</troll>

PS: J'ai rencontrer des gens tres bien aussi, hein... Mais il y a une proportion non negligeable de boulet.

"Je me demande bien d'où tu tire ça... En tout cas probablement pas de ton expérience personnel (je me trompe ?) si tu as effectué des proets d'une certaines envergure dans ces deux paradigmes, ni de l'expérience d'entreprise qui auraient elles aussi essayées les langes fonctionnelles."

Je tire ça d'une observation toute simple : à l'université j'ai suivi un cours de langage objet (Java), et un cours qui nous faisait travailler sur Prolog et Scheme, et globalement les étudiants concevaient des applications impressionnantes en Java avec un temps d'apprentissage très court tandis qu'ils galéraient en Scheme à concevoir de tout petits bouts de code (et ils avaient souvent cette expression à la bouche "putain mais pourquoi on peut pas utiliser une boucle for ça serait vachement plus simple").