Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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."
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
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.
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.
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é.
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#.
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.
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é.
eeeh je veux bien mais faire des interfaces graphiques "WYSIWYG" ça existe depuis Delphi 1 et Visual Basic 3 non ?Envoyé par LLB
Cela s'appelait initiailement des outils RAD...
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.
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 ?
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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#
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.
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...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Je l'ai étudié.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 )
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
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.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#
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 :
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.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
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...
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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.
Bien sûr. Personne n'a dit le contraire.Le code objet de OCaml est portable partout aussi
Oh.et je n'ai pas besoin d'installer trente-sept mille trucs dans tous les sens
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.
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.Sans compter que l'on peut aussi compiler vers du code natif de façon portable
Euh...quel est l'intérêt de faire du Windows-compatible
Je suppose que tu as fait une faute de frappe, mais je ne vois pas ce que tu as voulu dire.
Non. Tu ne développes pas du caca.il va falloir développer son caca pour .NET et pour DotGNU...
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.
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.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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.
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.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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 ?
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
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
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.
j'espère que la dernière phrase était une blague...
J'ai pas dit que MS avait reussi son coup.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 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.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager