Une nouvelle qui va réjouir LLB

Keihilin · 24/10/2007, 09h05

Lu ce matin :

F#, bientôt intégré dans VS.NET aux côtés de C#, VB.NET et C++

" Somasegar, vice président de la plateforme de développement et outils de Microsoft annonce que des pourparlers sont en cours avec MS Research et Don Syme pour intégrer F# (un langage fonctionnel) aux prochaines version de VS.NET. F# associé aux services techniques de .NET (DataBinding, Transactions, WCF, ...) serait une première. A suivre."

gorgonite · 24/10/2007, 09h47

intéressant en effet...

est-ce prévu pour visual studio 2008 ?

pseudocode · 24/10/2007, 11h11

ca n'existe pas déjà ???

http://research.microsoft.com/resear...2/details.aspx

gorgonite · 24/10/2007, 12h18

mais ce n'était pas en standard sous VS 2005

pseudocode · 24/10/2007, 14h12

Ah oui. C'est sur que c'etait pas en standard... Mais faut pas non plus être un développeur standard pour utiliser un langage fonctionnel.

LLB · 24/10/2007, 15h01

J'étais au courant le jour même (il y a une semaine).

Mais en effet, c'est une excellente nouvelle. De plus, j'ai rencontré recemment plusieurs offres d'emploi concernant F#... chez Microsoft. MS utilise de plus en plus ce langage, son avenir semble donc assez prometteur (il ne risque pas d'être abandonné sur le court terme).

Si F# bénéficie d'une intégration dans VS de la même qualité que C# (notamment le fait de faire des interfaces graphiques en WYSIWYG), il devrait gagner beaucoup en popularité.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mais faut pas non plus être un développeur standard pour utiliser un langage fonctionnel.

F# me semble plus accessible que les autres langages fonctionnels. Je connais un certain nombre de personnes qui utilisent F# comme premier langage fonctionnel et ils n'ont pas été dépaysés, pour ceux qui viennent de C#.

Convertir du code C# en F# est assez aisé : il suffit souvent d'ajouter des "let", de virer les informations de type, de virer les points-virgules en fin de ligne et d'enlever toutes les accolades. J'exagère un peu, la définition de fonctions ou de classes diffère, mais c'est pour dire que ce n'est pas compliqué (je l'ai fait souvent, vu que les exemples pour .NET sont généralement en C#).

D'ailleurs, C# intègre de plus en plus d'éléments fonctionnels (fonctions anonymes, inférence de type locale, linq, types anonymes...) et cela ne semble pas déboussoler les gens (même s'ils les utilisent peu, au final).

J'ai beaucoup d'espoir, et cette reconnaissance officielle de Somasegar (par opposition, ce n'était avant qu'un "simple" projet de recherche) devrait permettre à F# de gagner beaucoup en maturité.

Mat.M · 27/10/2007, 15h53

Citation:

Envoyé par LLB

Si F# bénéficie d'une intégration dans VS de la même qualité que C# (notamment le fait de faire des interfaces graphiques en WYSIWYG), il devrait gagner beaucoup en popularité.

eeeh je veux bien mais faire des interfaces graphiques "WYSIWYG" ça existe depuis Delphi 1 et Visual Basic 3 non ?
Cela s'appelait initiailement des outils RAD...

LLB · 27/10/2007, 17h09

Oui, mais utiliser des outils RAD avec un bon langage, j'ai jamais vu.

J'ai utilisé Delphi pendant 5 ans, j'avais utilisé VB à une époque, j'ai utilisé un peu C#... mais ce genre d'interface avec un langage fonctionnel, j'ai jamais vu. Je ne sais pas si cette intégration est prévue sur le court terme, mais ça apporterait vraiment un plus.

InOCamlWeTrust · 27/10/2007, 19h30

Moi qui aime bien les questions à la con, je vais en sortir une.

Pourquoi se cantonner à faire du Windows-compatible, donc non portable, alors que l'on peut tout aussi bien programmer de sorte à faire du code portable, qui marche sous une multitude d'OS et d'architectures différents ?

gorgonite · 27/10/2007, 19h48

Citation:

Envoyé par InOCamlWeTrust

Pourquoi se cantonner à faire du Windows-compatible, donc non portable, alors que l'on peut tout aussi bien programmer de sorte à faire du code portable, qui marche sous une multitude d'OS et d'architectures différents ?

pas tout à fait d'accord... la .Net est quand même plus portable que la Win32 (cf projet Mono)

en revanche, je n'ai pas assez étudié la CLI pour savoir si le jeu d'instructions virtuelles est adapté à un langage fonctionnel (et donc si F# a une réelle raison d'être

)

perso, lorsque j'ai étudié la JVM, je pense que plus de la moitié des instructions était trop éloigné de ce domaine... soit il était dédié aux langages objet, soit il était extrêmement bas niveau pour des opérations arithmétiques et logiques

par ailleurs, le faits qu'il y ait deux autres OCaml pour .Net, dont un développé avec un partenariat Microsoft-INRIA, n'est pas forcemment de bonnes augures pour F#

LLB · 27/10/2007, 20h11

Citation:

Envoyé par InOCamlWeTrust

Pourquoi se cantonner à faire du Windows-compatible, donc non portable

Au contraire. .NET a été conçu pour être totalement indépendant de la plate-forme. J'ai lu une partie des spécifications (ECMA) et rien ne se rattachait à Windows. Preuve en est : mono.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ uname
FreeBSD
$ echo 'printfn "Hello world!"' > hello.fs
$ mono fsc.exe hello.fs
$ mono hello.exe
Hello world!

J'ai utilisé plusieurs fois F# sous mono, dont une fois pour un projet de taille moyenne, je n'ai jamais rencontré la moindre incompatibilité. Je n'ai jamais eu à modifier la moindre ligne...

Citation:

en revanche, je n'ai pas assez étudié la CLI pour savoir si le jeu d'instructions virtuelles est adapté à un langage fonctionnel (et donc si F# a une réelle raison d'être )

Je l'ai étudié.
Il a été conçu pour être entièrement indépendant du langage. Il a été pensé pour permettre l'interopérabilité entre les langages, d'où un système de type commun, un système d'exceptions commun (si on lance une exception dans le code C#, on peut la rattraper en F#), etc.
Le CLI est un assembleur assez généraliste, à base de pile (il n'y a pas du tout de registres). Il est presque entièrement objet et est surtout orienté impératif. Mais ce n'est pas vraiment un problème, comme le montre le projet Ilx : http://research.microsoft.com/projects/ilx/ilx.aspx

Citation:

par ailleurs, le faits qu'il y ait deux autres OCaml pour .Net, dont un développé avec un partenariat Microsoft-INRIA, n'est pas forcemment de bonnes augures pour F#

1/ Je n'ai jamais vu personne l'utiliser. Quelle est sa vocation ? Et comme l'indique la news, ainsi que plusieurs offres d'emploi récentes, Microsoft soutient réellement F#. Je ne crois pas que F# puisse disparaitre au profit d'un OCaml.NET.
2/ F# n'est pas OCaml pour .NET, c'est un autre langage (héritant certes de Caml). Il a suffisamment évolué pour que l'on ne les confonde plus. Il possède suffisamment de nouvelles fonctionnalités et d'une très bonne intégration dans .NET pour qu'il n'y ait pas de risque (il a été conçu *pour* .NET). Preuve en est de son système objet.

EDIT :

Citation:

perso, lorsque j'ai étudié la JVM, je pense que plus de la moitié des instructions était trop éloigné de ce domaine... soit il était dédié aux langages objet, soit il était extrêmement bas niveau pour des opérations arithmétiques et logiques

Tu pourrais détailler les problèmes rencontrés (je ne connais pas la JVM). Fonctionnel n'est pas incompatible avec objet. Et les opérations bas-niveau, c'est normal pour un assembleur.

InOCamlWeTrust · 27/10/2007, 22h19

Le code objet de OCaml est portable partout aussi, et je n'ai pas besoin d'installer trente-sept mille trucs dans tous les sens : c'est pas un argument qui ne tient pas la route, d'après moi. Sans compter que l'on peut aussi compiler vers du code natif de façon portable, avec les mêmes options de compilation et les mêmes commandes... On retrouve aussi ce principe avec les grandes implantations de Haskell, mais de façon moins réussie, même si l'écart se comble avec le temps (c'est le signe que Haskell se porte bien !).

Donc, quel est l'intérêt de faire du Windows-compatible, d'un point de vue ingénierie pure et dûre ?

Sans compter qu'avec l'arrivée de DotGNU, il va falloir développer son caca pour .NET et pour DotGNU...

LLB · 27/10/2007, 22h42

Tu es pénible à devenir agressif à chaque fois qu'il y a un message sur F# (je ne ressortirai tes citations précédentes, mais j'ai pas oublié).

Tu dis que F# n'est pas portable, je te prouve le contraire.

Citation:

Le code objet de OCaml est portable partout aussi

Bien sûr. Personne n'a dit le contraire.

Citation:

et je n'ai pas besoin d'installer trente-sept mille trucs dans tous les sens

Oh.
Pour faire tourner ton code objet Caml, tu dois installer la VM Caml.
Pour faire tourner ton code objet F#, tu dois installer la VM .NET (et seulement ça).

Tu pourras prétendre que la VM Caml est plus légère, je rétorquerai que la VM .NET est plus diffusée.

Citation:

Sans compter que l'on peut aussi compiler vers du code natif de façon portable

C'est vrai. Chaque langage/implémentation a ses qualités et ses défauts. Tu me trouves un avantage de Caml, je peux te sortir 10 avantages de F#. Si tu veux, on peut lancer un vrai débat Caml vs F#. Je suis tout à fait partant, pourvu que tu cesses agressivité et mauvaise foi. Et ta première question était pleine de mauvaise foi : supposer la non-portabilité et supposer que F# n'a aucune qualité par rapport à Caml.

Citation:

quel est l'intérêt de faire du Windows-compatible

Euh...
Je suppose que tu as fait une faute de frappe, mais je ne vois pas ce que tu as voulu dire.

Citation:

il va falloir développer son caca pour .NET et pour DotGNU...

Non. Tu ne développes pas du caca.

Et dotgnu et mono sont juste des VM. Donc, tu utilises le même code objet que tu fais tourner sur une VM ou sur une autre. Après, tant que ton code utilise des fonctions qui sont disponibles partout, tu n'as pas de problème de portabilité. Si tu utilises des fonctions spécifiques à une plate-forme, c'est vrai, tu auras des difficultés... mais c'est pareil pour tous les langages.

InOCamlWeTrust · 27/10/2007, 23h26

Tu comprends ce que tu veux bien comprendre dans mes propos.

Je ne suis pas en train de dire que OCaml est supérieur à F#, même si j'en suis plus que convaincu : je ne soutiens pas plus OCaml que mon voisin d'à côté le XV de France fac aux argentins.

La question que je pose est une question qui me tient tout particulièrement à coeur : c'est celle de la portabilité des programmes (code source essentiellement), problème récurrent aujourd'hui.

En C, il existe plusieurs normes permettant aux applications d'être portables : la partie POSIX dédiée au langage et l'ISO en sont deux, par exemple (mais je ne t'apprends rien).

Ces normes ont été faites parce que les grands groupes du monde de l'informatique (à l'époque MS n'en faisait pas partie) ont compris qu'il auraient tout à gagner à se mettre d'accord sur une interface commune, indépendante du constructeur, à l'heure où il devenait vital, pour des questions de coût, donc de compétitivité, de porter les applications.

Ce principe est devenu, à coups de pieds dans le derrière, il est vrai, un dogme de l'informatique.

Aujourd'hui, avec l'avènement de MS, cet esprit se perd.

Cette boîte, au cas où tu ne l'aurais pas remarqué, utilise les différentes "technologies", dont .NET, pour verrouiller ses marchés et, à terme, étouffer toute l'industrie, et en particulier, puisqu'il s'agit de son secteur phare, les particuliers comme toi et moi.

.NET n'a pas été fait pour le bien de l'humanité, dans un élan inconditionnel de philanthropie : c'est aujourd'hui l'une des armes ultimes de MS pour s'accaparer et, je le redis, verrouiller, museler, la liberté des programmeurs.

Soutenir .NET, c'est, à terme, comme se tirer une balle dans le pied.

Je te mets ici un article tiré du New York Times : j'espère que ça te fera réfléchir...

Quoted here from the New York Times, July 25, 2002 (Late Edition, Section C, Page 6, Column 3) article "Microsoft Tries to Explain What Its .Net Plans Are About", written by John Markoff:

Microsoft sketched out an abbreviated road map today of how it will introduce products that offer .Net capabilities. One example was a communications server program with the code name Greenwich that is intended to enable advanced multimedia conferencing features for desktop and hand-held computer users. Another example was the next version of the company's database product, SQL Server, named Yukon, which is intended to make it easier to manage distributed data.

Finally, a brief demonstration was given of Windows Media Center -- a PC-based television that is intended to bring .Net-style information to the television in the living room.

Mr. Gates indicated, however, that the company's software promised land would be a new version of its Windows operating system with the code name Longhorn, which is still at least two years off.

Microsoft also warned today that the era of ''open computing,'' the free exchange of digital information that has defined the personal computer industry, is ending.

The company is trying to influence an industry consortium called the Trusted Computing Platform Alliance, which has been trying to create a new standard that will build a cryptographic key system into future personal computers.

LLB · 27/10/2007, 23h56

D'accord.
Le débat n'est pas tout à fait le même, en fait.

Ce que je remarque surtout, c'est que le concept de .NET me semble très intéressant. Une plateforme indépendante du langage, indépendante de l'OS, fournissant une très large bibliothèque. Grâce à .NET, il est très facile de combiner les langages. On peut faire une bibliothèque dans un langage et l'utiliser dans un autre (système de type commun, système d'exceptions, etc.). Grâce à .NET, tout nouveau langage, même marginal, peut survivre plus facilement : si on écrit un compilateur, on a gratuitement accès à de nombreuses choses. Grâce à .NET, il n'y a plus besoin d'écrire de binding pour chaque langage (regarde Caml, beaucoup de bibliothèques n'ont pas de bindings Caml et ce n'est pas pratique pour les utiliser).

Le concept donc, me semble intéressant. Maintenant, tu as raison : j'aurais préféré que ce ne soit pas Microsoft qui mette au point tout ça. J'aurais préféré que ce soit un comité indépendant, et promouvant le libre, qui crée tout ça. Malheureusement, ce n'est pas le cas.

Alors, que faire ? Refuser cette plateforme et utiliser des VM Caml (ou des binaires indépendants) ? Refuser cette plateforme et écrire sa bibliothèque pour manipuler des listes ou des matrices, pour chaque nouveau langage ? Refuser cette plateforme et en créer une autre, créant ainsi des incompatibilités, et demandant des années de travail ?

Ou alors, se dire qu'après tout, c'est pas si mal ? Les spécifications sont publiées, n'importe qui peut les implémenter. Des versions libres existent, pourquoi ne pas les soutenir ? Ces versions libres sont multi-plateformes : j'ai testé sous Debian et sous FreeBSD ; d'autres utilisent F# sous Mac. Et si jamais Microsoft prenait une décision contre l'intérêt général, alors pourquoi ne pas forker mono ? Après tout, le concept en lui-même n'est pas si mauvais.

J'ai hésité un moment avant de passer à F#. Sur ce forum, j'avais exprimé mes doutes la première fois. Mais finalement, F# n'est pas si mauvais que ça, niveau éthique : les sources sont diffusées avec le binaire, il m'est même arrivé de les lire et de proposer des patchs. Et surtout, au delà de l'aspect éthique, il y a l'aspect langage. Et justement, le langage en lui-même m'a convaincu. Il n'est certes pas parfait, après avoir étudié pas mal d'autres langages, fait un certain nombre de comparaisons, c'est F# qui me semble le plus prometteur.

InOCamlWeTrust · 28/10/2007, 17h26

La philosophie de .NET est bonne, en effet, même si je crois que l'on peut aller beaucoup plus loin (avec des sortes de routeurs logiciels mêlés aux serveurs à la J2EE... ça feait, je crois, un sujet de thèse intéressant). Ce qui me gêne, comme tu le dis, c'est qu'elle soit inexorablement rattachée à MS.

pseudocode · 28/10/2007, 18h01

Citation:

Envoyé par InOCamlWeTrust

Ce qui me gêne, comme tu le dis, c'est qu'elle soit inexorablement rattachée à MS.

C'est justement la raison d'etre de .NET.

Le coté "open" (ECMA) c'est juste pour désamorcer les foudres des anti-ms, et d'ailleurs ca marche plutot bien: la pression est plus du coté "mono" (qui court après les upgrades de .NET) que de MS (qui diffuse a outrance son framework, son modele et ses IDE)

La raison d'etre de .NET c'est de faire de Windows une (la) plateforme logicielle incontournable. Le "parc logiciel" c'est le nerf de la guerre et la raison de l'egemonie de MS sur le PC.

Fut une époque ou MS garantissait sa présence grace a ses seuls logiciels: IE, Outlook, Office, Visual... Mais des softs alternatifs sont apparus... Tant qu'ils necessitaient Windows, c'etait un moindre mal. Mais quand ces softs ont pu s'executer sur Linux... arg! D'ailleurs Linux est devenu une alternative credible du jour ou on a pu y fare tourner des logiciels usuels (et de bonne qualité).

Pour MS, la "course au logiciel" est une necessité. L'arme s'appelle .NET

L'objectif de .NET c'est de:
1. offrir aux developpeurs un grand choix de langage/librairie pour développer des applications pour Windows
2. offrir aux editeurs de compilo une specification qui leur garantit que leur compilo tournera sur Windows
3. assurer la compatibilité ascendante du parc des logiciels pour Windows

Tout le monde y trouve son compte: les développeurs, les editeurs et les utilisateurs... donc pourquoi s'inquieter ?

gorgonite · 28/10/2007, 18h14

Citation:

Envoyé par pseudocode

Pour MS, la "course au logiciel" est une necessité. L'arme s'appelle .NET

L'objectif de .NET c'est de:
1. offrir aux developpeurs un grand choix de langage/librairie pour développer des applications pour Windows
2. offrir aux editeurs de compilo une specification qui leur garantit que leur compilo tournera sur Windows
3. assurer la compatibilité ascendante du parc des logiciels pour Windows

Tout le monde y trouve son compte: les développeurs, les editeurs et les utilisateurs... donc pourquoi s'inquieter ?

j'espère que la dernière phrase était une blague...

1) la compatibilité ascendante n'est pas aussi "certaine" qu'avec Java (depuis la Jdk 1.2)
2) étant donné qu'une immense majorité des softs développés en .Net ne sont pas open-source, si certaines précautions n'ont pas été prises à la compilation , on peut se retrouver avec un programme exécutable avec uniquement la dernière VM (utile pour le déploiement

)

3) je ne rentrerais pas dans un débat idéologique

LLB · 28/10/2007, 18h21

Ou plutôt (en réponse à pseudocode) :
1. offrir aux developpeurs un grand choix de langage/librairie pour développer des applications
2. offrir aux editeurs de compilo une specification qui leur garantit que leur compilo tournera
3. assurer la compatibilité ascendante du parc des logiciels

Bien sûr, Windows y gagne. Mais pas seulement. Même si mono a toujours du retard sur .NET, mono est utilisable et apporte beaucoup. Préférez-vous donc vous opposer à .NET/mono, juste parce que ça profite à Windows, alors que c'est quelque chose qui va dans l'intérêt général ?

Perso, je soutiens les logiciels libres, pour servir l'intérêt général, pas pour essayer de faire du mal aux logiciels propriétaires. Si on me donnait le choix, je préfèrerais rendre Linux meilleur, plutôt que rendre Windows pire.

pseudocode · 28/10/2007, 18h27

Citation:

Envoyé par gorgonite

j'espère que la dernière phrase était une blague...

Citation:

1) la compatibilité ascendante n'est pas aussi "certaine" qu'avec Java (depuis la Jdk 1.2)
2) étant donné qu'une immense majorité des softs développés en .Net ne sont pas open-source, si certaines précautions n'ont pas été prises à la compilation , on peut se retrouver avec un programme exécutable avec uniquement la dernière VM (utile pour le déploiement

)
3) je ne rentrerais pas dans un débat idéologique

J'ai pas dit que MS avait reussi son coup.

J'ai juste ecrit l'argumentaire en faveur de .NET tel qu'il m'a été (plus ou moins) présenté aux ms-devdays.

Il faut voir aussi que .Net est une plateforme jeune. Il y a quelques années j'etais tres dubitatif sur le fait que MS puisse reussir son pari. Maintenant je pense qu'ils peuvent y arriver. Il restera toujours des applications qui ne rentreront pas dans le moule .NET (les jeux, les sgbd, ...) mais la majorité des nouveaux développement (from scracth) pour Windows se font avec .NET.

24/10/2007, 09h05	#1
Keihilin Inscrit Inscription : février 2004 Messages : 861 Détails du profil Informations personnelles : Âge : 34 Informations forums : Inscription : février 2004 Messages : 861 Points : 966 Points : 966	Une nouvelle qui va réjouir LLB Lu ce matin : F#, bientôt intégré dans VS.NET aux côtés de C#, VB.NET et C++ " Somasegar, vice président de la plateforme de développement et outils de Microsoft annonce que des pourparlers sont en cours avec MS Research et Don Syme pour intégrer F# (un langage fonctionnel) aux prochaines version de VS.NET. F# associé aux services techniques de .NET (DataBinding, Transactions, WCF, ...) serait une première. A suivre."
	00

24/10/2007, 09h47	#2
gorgonite Rédacteur/Modérateur Nicolas Vallée Ingénieur Système Inscription : décembre 2005 Messages : 9 774 Détails du profil Informations personnelles : Nom : Nicolas Vallée Âge : 27 Localisation : France Informations professionnelles : Activité : Ingénieur Système Secteur : Transports Informations forums : Inscription : décembre 2005 Messages : 9 774 Points : 14 303 Points : 14 303	intéressant en effet... est-ce prévu pour visual studio 2008 ? __________________ Evitez les MP pour les questions techniques... il y a des forums Contributions sur DVP : Mes Tutos \| Mon Blog
	00

24/10/2007, 11h11	#3
pseudocode Rédacteur/Modérateur Xavier Philippeau Architecte système Inscription : décembre 2006 Messages : 9 424 Détails du profil Informations personnelles : Nom : Xavier Philippeau Âge : 39 Localisation : France, Hérault (Languedoc Roussillon) Informations professionnelles : Activité : Architecte système Secteur : Industrie Informations forums : Inscription : décembre 2006 Messages : 9 424 Points : 14 133 Points : 14 133	ca n'existe pas déjà ??? http://research.microsoft.com/resear...2/details.aspx __________________ ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
	00

24/10/2007, 12h18	#4
gorgonite Rédacteur/Modérateur Nicolas Vallée Ingénieur Système Inscription : décembre 2005 Messages : 9 774 Détails du profil Informations personnelles : Nom : Nicolas Vallée Âge : 27 Localisation : France Informations professionnelles : Activité : Ingénieur Système Secteur : Transports Informations forums : Inscription : décembre 2005 Messages : 9 774 Points : 14 303 Points : 14 303	mais ce n'était pas en standard sous VS 2005 __________________ Evitez les MP pour les questions techniques... il y a des forums Contributions sur DVP : Mes Tutos \| Mon Blog
	00

24/10/2007, 14h12	#5
pseudocode Rédacteur/Modérateur Xavier Philippeau Architecte système Inscription : décembre 2006 Messages : 9 424 Détails du profil Informations personnelles : Nom : Xavier Philippeau Âge : 39 Localisation : France, Hérault (Languedoc Roussillon) Informations professionnelles : Activité : Architecte système Secteur : Industrie Informations forums : Inscription : décembre 2006 Messages : 9 424 Points : 14 133 Points : 14 133	Ah oui. C'est sur que c'etait pas en standard... Mais faut pas non plus être un développeur standard pour utiliser un langage fonctionnel. __________________ ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
	00

24/10/2007, 15h01	#6
LLB Membre Expert Inscription : mars 2002 Messages : 945 Détails du profil Informations forums : Inscription : mars 2002 Messages : 945 Points : 1 083 Points : 1 083	J'étais au courant le jour même (il y a une semaine). Mais en effet, c'est une excellente nouvelle. De plus, j'ai rencontré recemment plusieurs offres d'emploi concernant F#... chez Microsoft. MS utilise de plus en plus ce langage, son avenir semble donc assez prometteur (il ne risque pas d'être abandonné sur le court terme). Si F# bénéficie d'une intégration dans VS de la même qualité que C# (notamment le fait de faire des interfaces graphiques en WYSIWYG), il devrait gagner beaucoup en popularité. Code : Sélectionner tout - Visualiser dans une fenêtre à part Mais faut pas non plus être un développeur standard pour utiliser un langage fonctionnel. F# me semble plus accessible que les autres langages fonctionnels. Je connais un certain nombre de personnes qui utilisent F# comme premier langage fonctionnel et ils n'ont pas été dépaysés, pour ceux qui viennent de C#. Convertir du code C# en F# est assez aisé : il suffit souvent d'ajouter des "let", de virer les informations de type, de virer les points-virgules en fin de ligne et d'enlever toutes les accolades. J'exagère un peu, la définition de fonctions ou de classes diffère, mais c'est pour dire que ce n'est pas compliqué (je l'ai fait souvent, vu que les exemples pour .NET sont généralement en C#). D'ailleurs, C# intègre de plus en plus d'éléments fonctionnels (fonctions anonymes, inférence de type locale, linq, types anonymes...) et cela ne semble pas déboussoler les gens (même s'ils les utilisent peu, au final). J'ai beaucoup d'espoir, et cette reconnaissance officielle de Somasegar (par opposition, ce n'était avant qu'un "simple" projet de recherche) devrait permettre à F# de gagner beaucoup en maturité.
	00

27/10/2007, 17h09	#8
LLB Membre Expert Inscription : mars 2002 Messages : 945 Détails du profil Informations forums : Inscription : mars 2002 Messages : 945 Points : 1 083 Points : 1 083	Oui, mais utiliser des outils RAD avec un bon langage, j'ai jamais vu. J'ai utilisé Delphi pendant 5 ans, j'avais utilisé VB à une époque, j'ai utilisé un peu C#... mais ce genre d'interface avec un langage fonctionnel, j'ai jamais vu. Je ne sais pas si cette intégration est prévue sur le court terme, mais ça apporterait vraiment un plus.
	00

27/10/2007, 19h30	#9
InOCamlWeTrust Membre Expert Inscription : septembre 2006 Messages : 1 036 Détails du profil Informations forums : Inscription : septembre 2006 Messages : 1 036 Points : 1 129 Points : 1 129	Moi qui aime bien les questions à la con, je vais en sortir une. Pourquoi se cantonner à faire du Windows-compatible, donc non portable, alors que l'on peut tout aussi bien programmer de sorte à faire du code portable, qui marche sous une multitude d'OS et d'architectures différents ?
	00

27/10/2007, 22h19	#12
InOCamlWeTrust Membre Expert Inscription : septembre 2006 Messages : 1 036 Détails du profil Informations forums : Inscription : septembre 2006 Messages : 1 036 Points : 1 129 Points : 1 129	Le code objet de OCaml est portable partout aussi, et je n'ai pas besoin d'installer trente-sept mille trucs dans tous les sens : c'est pas un argument qui ne tient pas la route, d'après moi. Sans compter que l'on peut aussi compiler vers du code natif de façon portable, avec les mêmes options de compilation et les mêmes commandes... On retrouve aussi ce principe avec les grandes implantations de Haskell, mais de façon moins réussie, même si l'écart se comble avec le temps (c'est le signe que Haskell se porte bien !). Donc, quel est l'intérêt de faire du Windows-compatible, d'un point de vue ingénierie pure et dûre ? Sans compter qu'avec l'arrivée de DotGNU, il va falloir développer son caca pour .NET et pour DotGNU...
	00

27/10/2007, 23h26	#14
InOCamlWeTrust Membre Expert Inscription : septembre 2006 Messages : 1 036 Détails du profil Informations forums : Inscription : septembre 2006 Messages : 1 036 Points : 1 129 Points : 1 129	Tu comprends ce que tu veux bien comprendre dans mes propos. Je ne suis pas en train de dire que OCaml est supérieur à F#, même si j'en suis plus que convaincu : je ne soutiens pas plus OCaml que mon voisin d'à côté le XV de France fac aux argentins. La question que je pose est une question qui me tient tout particulièrement à coeur : c'est celle de la portabilité des programmes (code source essentiellement), problème récurrent aujourd'hui. En C, il existe plusieurs normes permettant aux applications d'être portables : la partie POSIX dédiée au langage et l'ISO en sont deux, par exemple (mais je ne t'apprends rien). Ces normes ont été faites parce que les grands groupes du monde de l'informatique (à l'époque MS n'en faisait pas partie) ont compris qu'il auraient tout à gagner à se mettre d'accord sur une interface commune, indépendante du constructeur, à l'heure où il devenait vital, pour des questions de coût, donc de compétitivité, de porter les applications. Ce principe est devenu, à coups de pieds dans le derrière, il est vrai, un dogme de l'informatique. Aujourd'hui, avec l'avènement de MS, cet esprit se perd. Cette boîte, au cas où tu ne l'aurais pas remarqué, utilise les différentes "technologies", dont .NET, pour verrouiller ses marchés et, à terme, étouffer toute l'industrie, et en particulier, puisqu'il s'agit de son secteur phare, les particuliers comme toi et moi. .NET n'a pas été fait pour le bien de l'humanité, dans un élan inconditionnel de philanthropie : c'est aujourd'hui l'une des armes ultimes de MS pour s'accaparer et, je le redis, verrouiller, museler, la liberté des programmeurs. Soutenir .NET, c'est, à terme, comme se tirer une balle dans le pied. Je te mets ici un article tiré du New York Times : j'espère que ça te fera réfléchir... Quoted here from the New York Times, July 25, 2002 (Late Edition, Section C, Page 6, Column 3) article "Microsoft Tries to Explain What Its .Net Plans Are About", written by John Markoff: Microsoft sketched out an abbreviated road map today of how it will introduce products that offer .Net capabilities. One example was a communications server program with the code name Greenwich that is intended to enable advanced multimedia conferencing features for desktop and hand-held computer users. Another example was the next version of the company's database product, SQL Server, named Yukon, which is intended to make it easier to manage distributed data. Finally, a brief demonstration was given of Windows Media Center -- a PC-based television that is intended to bring .Net-style information to the television in the living room. Mr. Gates indicated, however, that the company's software promised land would be a new version of its Windows operating system with the code name Longhorn, which is still at least two years off. Microsoft also warned today that the era of ''open computing,'' the free exchange of digital information that has defined the personal computer industry, is ending. The company is trying to influence an industry consortium called the Trusted Computing Platform Alliance, which has been trying to create a new standard that will build a cryptographic key system into future personal computers.
	00

27/10/2007, 23h56	#15
LLB Membre Expert Inscription : mars 2002 Messages : 945 Détails du profil Informations forums : Inscription : mars 2002 Messages : 945 Points : 1 083 Points : 1 083	D'accord. Le débat n'est pas tout à fait le même, en fait. Ce que je remarque surtout, c'est que le concept de .NET me semble très intéressant. Une plateforme indépendante du langage, indépendante de l'OS, fournissant une très large bibliothèque. Grâce à .NET, il est très facile de combiner les langages. On peut faire une bibliothèque dans un langage et l'utiliser dans un autre (système de type commun, système d'exceptions, etc.). Grâce à .NET, tout nouveau langage, même marginal, peut survivre plus facilement : si on écrit un compilateur, on a gratuitement accès à de nombreuses choses. Grâce à .NET, il n'y a plus besoin d'écrire de binding pour chaque langage (regarde Caml, beaucoup de bibliothèques n'ont pas de bindings Caml et ce n'est pas pratique pour les utiliser). Le concept donc, me semble intéressant. Maintenant, tu as raison : j'aurais préféré que ce ne soit pas Microsoft qui mette au point tout ça. J'aurais préféré que ce soit un comité indépendant, et promouvant le libre, qui crée tout ça. Malheureusement, ce n'est pas le cas. Alors, que faire ? Refuser cette plateforme et utiliser des VM Caml (ou des binaires indépendants) ? Refuser cette plateforme et écrire sa bibliothèque pour manipuler des listes ou des matrices, pour chaque nouveau langage ? Refuser cette plateforme et en créer une autre, créant ainsi des incompatibilités, et demandant des années de travail ? Ou alors, se dire qu'après tout, c'est pas si mal ? Les spécifications sont publiées, n'importe qui peut les implémenter. Des versions libres existent, pourquoi ne pas les soutenir ? Ces versions libres sont multi-plateformes : j'ai testé sous Debian et sous FreeBSD ; d'autres utilisent F# sous Mac. Et si jamais Microsoft prenait une décision contre l'intérêt général, alors pourquoi ne pas forker mono ? Après tout, le concept en lui-même n'est pas si mauvais. J'ai hésité un moment avant de passer à F#. Sur ce forum, j'avais exprimé mes doutes la première fois. Mais finalement, F# n'est pas si mauvais que ça, niveau éthique : les sources sont diffusées avec le binaire, il m'est même arrivé de les lire et de proposer des patchs. Et surtout, au delà de l'aspect éthique, il y a l'aspect langage. Et justement, le langage en lui-même m'a convaincu. Il n'est certes pas parfait, après avoir étudié pas mal d'autres langages, fait un certain nombre de comparaisons, c'est F# qui me semble le plus prometteur.
	00

28/10/2007, 17h26	#16
InOCamlWeTrust Membre Expert Inscription : septembre 2006 Messages : 1 036 Détails du profil Informations forums : Inscription : septembre 2006 Messages : 1 036 Points : 1 129 Points : 1 129	La philosophie de .NET est bonne, en effet, même si je crois que l'on peut aller beaucoup plus loin (avec des sortes de routeurs logiciels mêlés aux serveurs à la J2EE... ça feait, je crois, un sujet de thèse intéressant). Ce qui me gêne, comme tu le dis, c'est qu'elle soit inexorablement rattachée à MS.
	00

28/10/2007, 18h21	#19
LLB Membre Expert Inscription : mars 2002 Messages : 945 Détails du profil Informations forums : Inscription : mars 2002 Messages : 945 Points : 1 083 Points : 1 083	Ou plutôt (en réponse à pseudocode) : 1. offrir aux developpeurs un grand choix de langage/librairie pour développer des applications 2. offrir aux editeurs de compilo une specification qui leur garantit que leur compilo tournera 3. assurer la compatibilité ascendante du parc des logiciels Bien sûr, Windows y gagne. Mais pas seulement. Même si mono a toujours du retard sur .NET, mono est utilisable et apporte beaucoup. Préférez-vous donc vous opposer à .NET/mono, juste parce que ça profite à Windows, alors que c'est quelque chose qui va dans l'intérêt général ? Perso, je soutiens les logiciels libres, pour servir l'intérêt général, pas pour essayer de faire du mal aux logiciels propriétaires. Si on me donnait le choix, je préfèrerais rendre Linux meilleur, plutôt que rendre Windows pire.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email