Discussion :

[gasche]

Ma conclusion est que le modèle "licence gratuite + services" est certes viable, mais n'a pas l'air d'être le plus rentable. Bref, c'est une approche qui à de l'avenir c'est certain, mais ce n'est pas non plus la panacée.

Il faut aussi voir qu'il y a une période de transition.
Les gens paient de l'argent pour disposer (à la fin) de leurs outils informatiques. Ils l'ont toujours fait, et le feront toujours. La question c'est "où est dépensé cet argent ?".

L'habitude actuelle c'est de payer un peu pour le matériel, beaucoup pour le logiciel et pas tant que ça pour le support (je parle des boites généralistes, pas des machins spécialisés genre hébergeurs ou boîtes à grosses contraintes ou quoi). Ça n'a pas toujours été comme ça, au "début" (les applications scientifiques des premiers ordinateurs) par exemple les gens payaient beaucoup pour le matériel, et rien ou quasiment pour le logiciel (qui était livré avec ou conçu sur place).

Dans un tel modèle, forcément une boîte qui touche de l'argent sur le matériel (vente liée) et qui vend du logiciel marche bien, et les boîtes qui font du service ont plus de mal, parce qu'une fois que les gens ont payé leur logiciel, ils ne leur reste plus tant d'argent à "allouer" à l'informatique.

Mais si le modèle évolue, la situation peut très bien se renverser. Si de plus en plus de boîtes passent sur un modèle "libre + services", il va devenir de plus en plus dur de vendre du logiciel, et de plus en plus habituel que les dépenses informatiques se concentrent sur les services. Les modèles de rentabilité peuvent alors beaucoup évoluer.
Et ce n'est pas une pensée en l'air. On peut prendre un exemple concret : IBM distribue maintenant gratuitement sa suite bureautique (Lotus Symphony) (qui n'est cependant pas libre, même si IBM collabore avec OpenOffice/Sun), alors que traditionnellement ils ont toujours vendu Lotus.

[InOCamlWeTrust]

J'ajoute juste une chose : les marges dans les services sont beaucoup plus grandes que dans l'industrie. C'est peut-être une raison, mais certainement pas la seule, pour laquelle on évolue vers un marché du service.

Personnnellement, si j'avais de l'argent à dépenser, je préfèrerais prendre Solaris 10 gratuitement avec une assistance annuelle payante plutôt que d'acheter Windows cher et devoir me démerder tout seul dans mon coin quand quelque chose plante... car ce qui coûte de l'argent pour une entreprise, et là où part le temps disponible d'un particulier, en fin de compte, ce sont dans les pannes, bugs, erreurs d'installation, erreurs de configuration, et tout le bordel que l'on connaît tous.

[SpiceGuid]

Aujourd'hui: lancement de Visual Studio 2008 et .NET 3.5

http://weblogs.asp.net/scottgu/archi...-released.aspx

C'est moi ou il n'est pas question de F# (je ne vais pas télécharger tout le bouzin pour vérifier) ?

[LLB]

F# ne sera pas inclus dans 2008.

L'annonce citée au début du thread a été faite il y a quelques semaines. 1 ou 2 personnes ont été choisies pour travailler à plein temps dessus. Pour obtenir la même intégration dans VS que C# ou VB, ça demande du travail. Donc non, ce ne sera pas pour la version 2008.

De plus, il n'y a pas encore de version finalisée et stable de F#. Un certain nombre de changements sont prévus, il vaut mieux attendre une version finale avant de la distribuée en masse avec VS. Cela dit, le plugin F# peut être ajouté (séparément) sur la version 2008.

C'est donc une question une de maturité. De la même façon, les bibliothèques spécifiques à F# (celles adaptées de Caml) doivent être (pour le moment) compilées en statique avec le binaire. À terme, quand elles seront moins sujettes à variation, on pourra les utiliser en dynamique (voire, elles seront intégrées à .NET ?).

[InOCamlWeTrust]

C'est donc une question une de maturité. De la même façon, les bibliothèques spécifiques à F# (celles adaptées de Caml) doivent être (pour le moment) compilées en statique avec le binaire. À terme, quand elles seront moins sujettes à variation, on pourra les utiliser en dynamique (voire, elles seront intégrées à .NET ?).

Pas si sûr : c'est ce que l'on répète à chaque fois à propos des langages fonctionnels, quand on en vient à parler d'une intégration industrielle ou grande échelle.

Je pense plutôt, mais j'ai peut-être tort, qu'il s'agit d'une volonté de ne pas refroidir les clients ou utilisateurs de VS et .NET, très attachés aux langages impératifs à la C# ou Java... mais peut-être que je me trompe, car, dans le cas contraire, ça ferait déjà longtemps que l'on écrirait de grands projets en fonctionnel.

[LLB]

Comment ça ?

Ce qui est sûr, et c'était l'annonce de début de thread, c'est que F# va devenir un vrai produit Microsoft. Il sera intégré par la suite à VS - des gens y travaillent (en particulier Luke Hoban).

À partir du moment où F# sera un langage de "première classe", je ne vois pas de raison à ne pas inclure ses bibliothèques dans la distribution de .NET. Et même dans le pire cas, ces bibliothèques font moins de 2 Mo. Ce n'est pas comme si ça posait problème.

Je ne vois pas en quoi ça peut refroidir des clients ou utilisateurs de VS. :/

[InOCamlWeTrust]

Tu le sais aussi bien que moi : dès que tu parles avec les gens "de l'industrie", qui utilisent ce genre de trucs (VS, .NET et compagnie), des langages fonctionnels, au mieux, ils te rient à la figure... au pire, ils t'envoient chier.

Les personnes qui traditionnellement travaillent avec ce genre de langages (impératif objet) voient d'un très mauvais oeil les langages fonctionnels qu'ils considèrent comme immatures (va savoir pourquoi) : pour eux, écrire du fonctionnel, c'est comme jouer un partie de PACMAN.

Par expérience, je le sais.

J'ai même eu un prof qui me disait très franchement que OCaml n'était pas un langage viable pour de grandes applications industrielles, et que, il fallait s'y faire, tout le monde dans un futur proche programmerait en Java... !!! Quand tu parlais avec lui, il te faisait comprendre que c'était une hérésie que de coder en 3 lignes ce qui est fait en 50 classes dégueulasses Java !!! Cette personne est, entre autres, impliquée dans la conception de l'AFDX, nouveau standard servant actuellement à connecter les calculateurs de l'A380...

Il y a encore beaucoup de chemin à franchir sur ce point-là, et Microsoft, car ils ne sont tout de même pas cons finis, le sait très bien. C'est un problème d'image de marque. Du moment que de très grands industriels, des gens "sérieux" (mais qui programment avec les pieds beaucoup de fois), utilisent leur produit, si leur produit, c'est-à-dire VS et .NET, commence à intégrer des composants mal perçus ou considérés comme des jouets par leurs clients, c'est non seulement des pertes sèches, mais aussi une "réputation" (oui, beaucoup de gens ont énormément d'estime envers ces gens-là, la plupart du temps ne sachant eux-mêmes pas vraiment pourquoi) qui se casse la gueule.

Je serais toi, je n'attendrais pas grand chose de ceci... surtout que, du point de vue d'une entreprise comme Microsoft, mettre deux personnes sur un projet comme celui-là... c'est plus que de la rigolade.

Je comprends bien ton enthousiasme, mais je reste très sceptique sur l'histoire.

Mais ça reste un avis purement personnel.

[LLB]

D'accord, on verra bien.

Je suis d'accord avec toi sur certains points, je n'imagine pas F# remplacer Java/C# dans un futur proche. Il y a tout un tas de raisons qui font qu'une entreprise restera probablement sur C++/Java/C# : le nombre de programmeurs disponibles, la popularité, les habitudes, etc.

Mais je pense sincèrement que la part de la programmation fonctionnelle va augmenter un peu. J'ai vu plusieurs offres d'emplois F# chez Microsoft. Ce sont des projets internes (genre vérification automatique de drivers...), mais pour moi c'est une garantie : je pense que MS va continuer à faire vivre F#. Et même si ça ne remplacera évidemment pas C#, ça pourra rester une alternative viable pour un certain nombre de personnes (principalement amateurs) dont je fais partie. Si, en plus, ça me permet de trouver du boulot et de ne plus jamais avoir à utiliser un langage impératif, je serai ravi.

Enfin, un certain nombre de fonctionnalités de F# sont par la suite intégrées à C#. Les gens de l'industrie qui utilisaient C# 1, sont passés à C#2, puis ils passeront au 3, etc. À chaque nouvelle version, des fonctionnalités du monde fonctionnel sont ajoutées. Bien sûr, le mot "programmation fonctionnel" qui fait si peur à l'industrie n'est pas dit tout haut, mais le concept est là. Il est très pauvre par rapport à Lisp/Haskell/Caml, mais ça progresse à chaque fois.

Je comprends bien ton enthousiasme, mais je reste très sceptique sur l'histoire.

L'histoire des bibliothèques dynamiques, c'est vraiment un détail.
Ce que je souhaite surtout, c'est de pouvoir continuer à utiliser F#. Sur ce point, je suis confiant. Il corrige un certain nombre de faiblesses de Caml et, au moins pour un amateur, il est une excellente alternative à Java/C#.

[Garulfo]

[...]
Mais je pense sincèrement que la part de la programmation fonctionnelle va augmenter un peu. J'ai vu plusieurs offres d'emplois F# chez Microsoft. Ce sont des projets internes (genre vérification automatique de drivers...),[...]

Tiens t'as vu ça toi aussi

[SpiceGuid]

Bien sûr que la pérennité de F# est garantie, d'abord par la solidité financière de Microsoft, ensuite par (semble-t-il) l'engagement de Microsoft Research dans la programmation fonctionnelle.

Cependant dans l'immmédiat, mon sentiment c'est que le management de Microsoft suit une stratégie dans laquelle F# est loin d'être une pièce maîtresse:

• imposer Vista par la vente liée
• grâce à Vista, imposer C#
• grâce à C# et VB.net imposer la plateforme .Net
• ensuite seulement, MS peut mettre en avant F# sans fragiliser sa stratégie

J'ai parcouru le manuel en ligne de F#, les similitudes avec Caml sont limpides (et quasiment assumées), donc en tant qu'utilisateur de Windows XP-pro je devrai plutôt me réjouir puisque l'accès à .Net résoud quasiment tous les problèmes d'interface avec le code "externe".

Pourtant je ne m'engage pas dans cette voie parce que la suite est prévisible:

• la version actuelle tourne encore sous XP mais elle est mal documentée, avec des extensions exprimentales, pas encore de support officiel, en bref trop de problèmes de maturité
• le temps d'arriver à maturité il y a fort à parier que F# ne puisse plus tourner sous XP ou que .Net ne puisse plus décemment se contenter de 512Mo Ram ce qui bien entendu exclut un très grand nombre de machines sous XP

Avec OCaml, Windows98, 64Mo de ram et Crimson Editor on développe confortablement, en interprété comme en natif. Avec F# ce qui est proposé, ce n'est pas une meilleur interface avec Win32, c'est une meilleur interface avec WinFX.
Bilan: si je veux programmer pour Win32 j'utilise ma licence Delphi.

[LLB]

Tout à fait d'accord, sur ton analyse au début.

la version actuelle tourne encore sous XP mais elle est mal documentée, avec des extensions exprimentales, pas encore de support officiel, en bref trop de problèmes de maturité

C'est vrai. Beaucoup de fonctionnalités ont été ajoutées ces derniers mois, certaines étant expérimentales. Cela dit, tout ce qui est susceptible de changer plus tard génère un warning. Il y a aussi très peu de documentation actuellement, c'est lié à sa jeunesse. Si quelqu'un souhaite apprendre le langage, le plus sûr est d'acheter le livre Expert F# (publication dans quelques jours) qui est extrêmement complet et décrit toutes les dernières fonctionnalité.

le temps d'arriver à maturité il y a fort à parier que F# ne puisse plus tourner sous XP ou que .Net ne puisse plus décemment se contenter de 512Mo Ram ce qui bien entendu exclut un très grand nombre de machines sous XP

C'est une question de .NET et non de F#. Je l'utilise actuellement sous XP avec 256Mo de Ram, ça tourne. Mais je ne sais pas ce que ça donne sur un gros projet (faudrait regarder comment s'en sort C#).

Bilan: si je veux programmer pour Win32 j'utilise ma licence Delphi.

Delphi utilise maintenant .NET, il me semble. Les vieilles versions de Delphi sont-elles encore supportées ? Niveau pérennité, je ne suis pas sûr que ce soit le meilleur choix.

[InOCamlWeTrust]

Bien sûr que la pérennité de F# est garantie, d'abord par la solidité financière de Microsoft, ensuite par (semble-t-il) l'engagement de Microsoft Research dans la programmation fonctionnelle.

Ce sont des choses différentes ; tu peux être financièrement solide et arrêter un projet : il y a mille raisons pour ça...

[SpiceGuid]

C'est une question de .NET et non de F#.

C'est une question de ressources, si .Net se contentait de Win98se et 64Mo de ram alors je passerais tout de suite à F#.

Delphi utilise maintenant .NET, il me semble. Les vieilles versions de Delphi sont-elles encore supportées ? Niveau pérennité, je ne suis pas sûr que ce soit le meilleur choix.

Mes programmes en OCaml et Delphi 5 tournent (testés) de win98se à XPpro-sp2.
Ils tournent probalement aussi bien sous Vista (non testés).
Donc au niveau perennité ça me paraît un bon choix.
Au niveau compatibilité descendante .Net est une catastrophe.