Pourquoi quelqu'un prendrait la peine d'apprendre des langues hors de la demande. Une étude de cas de la communauté F #



Nous entendons tous parler de films, de jeux, de livres ou de compositions musicales emblématiques qui sont salués avec véhémence par la communauté des sophisticados, des professionnels et des critiques, mais qui ne semblent jamais attirer un succès commercial tangible ou l'attention d'un public plus large. De telles situations me laissent profondément frustré.

En matière de développement, les bonnes technologies ne sont parfois jamais mises à l'honneur. Prenez F # par exemple. Tout ce que je sais à ce sujet, c'est que c'est un langage super cool, mais totalement impopulaire, ce qui rend difficile pour les développeurs - une fois qu'ils le connaissent - de revenir aux langues auxquelles ils sont habitués.

J'ai essayé de découvrir quelle est l'histoire derrière cela. En fait, qui sont les personnes qui l'utilisent et pourquoi le font-elles si la langue est hors de demande dans les affaires? Pour trouver des réponses, j'ai rejoint la communauté russophone F # sur Telegram - notre table ronde pour la discussion.

Comment avez-vous commencé à apprendre le F #?


Ayrat Hudaygulov ( Szer ): J'ai à l'origine migré ici depuis C #. Nous avions une fois un travail qui avait à voir avec Akka.NET - un port Scala d'Akka. Le port lui-même était bien, mais il manquait d'exemples dans de rares cas dans le manuel de l'utilisateur, bien qu'ils soient toujours fournis dans le manuel Scala. En lisant ce manuel, je me demandais sans cesse - pourquoi faut-il seulement quelques lignes pour l'écrire en Scala alors que j'ai tant de mal à faire de même en C #?

J'ai vu la solution en passant à F #. Depuis, je n'ai plus eu de doutes.

Roman Liman ( kagetoki ): Il s'est avéré que c'était un outil puissant pour résoudre les problèmes quotidiens réels auxquels tout développeur peut être confronté. Les obstacles qui étaient auparavant considérés comme la norme inévitable de la POO dans le monde de C # et de Java ne sont en fait pas inévitables et peuvent être facilement évités plutôt que surmontés.

Phil Ranzhin ( fillpackart ): J'ai lu une fois une longue interview de Vagif Abilov sur Habr. À l'époque, je ne pouvais tout simplement pas me familiariser avec le paradigme de la programmation fonctionnelle, donc toute information connexe me ferait vraiment chier. Cette interview n'a pas fait exception.

Vagif Abilov ( VagifAbilov ): Voici le lien vers l'article en question . Je l'ai fait peu de temps après avoir prononcé un discours lors de la conférence DotNext à Moscou. Pour faire court, j'ai commencé à apprendre le F # comme une tentative de rendre mon code plus concis (moins de code équivaut à moins de mal) et d'utiliser des structures de données persistantes. Bien sûr, rien n'empêche un développeur C # ou Java de déclarer leurs structures de données persistantes, mais la possibilité de muter les structures de données est une caractéristique fondamentale des langages OOP, et qui leur sera toujours inhérente. La programmation fonctionnelle vous épargne l'effort généralement consacré à la protection des données contre les mutations inappropriées dans un environnement multi-thread - les données prendront soin d'elles-mêmes, car elles sont immuables.

Phil Ranzhin : Vagif n'arrêtait pas de dire qu'après le C # et Java strictement formels, F # semblait quelque chose de beaucoup plus convivial pour le développement. Je ne savais pas alors qui était Vagif, mais je pensais naturellement que le gars n'avait pas la moindre idée. C # n'est pas trop formel, C # est exactement ce qu'il devrait être. C'est puissant et beau. J'ai décidé d'écrire un article sur la façon dont la programmation fonctionnelle absurde était après tout. J'ai pris un problème simple et j'ai commencé à l'implémenter en C # et en F # afin de prouver mon point. Mais alors que j'y travaillais, j'ai tellement aimé F # que j'ai abandonné l'article. Au lieu de cela, j'ai commencé à approfondir la technologie.

Roman Liman : Une grande partie des éléments vérifiés par C # au moment de l'exécution sont désormais pris en charge au moment de la compilation, ce qui donne l'impression de jouer avec la saisie statique pour la première fois - une véritable révélation.

Sans l'exagérer, où vous avez besoin de sept lignes de code en F #, vous aurez besoin de 200-300 lignes pour écrire le code équivalent en C # (pour ne rendre compte que du code utile). Le compilateur fera toute la génération de passe-partout pour vous, comme l'égalité structurelle.

Phil Ranzhin : Je n'ai jamais réellement débogué mon code F # car dans mon code F #, tous les bugs sont résolus lors de la compilation. Je ne plaisante pas.

Est-ce difficile d'apprendre F #?


Roman Liman : Est-ce difficile de l'apprendre? Je dirais, pas dur du tout. Vous pourriez avoir du mal à vous y attaquer au début si vous n'avez jamais abordé le paradigme fonctionnel et les types immuables auparavant. Mais ce problème est lié à la commutation entre les paradigmes, pas aux langues.

La syntaxe n'est pas évidente au début, alors apprivoisez votre arrogance et lisez ce langage, n'espérez pas vous en sortir avec votre connaissance de C #.

Ayrat Hudaygulov : F # prend en charge tout ce que C # fait, à l'exception de goto (car le langage est entièrement basé sur l'expression, il semblerait étrange de faire un saut impératif dans une expression calculable) et le mot-clé protégé (c'était ainsi par conception, comme apparemment l'ajouter serait une évidence). Le reste de tout ce que nous aimons dans la POO - les classes abstraites, les interfaces, les propriétés implémentées automatiquement, l'utilisation, la tentative de capture, etc. - tout est là bien sûr. Les amateurs de comptage d'octets seront également satisfaits, que ce soit avec les paramètres ref / out, mutabilité, étendues, non gérés, pointeurs, stackalloc.

Toutes les fonctionnalités C # sont ajoutées avec un retard de quelques années par rapport à F # (génériques, tâche asynchrone / attente +, LINQ, correspondance de modèle et bien d'autres). De plus, de nombreuses fonctionnalités n'arriveront probablement jamais au langage (types de somme comme unions discriminées, curry de fonction native). Le C # 8.0 à venir devrait être amélioré avec des enregistrements et une correspondance récursive de motifs. La question est, pourquoi attendre?

Une autre question est: pourquoi apprendre une nouvelle langue pour l'utiliser à l'ancienne? Pour vraiment profiter des avantages de F # qui manquent en C #, vous devrez comprendre l'autre côté de la Force. Personne n'a dit que c'était facile.

John Doe : En tant que développeur C #, je suis reconnaissant aux créateurs de F # pour les génériques et la programmation asynchrone à visage humain en C #. Pour ceux qui ne le savaient pas, ces méga-fonctionnalités sont venues en C # grâce à F #.

Vagif Abilov : L'auteur du populaire développement pragmatique recommande aux développeurs d'apprendre un nouveau langage de programmation chaque année. Je ne peux pas dire que j'adhère religieusement à ce conseil, mais je suppose que les auteurs voulaient vraiment dire que les développeurs doivent toujours être prêts à réviser les principes sur lesquels ils écrivent leur code.

Beaucoup de gens vénèrent les langages de programmation comme leurs croyances. Certains traiteront un passage de Java à Clojure comme une conversion du christianisme à l'islam. Pourquoi diable cela devrait-il être si important? L'apprentissage de nouveaux langages de programmation nous donnera souvent l'occasion de reconsidérer nos anciennes façons de travailler avec les langages que nous connaissons déjà. Se familiariser avec F # incite les gens à écrire du code C # d'une nouvelle manière.

Roman Melnikov ( neftedollar ): La partie OOP de F # est plus appropriée (bien qu'elle soit complètement compatible avec la version C # d'OOP), car elle vous encourage à programmer en utilisant des interfaces abstraites au lieu de classes explicites.

Que pensez-vous des concepteurs de cette langue?


Nikolay Matyushin : J'ai déjà aidé à introduire la prise en charge des fournisseurs de types de données dans .NET Core. Ils ne fonctionneraient pas pendant un bon moment, donc, après avoir enrôlé un autre membre de notre communauté russophone, je me suis décidé à découvrir ce qui n'allait pas exactement. Après quelques recherches, nous avons découvert que .NET Core n'avait pas de fonction pour enregistrer l'objet d'assemblage dans un fichier - cette fonction était nécessaire aux fournisseurs de types.

Nous avons passé une semaine ou deux à développer un prototype qui serait capable de le faire. Nous avons mis en place un hack désordonné, mais cela a fonctionné (au moins dans une certaine mesure). Pendant tout ce temps, nous avons continué à publier sur Github's Issues jusqu'à ce que Don Syme intervienne, dise que c'était «quelques heures de travail» et fixait les fournisseurs de types.

Vagif Abilov : Le concepteur de langage Don Syme est accessible et ouvert d'esprit. J'espère qu'il s'aventurera un jour jusqu'à une conférence russe pour rencontrer des développeurs russes en personne.

Roman Liman : Syme est un génie. C'est incroyable qu'il soit à peu près tout seul derrière ce beau design.

Pavel Smirnov : Il est mon modèle dans le monde de la programmation.

Ayrat Hudaygulov : Soit dit en passant, Don Syme a été le seul à introduire des génériques dans .NET, sinon nous continuerions à tout diffuser en dur depuis et vers l'objet en C #, comme c'était (et partiellement) le cas en Java. Syme fait grandir le langage avec un regard en arrière sur C #, vers la compatibilité avec ses nouvelles fonctionnalités, ce qui est probablement la bonne chose à faire du point de vue stratégique. Pourtant, cela signifie que l'arrière-goût de mauvaises décisions en C # peut également s'infiltrer dans F #. Il s'oppose également à l'introduction de fonctionnalités de nerdy FP (bonjour Scala!) Et à la surcompression du langage, car tout cela peut effrayer les autres et alourdir la bibliothèque standard (bonjour C ++!).

Je pense que Syme est un héros. Je m'associe à lui sur sa vision de la langue en tant que paradigme, cependant, j'ajouterais probablement plus de fonctionnalités à la langue.

Pourquoi la langue n'est-elle pas très populaire?


Roman Liman : Je dirais que la langue n'est pas populaire car la PF est généralement moins populaire que la POO. En outre, il y a la courbe d'apprentissage abrupte. Le reste est une situation de Catch 22. Peu de projets sont codés en F # car le marché manque de programmeurs F #, tandis que les programmeurs n'apprennent pas ce langage car le marché manque de projet pertinent.

Phil Ranzhin : Je ne connais personne qui pratiquerait la programmation fonctionnelle et en même temps préférerait le modèle orienté objet. En ce sens, F # est particulièrement malchanceux, car il ne fonctionne bien que pour ceux qui croient en l'union symbiotique des deux paradigmes.

Pavel Smirnov : Beaucoup le considéraient comme un enfant mort-né en raison de la politique de Microsoft de faire de F # une plate-forme pour jouer avec des fonctionnalités destinées à C #. Cependant, le langage visait à l'origine la science des données plutôt que le développement industriel.

Roman Melnikov : ReSharper. C'est un élément essentiel pour C #, et de nombreuses personnes y ont déjà investi. L'écriture de code C # sans ReSharper est un travail difficile, compte tenu de la quantité de configuration manuelle, par exemple pour mettre en évidence les allocations. Ainsi, ReSharper soulage beaucoup de douleur dans le cul pour les développeurs C #. F # n'inflige pas cette douleur en premier lieu, mais ceux qui utilisent ReSharper ne peuvent pas vraiment apprécier toute la beauté d'un langage qui ne dépend pas de l'outillage.

Vagif Abilov : À mon avis, la raison pour laquelle il est en retard sur le succès de Scala réside dans la position dominante de Microsoft qui dicte toujours les priorités sur la plate-forme Windows. Malgré le fait que F # ait été développé dans Microsoft Research, la société l'a toujours positionné comme un langage pour les passionnés. Microsoft a ses propres mesures pour la faisabilité économique de développer une technologie particulière basée sur les performances de vente actuelles, donc, selon ces mesures, les projets comme SharePoint semblent beaucoup plus sexy que F #. Cependant, de petits coups sont tombés de grands chênes.

Phil Ranzhin : Je suis convaincu que cela va décoller. La puissance de .NET combinée à la syntaxe la plus moderne et au concept idiomatique sans précédent ne peuvent que décoller.

Roman Melnikov : L'avenir s'annonce incroyablement prometteur. F # ouvre la voie à l'analyse des données, grâce aux fournisseurs de types par exemple. Il existe également des compilateurs js et la bibliothèque magic elmish (qui est en fait Elm pour .NET).

Miguel de Icaza est un fervent partisan de F #, donc Xamarin a toujours eu le même niveau de support F # que C #. Il y a aussi un compilateur dans ErlangCore, qui est également assez génial. F # peut être utilisé pour coder à la fois le backend et le frontend. SAFE-Stack est époustouflant, avec des appels API typés, des wrappers de socket Web sympas (Elmish. Bridge) et des tonnes d'autres choses.

Vagif Abilov : Je suis heureux d'apprendre que F # est utilisé dans la pratique. Je travaille sur un projet d'une société de radiodiffusion norvégienne selon lequel le système télécharge des fichiers multimédias de télévision et de radio dans le cloud pour les rendre disponibles pour la lecture à partir d'ordinateurs et d'appareils mobiles. Le système est écrit en F # et exploite Akka.NET. Ce n'est pas le seul projet de notre organisation en F #, et ce qui est encore plus prometteur, c'est que le nombre de ces projets augmente tout comme le nombre de développeurs prêts à passer à ce langage.

À quoi sert F #?


Phil Ranzhin : F # est parfait pour le développement de l'IA. Ce langage est littéralement conçu pour séparer mon esprit de tout tracas et pour se concentrer sur les choses importantes. Lorsque vous travaillez sur l'IA, votre tâche consiste à adapter votre état d'esprit au comportement de la machine. Dans de tels cas, votre code est votre langage intermédiaire qui est incapable de décrire des idées trop compliquées. Mais F # est capable d'être suffisamment abstrait pour que vous et votre machine puissiez écrire l'histoire.

Vagif Abilov : Il peut être utilisé pour résoudre tous les problèmes et est particulièrement bon pour la conception pilotée par domaine. Dans mon interview de l'année dernière sur Habr, j'étais stupide de dire que les langages fonctionnels étaient applicables aux algorithmes et au backend dans une plus large mesure qu'ils ne l'étaient pour la programmation des interfaces utilisateur et des pages Web.

Quelqu'un a ensuite mentionné dans la section des commentaires qu'il y avait un langage fonctionnel Elm qui a été conçu spécifiquement pour la programmation des pages Web. La personne qui a laissé le commentaire avait absolument raison. Depuis lors, j'ai commencé à utiliser Fable qui permet d'écrire des applications Web en F # et de les compiler en JavaScript. L'effet a été remarquable: la combinaison de F # plus Fable (et de la bibliothèque Fable-Elmish) ouvre l'accès à la programmation Web à des développeurs comme CSS comme moi.

Pavel Smirnov : Développement piloté par les données - il s'agit d'un langage FP concis avec le support de type fournit. Son modèle d'acteur MailboxProcessor, dans le cadre de la bibliothèque standard, est un régal!

Roman Melnikov : Il résout parfaitement les problèmes Web et s'intègre bien avec les composants réactifs. Il résout les problèmes d'analyse de données et d'apprentissage automatique (fslab.org), les problèmes ETL, les problèmes de conception de la logique métier - son système de types permet de coder de manière à éviter les états incorrects.
Il fonctionne à merveille pour l'analyse (Fparsec). C'est génial pour concevoir et interpréter vos propres langues. Prenez simplement TypeScript - il a été écrit à l'origine en F #. Il peut être utilisé pour écrire du code GPU.
J'utilise moi-même F # au lieu de bash et Python pour coder des scripts fsx pour mon ordinateur.

Il est vrai que vous ne pouvez pas l'utiliser pour programmer des microcontrôleurs. Mais je suppose que beaucoup de gens peuvent s'en passer.

Où obtenir des informations


Livres




Internet



Télégramme


fsharp_news
fsharp_chat

Une brève description de la communauté


Roman Liman : La communauté est fabuleuse: elle est motivée par le désir de coder en F # commercialement, donc les débutants sont les bienvenus et offrent un soutien formidable dans le but de développer la communauté et d'augmenter les chances des membres de trouver un emploi.

Phil Ranzhin : Ces dangereux adeptes de culte! Mais ils ont raison.

Pavel Smirnov : La communauté russophone F # est un endroit agréable. Ce que j'aime le plus, c'est qu'ils se soucient vraiment de leur langue préférée, tout comme les gens dans d'autres écosystèmes plus connus.

Nikolay Matyushin : C'est probablement parce que la langue n'est pas très populaire, donc les personnes toxiques ne restent pas.

Roman Melnikov : La communauté a sa part de drames qui n'affectent pas la langue elle-même mais rendent la vie plus excitante.

Source: https://habr.com/ru/post/fr432048/


All Articles