Les pièges du monde réel de l'introduction de F # dans une grande base de code et une équipe d'ingénieurs [fermé]

37

Je suis CTO d'une société de logiciels avec une grande base de code existante (tous en C #) et une équipe d'ingénieurs importante. Je peux voir comment certaines parties du code seraient beaucoup plus faciles à écrire en f #, ce qui permettrait un temps de développement plus rapide, moins de bugs, des implémentations parallèles plus faciles, etc., essentiellement des gains de productivité globaux pour mon équipe. Cependant, je peux également voir plusieurs pièges de productivité liés à l’introduction de F #, à savoir:

1) Tout le monde doit apprendre le F #, et ce n'est pas aussi simple que de passer de Java au C #, par exemple. Les membres de l'équipe qui n'ont pas appris F # ne pourront pas travailler sur les parties F # de la base de code.

2) Le pool de programmeurs F # pouvant être embauchés, à compter de maintenant (décembre 2010) est inexistant. Recherchez dans différentes bases de données de curriculum vitae de l’ingénieur logiciel le "F #", ce qui signifie que moins de 1% des curriculum vitae contiennent le mot clé.

3) Le soutien communautaire à partir de maintenant (décembre 2010) est moins disponible. Vous pouvez google presque n'importe quel problème en C # et trouver quelqu'un qui l'a déjà traité, mais pas avec F #. La prise en charge des outils tiers (NUnit, Resharper, etc.) est également fragmentaire.

Je me rends compte que c’est un peu Catch-22, c’est-à-dire que si des personnes comme moi n’utilisent pas F #, la communauté et les outils ne se matérialiseront jamais, etc. Mais j’ai une entreprise à gérer pas saigner bord.

Y a-t-il d'autres pièges que je n'envisage pas? Ou quelqu'un veut réfuter les pièges que j'ai mentionnés? Je pense qu’il s’agit d’une discussion importante et je serais ravi d’entendre vos arguments contre ce forum public qui pourrait faire beaucoup pour augmenter l’adoption de F # par l’industrie.

nganju
la source
7
"Le groupe de programmeurs F # louables [...] est inexistant" - presque inexistant. Cependant, si vous trouvez un programmeur qui est ou est disposé à se spécialiser en F #, ils seront probablement très spéciaux.
Tim Robinson
Vous demandez des pièges réels, mais vous incluez des pièges potentiels dans votre question. C'est une invitation pour des pièges plus "imaginaires" dans les réponses, ou pour des réponses hors sujet réfutant les pièges que vous envisagez. Si vous auriez une opinion contraire à cause de ce problème de formulation (réputation trop basse)
Joh
Nick, je dirais: choisissez parmi les geeks linguistiques expérimentés et expérimentés que vous avez déjà et laissez-les jouer avec F # dans le but de rendre la société plus intelligente / meilleure / plus productive, et pas seulement pour le plaisir. Il y a quelques gars comme ça où je travaille.
Job

Réponses:

28

La recherche reprend pour d’autres langages fonctionnels tels que Scheme, Lisp ou Haskell. Beaucoup de gens les apprennent à l’école et les ont sur leur curriculum vitae; Je suis sûr que beaucoup d’entre eux ne voudraient pas apprendre le F #. Scheme est dans mon CV même si je ne l'ai jamais utilisé après les cours et qu'un travail impliquant F # aurait probablement aussi attiré mon attention.

MK
la source
13

Y a-t-il d'autres pièges que je n'envisage pas?

En pratique, la principale erreur que les gens commettent est d’essayer de forcer l’utilisation de F # pour les problèmes qui ne sont pas le bon outil pour le travail.

Ou quelqu'un veut réfuter les pièges que j'ai mentionnés?

Toutes ces préoccupations sont manifestement valables dans une certaine mesure, mais je me demande dans quelle mesure.

Par exemple, vous dites que tout le monde devrait apprendre le F # pour pouvoir travailler sur le code F #. Bien que vrai, ce n'est pas un gros problème dans la pratique. Apprendre le F # n’est pas plus important que l’apprentissage de WPF, Silverlight ou le TPL. J'enseigne à environ 30 développeurs comment utiliser F # pour un client à Londres et une douzaine d'entre eux travaillaient à plein temps sur le code F # après seulement quelques semaines et ils venaient de livrer leur premier produit (à temps et dans les limites du budget!). ) écrit presque entièrement en fa # après seulement quelques mois. En fait, ils avaient plus de difficultés techniques avec Silverlight que F # et ils ont constaté que le support technique de Silverlight était bien pire que pour F #.

Vous faites référence au bassin relativement restreint de programmeurs F # disponibles, mais, encore une fois, compte tenu de la facilité avec laquelle il est possible de capter F #, je ne pense pas que cela soit une préoccupation majeure. Je doute que vous deviez en embaucher plusieurs, le cas échéant. Mon client a deux membres F # pour plus de 100 programmeurs et notre travail consiste à créer et à superviser l’utilisation de F #.

Votre troisième et dernière préoccupation concerne moins de soutien de la communauté, de solutions Go # C pour C # par rapport au support F # et d’outils tiers. Encore une fois, je n'ai pas trouvé cela problématique dans la pratique. J'ai envoyé un e-mail à fsbugs avec un commentaire sur les unités de mesure dans F # et une réponse a été fournie dans les 24 heures par le chercheur qui l'a inventé avec une explication détaillée de la raison pour laquelle mon interprétation était fausse et pourquoi elle fonctionne correctement. Anders Hejlsberg ne m'a jamais donné ça ;-). Je cherche tout le temps des solutions Google et je les trouve écrites en C #, VB ou même IronPython, mais, après 3 ans d'utilisation de l'industrie F #, je ne peux rappeler qu'un seul cas où la traduction de la solution en F # n'était pas anodine. En fait, j’ai récemment converti l’échantillon de sérialiseur de données C # de MSDN en F # et il était 5 fois plus court. Enfin, vous avez mentionné la prise en charge de F # dans des outils tels que NUnit Nous utilisons NUnit de F # sans problème depuis quelque temps. Ce sont des outils .NET, pas des outils C #.

Étude de cas : mon client actuel utilise non seulement NUnit pour les tests unitaires, mais il a également créé TickSpec en F # au-dessus de NUnit comme alternative techniquement supérieure à SpecFlow pour BDD. L'auteur a tenu à me montrer que TickSpec est une fraction infime de la taille de SpecFlow et offre davantage de fonctionnalités. De plus, plusieurs développeurs au travail sans aucune expérience préalable en F # (et, je pense, sans aucune expérience en programmation fonctionnelle préalable) l'ont récupérée et ont commencé à l'utiliser dans des projets indépendants, sans problème, précisément parce que F # + TickSpec facilite la résolution de leurs problèmes. problèmes.

FWIW, j’ai offert à mon client un abonnement gratuit à notre journal F # .NET, qui s’est bien déroulé avec la plupart des développeurs qui ont appris F #.

HTH!

Jon Harrop
la source
3
Affirmation sans équivoque: un langage que vous pouvez apprendre rapidement ne vaut pas la peine d'être ajouté à un mix de développement commercial Le but de F # est d’écrire du code fonctionnel, et la plupart des gens ne vont pas apprendre la programmation fonctionnelle aussi rapidement.
David Thornley
8
Exemple de comptoir à plat: LINQ. L'écriture de code fonctionnel n'est absolument pas le but de F #, quelle que soit la définition du mot "fonctionnel". Dans le contexte des développeurs C # existants, ils devraient déjà être à mi-chemin avec System.Func.
Jon Harrop
1
Si F # ne concerne pas principalement la programmation fonctionnelle, alors de quoi s'agit-il vraiment? Comment savez-vous que F # convient mieux que, par exemple, C #?
Robert Harvey
5
@Robert: F # offre une variété de fonctionnalités qui peuvent le rendre beaucoup plus productif que le C #. Les types de variantes et la correspondance de motifs sont extrêmement puissants pour créer et manipuler des arbres, qui apparaissent dans tout, des compilateurs aux graphiques informatiques. L'inférence de type facilite l'écriture de code fortement générique, idéal pour l'algorithmique dense. Les sessions interactives sont idéales pour le code jetable, comme le transfert d'ensembles de données d'un formulaire à un autre ou même pour une analyse sophistiquée. Ces fonctionnalités ne sont qu'incidemment liées à la programmation fonctionnelle et fonctionnent toutes bien dans le code impératif.
Jon Harrop
8

Comme vous le reconnaissez dans votre premier point, vos programmeurs qui ne connaissent pas F # ne peuvent pas travailler sur la partie F # de votre base de code. Cependant, vous n'avez pas besoin de réécrire toute votre base de code en F # pour en tirer des avantages: il vous suffit de réécrire les parties sur lesquelles vous verriez le plus grand avantage. Le fait que F # interagisse très bien avec C # devrait faciliter la découpe de certaines pièces et la création d'assemblages F #.

Si vos ingénieurs travaillaient sur une application classique à 3 niveaux, vous n’insisteriez probablement pas sur le fait qu’ils devaient tous posséder une connaissance approfondie de SQL, HTML, Javascript, CSS, etc. Au lieu de cela, certains spécialistes travailleraient naturellement sur différentes parties de l'application. Par conséquent, je ne pense pas que l'ajout d'une nouvelle langue pour une partie de votre application devrait être un obstacle trop important. De plus, vous pouvez utiliser les normes de codage et autres pratiques pour vous assurer que votre code F # est lisible même par les ingénieurs sans fond F # profond.

kvb
la source
1
@kvb, mon commentaire est un peu hors sujet, mais je voulais juste dire que même s’il est généralement idéal, de nombreuses entreprises n’ont en pratique pas de poste spécialisé comme vous l’avez décrit et exigent, comme dans votre exemple, qu'un seul développeur connaissances (suffisantes) de SQL, HTML, Javascript, CSS, etc. et peut-être aussi des analyses commerciales. J'ai personnellement travaillé sur les deux scénarios ( non déterminés par la taille de l'entreprise) et chacun présente des avantages et des inconvénients et peut être plus ou moins approprié projet par projet, mais la spécialisation est certainement un luxe.
Stephen Swensen
7

L'ajout de F # aux langues que vous utilisez comporte les inconvénients de l'introduction de toute nouvelle technologie. Quels que soient les avantages, si certains membres de votre équipe ne veulent pas ou ne sont pas assez flexibles pour apprendre, ils ne pourront pas travailler sur des projets F #. Néanmoins, si vous laissez les dinosaures de votre équipe vous empêcher d’adopter de nouvelles technologies, votre entreprise est condamnée.

Les seuls pièges que j'ai personnellement vécus sont:

  1. Difficultés lors du débogage. Suivre le déroulement de l'exécution d'un programme basé sur une expression dans un débogueur conçu pour des langages basés sur une instruction peut être délicat.

  2. Intellisense frustrant. La saisie automatique cesse de fonctionner exactement quand vous en avez besoin. Microsoft doit s’efforcer de rendre l’analyseur d’arrière-plan plus tolérant aux pannes.

  3. La syntaxe sensible à l'indentation rend difficile le copier-coller ou le reformatage du code.

  4. Manque de refactoring.

  5. Certaines des extensions VS pratiques pour F # existantes (pliage du code, coloration en profondeur) sont un peu lentes, ce qui rend l'expérience de la saisie un peu frustrante.

À mon avis, aucun de ces problèmes n’est décisif et je peux vivre avec eux pour le moment. Les outils sont plus faciles à améliorer et à corriger que les langues.

Vos craintes qu'il soit difficile d'embaucher de nouveaux programmeurs capables d'écrire en fa # sont assez courantes mais, à mon avis, injustifiées. Si vous deviez rédiger des instructions de codage, déconseilleriez-vous ou interdiriez-vous les fonctionnalités suivantes en C # yield return:, LINQ to object, lambdas, the next async?

Si vous pensez que ces fonctionnalités permettent d'écrire un meilleur code, il n'y a aucune raison de ne pas utiliser F #. Le langage prend en charge ces fonctionnalités de manière lisse et bien pensée, ce que C # ne peut pas vraiment faire en raison de son héritage.

Si votre équipe est suffisamment intelligente pour comprendre les concepts à la base des fonctionnalités que j'ai mentionnées, elle dispose de tout ce dont elle a besoin pour devenir un excellent programmeur en F #. Il en va de même pour les futures recrues: engageriez-vous une personne incapable ou peu disposée à utiliser les fonctionnalités introduites après C # 1.0?

Joh
la source
5

J'ai envisagé cette situation exacte.

Voici ce que je prévois pour mon équipe:

  • Mélangez C # avec F #, cela peut être fait en utilisant C # pour la majorité de la base de code. Lorsqu'un traitement de données important est requis, écrivez les fonctions associées dans F # et placez-les dans une dll ou faites-les référence. Exemple ici

  • Reformulez lentement votre base de code existante de la manière indiquée ci-dessus.

  • Tout le code ne doit pas nécessairement être fonctionnel.

  • Obtenez votre équipe pour apprendre les bases de Haskell, LISP au cours des week - ends .

  • Amenez-les à apprendre le F # en essayant de résoudre les énigmes du projet Euler (qui m’ont beaucoup aidé lors de mon apprentissage du F #). Encore une fois, cela devrait être quelque chose de fait, dites le week-end, ou pendant le temps de travail si vous voulez réserver une journée pour "la formation".

nuit
la source
15
allez-vous payer vos développeurs pour travailler sur ce week-end? Seigneur sait que j'ai passé beaucoup de week-ends et de soirées à apprendre le F #, mais comme passe-temps. Même s’il est vrai que lorsque j’ai engagé un projet Grails, j’ai appris ce cadre en partie pendant les heures de repos, mais c’est tout simplement ma personnalité et j’ai apprécié, mais si quelqu'un m’avait dit de le faire pendant mes heures de repos, pas été heureux.
Stephen Swensen
+1 mais: Haskell et Lisp ont un intérêt purement académique. Je ne pense pas que cela ajouterait de la valeur à un programmeur .NET pour lui permettre d'apprendre ces langues. Je pense (en tant qu'auteur de plusieurs livres F # ;-) que lire un bon livre serait plus productif que d'essayer d'écrire du code F # (comme le projet Euler puzzles) in vacuo. Avec des conseils, ils peuvent être opérationnels en un mois.
Jon Harrop
4

1) L’apprentissage d’un langage fonctionnel augmentera les capacités globales de certains en tant que programmeur, mais cela ne s’applique qu’à ceux qui veulent apprendre et s’améliorer. Tous les programmeurs ne veulent pas s’améliorer ni veulent changer leur environnement de travail (connaissez votre équipe).

2) Je ne peux pas discuter avec cela. Vous devrez payer pour la courbe d'apprentissage de 6 mois de toute nouvelle langue, mais connaître déjà les bibliothèques .net élimine les années supplémentaires nécessaires à l'apprentissage de nouvelles bibliothèques.

3) Le support de la communauté, bien que plus petit que C #, compte sur un bon nombre de développeurs F # actifs hautement qualifiés qui postent sur le Web. N'oubliez pas que la plupart des langues prises en charge sont des bibliothèques et que .NET est un excellent support.

Le gorille de mille livres est ici la gestion des risques. "Je peux être tranchant mais pas tranchant." Je dirais que F # ne saigne pas. Il a été publié avec VS2010 et est directement pris en charge par Microsoft. Saignement est une "version bêta" et un disclaimer de Microsoft disant de ne pas être responsable de quoi que ce soit.

gradbot
la source
Si quelqu'un connaît déjà la plate-forme C # et .Net, l'apprentissage de F # coûte généralement moins d'un mois. (basé sur l'expérience de mes deux collègues.)
4

Sur le plan pratique, la prise en charge d’IntelliSense fait cruellement défaut, au point que les gains de productivité de l’inférence de type sont surpassés par la fonction de saisie semi-automatique moins sophistiquée disponible en C #.

Les messages d'erreur générés par des inférences de type erronées sont également plus longs à corriger pour les débutants (et souvent pour les utilisateurs intermédiaires comme moi-même), tout simplement parce que vous êtes moins enclin à fournir des annotations de type que dans un langage comme C #.

La POO manque également de manière surprenante en fa #; Par exemple, les types / classes imbriqués ne sont pas pris en charge. Vous devez faire attention lorsque vous portez du code, car certaines choses que vous pouvez faire en C # ne peuvent pas être faites en F #, malheureusement.

Dernier point mais non le moindre, la taille et la qualité de la communauté F # sont en quelque sorte décevantes. Une grande partie des informations F # disponibles sur le Web est soit pour les anciennes versions, soit simplement pas très bonne - soit non idiomatique, de mauvaises performances ou totalement incorrecte. Ensuite, il y a des gens qui demandent des sommes énormes pour des lettres d’information qui ne sont en grande partie que des résumés d’informations existants.

J'utilise moi-même le C # pour des projets professionnels et le F # pour mes propres projets. Autant que j'aime F #, malheureusement, il est un peu difficile de prédire comment / quand les choses risquent de se dégrader.

Rei Miyasaka
la source
1
Si £ 39 est "une somme énorme" pour former un développeur, apprendre F # est le moindre de vos soucis, IMHO.
Jon Harrop
Uh oh, l'homme lui-même. Mec, tu es partout, n'est-ce pas? 39 £ est en fait une somme énorme pour le type d'informations qui, de nos jours, sont presque toujours disponibles dans des blogs ou des articles techniques.
Rei Miyasaka
2
Toutes les informations très pertinentes, je ne suis pas sûr de savoir pourquoi les gens votent contre votre message. Même si j'aime bien F #, la question concerne ses côtés négatifs, et les messages les soulignant ne devraient pas être rejetés par ceux qui aiment F #.
Joh
1

Le principal problème est toujours la maintenabilité.

J'adorerais coder dans Scheme, mais le prochain responsable voudrait probablement me traquer et me torturer.

leppie
la source
Que faire si le prochain responsable connaît également Scheme? J'ai lu sur comp.lang.lisp que les programmeurs Lisp sont en réseau afin de pouvoir fournir des remplaçants à leurs employeurs si nécessaire.
Larry Coleman
0

Je dirais que la première chose à faire est de demander aux membres de votre équipe ce qu’ils pensent de l’introduction de F #. S'ils aiment l'idée, tout ira beaucoup mieux si ce n'est pas le cas.

Nemanja Trifunovic
la source