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é]

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.

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.

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!

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.

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?

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".

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.

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.

Le principal problème est toujours la maintenabilité.

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

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.