À qui dois-je m'adresser à propos de F #, si ce n'est une personne qui a dédié un site Web détaillé à cette langue?
Scott Vlashin a créé la ressource
"F # pour le plaisir et le profit" , familière à de nombreux résidents de Habra: de Habré, ils ont traduit à la fois la
série d'articles "Functional Thinking" et l'
article "Railway-Oriented Programming".
Et en novembre, il interviendra lors de notre conférence DotNext à Moscou avec le
rapport «Le pouvoir de la composition». Et en prévision de ce discours, nous lui avons posé des questions sur F # et la programmation généralement fonctionnelle.
- Reprenons depuis le début: qu'avez-vous fait avant la programmation fonctionnelle, comment en êtes-vous arrivé à F # et comment avez-vous créé le site?- Je suis un homme vénérable, et quand j'étais à l'université, il n'y avait pas encore de programme informatique séparé. J'ai reçu une éducation mathématique, mais je ne voulais pas faire de mathématiques, donc après l'université, j'ai travaillé pendant environ 10 ans sur divers emplois, dont celui de charpentier.
Un beau jour à la fin des années 1980, mon père a acheté un ordinateur, CP / M Kaypro, avec une petite quantité de mémoire et des disquettes de 5,25 pouces pour son travail. C'était avant que Windows n'apparaisse, donc DOS s'y tenait. C'est là-dessus que j'ai commencé la programmation. J'étais engagé dans des bases de données, d'abord pour mon père, il en avait besoin pour son travail. Et puis j'ai commencé à le faire professionnellement.
Ma première langue était Turbo Pascal, et en 1989 ou 1990, j'ai rencontré Smalltalk, et j'ai beaucoup aimé, c'est toujours une de mes langues préférées. Un travail en a remplacé un autre et au final, comme la plupart des programmeurs, j'ai trouvé un emploi dans une grande entreprise pour écrire des applications métier ennuyeuses (je les appelle des «BLOBs»: des applications métier ennuyeuses). Et pendant très longtemps, il faisait exactement cela.
Pendant un certain temps, j'ai écrit en Python, environ 10 ans - en C #. Et en 2011, c'est-à-dire il n'y a pas si longtemps, j'ai décidé que j'étais fatigué de mon travail et ce serait bien d'essayer quelque chose de nouveau; donc je voulais faire de la programmation fonctionnelle. Il s'est avéré que mon Visual Studio avait déjà un langage fonctionnel, j'ai donc essayé de comprendre F #. Et au début, cela semblait très étrange, je ne comprenais rien, c'était tellement différent de tout ce avec quoi je travaillais auparavant.
Il y avait plusieurs bons blogs sur F #, mais il y en avait très peu, et il n'y avait pas assez de documentation non plus. En conséquence, mes amis m'ont donné d'excellents conseils: si vous voulez étudier quelque chose correctement, essayez de commencer à en enseigner aux autres, car cela vous fait très bien comprendre le sujet. De plus, on m'a conseillé de créer un blog, cela me permet de me démarquer des autres programmeurs.
En général, en 2012, j'ai commencé le blog «F # pour le plaisir et le profit» et j'ai commencé à publier des articles à chaque fois que j'apprenais quelque chose de nouveau sur F #. Maintenant, il y a plusieurs centaines de pages et il a gagné en popularité. Au début c'était juste un hobby, j'y ai travaillé pendant mon temps libre. Et il y a environ 3 ou 4 ans, j'ai décidé de quitter mon emploi et de devenir consultant indépendant. L'année dernière, j'ai écrit un livre, qui s'est également avéré très populaire. Et donc ma connaissance de F # a eu lieu.
- Comment travaillez-vous en freelance avec F #, ou pas seulement?- Fondamentalement, F #, bien que d'une manière générale, ce qu'ils paieront - c'est pourquoi je conseille
* rires * . Si j'ai besoin d'argent, mais quelqu'un a du travail sur C #, et ça a l'air intéressant, je le prends. Et l'année dernière, j'ai travaillé avec Python pendant trois mois. Ce qui m'importe ce n'est pas la langue, mais quel problème particulier doit être résolu. J'aime étudier et lorsque vous êtes engagé pour résoudre un problème, vous devez devenir, sinon un expert, puis au moins trier un nouveau domaine.
J'ai donc dû étudier l'économie immobilière et les risques d'assurance. Je crois qu'un bon code ne peut être écrit que si vous avez une bonne compréhension du sujet que vous faites et pas seulement écrire ce que les autres vous disent. Pour moi, c'est le plus intéressant - pas une langue, mais un problème.
- En Russie, bien que certains développeurs s'intéressent au F #, les affaires avec ce langage sont difficiles: il est plus difficile de trouver ou de remplacer un développeur qu'avec C #. Et ces entreprises avec lesquelles vous travaillez, comment sont-elles résolues en F #?- Il existe deux situations les plus courantes. La première option est lorsque l'entreprise utilise déjà F #, ils ont généralement une sorte de projet pilote. Ils m'appellent et me demandent de les aider à lancer ce projet et à leur enseigner la langue. Habituellement, ils sont prêts à consacrer environ six mois à un tel projet pour savoir s'ils veulent aller plus loin.
De plus, je suis engagé dans l'enseignement du design axé sur le domaine, et ici F # n'est pas à l'honneur, mais je l'utilise comme langage. Je montre aux programmeurs habitués à C # combien de temps le même code en F # peut être plus court qu'en C #. Autrement dit, je fais la promotion de la langue tranquillement. Cela vous aide à ne pas avoir à passer entièrement à F #, vous pouvez écrire un modèle de domaine en F # et tout le reste en C #.
- Vous dites que C # et F # peuvent être utilisés ensemble. Mais en C #, Entity Framework, NHibernate ou quelque chose de similaire est le plus souvent utilisé. Et parmi les développeurs sur F #, c'est beaucoup moins populaire. Comment mélanger ces langues en tenant compte de la différence d'approche?- L'une des entreprises avec lesquelles j'ai travaillé utilise Entity Framework. Ils ont essayé de basculer vers l'architecture des ports et adaptateurs, c'est-à-dire de supprimer toutes les opérations d'entrée / sortie du cœur de l'architecture. Pour cela, Entity Framework est assez mauvais. Dans de telles situations, il est beaucoup plus pratique d'utiliser quelque chose comme Dapper, qui vous permet de ne pas traiter avec SQL au milieu de votre code. Entre autres choses, cela facilite les tests.
Qu'ils n'utilisent pas de programmation fonctionnelle, mais la situation les pousse toujours à avoir un cœur propre du programme et à garder la base de données quelque part à la périphérie. Si la réflexion est passée à ce format, il s'agit d'une étape importante vers l'abandon de l'entité. Dans une telle entreprise, je n'aurais en fait rien changé. Vous ne pouvez pas forcer les gens à changer, ils doivent eux-mêmes vouloir changer. Je n'essaie pas de me vendre et d'imposer à quelqu'un la meilleure façon, selon moi. Habituellement, les gens veulent déjà changer, et je les aide simplement à y parvenir. Comprenez-vous ce que je veux dire?
- Autrement dit, vos clients sont des entreprises qui elles-mêmes évoluent déjà vers une approche plus fonctionnelle.- Même s'ils travaillent avec C #, ils basculent vers un C # plus fonctionnel, commencent à utiliser LINQ, des structures de données immuables, c'est-à-dire, vont en général dans cette direction. Par conséquent, pour eux, passer à F # n'est plus un grand saut.
Les professions de développeur et de charpentier sont-elles similaires
- Vous avez un fil intéressant sur Twitter comparant le travail d'un programmeur et d'un charpentier. Je voudrais poser des questions sur le "fonctionnalisme", à partir de ce fil. Mais pouvez-vous en dire l'essence à nos lecteurs?- Les développeurs aiment se comparer avec les ingénieurs et le développement de logiciels - avec la construction de bâtiments ou de ponts. Et il y a beaucoup de débats pour savoir si la programmation est vraiment proche de ces activités, ou si elles sont fondamentalement différentes. Par exemple, nous avons des exigences pour que le projet change tous les jours - lorsque vous construisez un pont, tout est probablement complètement faux? Ou est-ce vraiment le cas là aussi?
Mais je pense que dans ce différend, il n'y a pas de réponse correcte unique. Je n'ai jamais été ingénieur, mais j'étais charpentier. Et je peux dire que les menuisiers ont beaucoup de travaux différents, de formats très différents, et chacun a besoin de sa propre approche.
Par exemple, dans l'un des travaux, j'ai fait des armoires de cuisine. En Amérique, ils sont tous très standardisés, tous de la même taille, adaptés les uns aux autres, et le travail se fait avec des outils électriques. Il est nécessaire de fournir une certaine qualité, mais en Amérique, l'ancienne cuisine est généralement jetée lorsque la maison change de propriétaire, c'est-à-dire qu'elle ne servira pas très longtemps. Donc, dans ce travail, tout est lié à la vitesse et aux économies de coûts.
Ensuite, j'ai eu une autre tâche, où je devais remplacer une grande poutre en chêne de 6 pouces au milieu de la pièce du bâtiment, qui avait 400-500 ans. Ici, tout était à l'opposé: tout était courbé, sans angles droits, et pour le remplacer, il fallait monter manuellement un nouveau morceau de bois pour qu'il ait exactement la même forme que l'ancien. Cela exigeait beaucoup de précision.
Enfin, il y a eu le troisième travail dans lequel j'ai fait le décor de la scène. Ils étaient faits de contreplaqué et de bois très mince pour les accessoires.
Mon idée est que chaque œuvre nécessite sa propre approche. Dans le cas des armoires de cuisine, la précision, l'utilisation d'outils électriques et des résultats reproductibles sont nécessaires. Dans une vieille maison en bois, vous travaillez avec un système hérité, il est important de faire attention, de ne pas se précipiter, il ne faut pas la vitesse, mais la justesse du résultat. Enfin, dans le cas des décorations, vous créez délibérément une structure fragile qui n'a pas besoin d'être solide, vous devez souvent la couper et la remonter en quelques minutes, de telles structures ne durent pas éternellement.
Quand ils disent que la programmation est similaire à l'ingénierie, cela n'est vrai que pour certains types de programmation. Par exemple, si vous écrivez un logiciel qui contrôle un avion, vous devez être très prudent et atteindre une très grande précision. Une chose complètement différente est un script d'une ligne pour rechercher des fichiers, cela ressemble plus à la création de décors. Il est inutile de passer 20 heures à prouver que ce script fonctionne et à écrire 1000 tests unitaires pour cela. Tout travail ne devrait pas prendre plus de 5 minutes. Et lorsque vous travaillez avec un système hérité, vous devez adapter votre code au code existant autant que possible, une refactorisation importante n'est pas souhaitable ici.
Autrement dit, dans chaque cas, le contexte est important. Parfois, vous devez planifier beaucoup, penser beaucoup à un projet, écrire beaucoup de tests. Dans d'autres cas, il suffit de fouetter quelque chose. Beaucoup de gens manquent de flexibilité à cet égard, ils pensent que si vous n'utilisez pas de tests unitaires ou n'utilisez pas de langage de programmation, vous n'êtes pas un professionnel. En fait, l'idée que tout dépend du contexte est assez évidente. Étonnamment, avec quelle obstination certains programmeurs insistent sur leurs idées, et si vous vous éloignez au moins d'une manière ou d'une autre de leurs idéaux, vous êtes immédiatement envoyé sur la liste noire. À mon avis, c'est stupide.
- Vous dites que pour un observateur extérieur, l'activité semble uniforme, mais quand vous la voyez de l'intérieur, des cas complètement différents sont révélés. Et je veux demander: est-ce la même chose avec la programmation fonctionnelle? Ceux qui regardent de l'extérieur ont un stéréotype commun, mais en fait il y a de gigantesques différences?- C'est vrai. De l'extérieur, il peut sembler que tous les «fonctionnaires» pensent de la même façon, mais il existe de nombreux groupes différents qui se disputent: les partisans de Haskell, F #, Clojure, Elm. Même à l'intérieur de F #, il y a un fort désaccord quant à la direction dans laquelle ce langage devrait évoluer - si vous essayez d'imiter Haskell ou si la facilité d'utilisation est une priorité. Vous avez donc raison, à l'intérieur de ce champ est beaucoup plus diversifié que les observateurs extérieurs ne l'imaginent habituellement.
- Pour les différences dans le travail d'un charpentier, vous avez donné des exemples très clairs. Pouvez-vous également illustrer les différences de programmation fonctionnelle avec des exemples spécifiques?- Il y a une école de programmation fonctionnelle, qui croit qu'il faut essayer de tout prouver, et que tout soit mathématiquement parfait. Cette école utilise beaucoup de jargon mathématique, par exemple, les «monoides» ou les «monades». Ce sont principalement des utilisateurs de Haskell, et l'environnement universitaire est très influent.
Et il y a des gens qui sont plus importants pour obtenir des résultats. Ils s'intéressent moins aux mathématiques qu'à l'immuabilité et au retrait des E / S vers la périphérie. Le meilleur exemple de cette approche est la communauté Elm. Ils sont principalement impliqués dans la création d'applications Web. Contrairement au premier groupe, ici, ils n'utilisent pas consciemment le jargon mathématique et refusent consciemment la partie de la fonctionnalité qui se trouve dans Haskell et que les utilisateurs de Haskell considèrent comme vitale.
De plus, il existe un différend entre les partisans du typage fort et du typage dynamique. De l'avis du profane, la programmation fonctionnelle est quelque chose comme Haskell ou F #, mais à côté d'eux, il existe des langages comme Clojure qui ont un typage dynamique et une approche complètement différente pour résoudre les problèmes. Si vous rassemblez toute cette compagnie hétéroclite dans une pièce, ils peuvent se battre. Je pense que toutes les approches ont leur propre raison, et quand je travaille pour quelqu'un, je ne leur dis pas que leur approche est mauvaise.
- Beaucoup ont peur de la «nature académique» mentionnée («F # est enraciné dans ML, qui est pour des preuves scientifiques rigoureuses, mais je résous de vrais problèmes ici»). Mais il s'avère que les gens ont peur en vain?- En général, il me semble étrange que tant de gens soient habitués à considérer l'académicité comme quelque chose de négatif. Eh bien, c'est, comment, certains le considèrent négatif, d'autres - positif.
Le fait est que bon nombre des technologies que nous utilisons maintenant dans la programmation sont apparues dans le milieu universitaire, par exemple, la collecte des ordures ou les types. Il n'y a donc rien de mal avec les méthodes académiques elles-mêmes. Une autre question est que leur insistance excessive peut être nuisible, car les scientifiques et les programmeurs ont des objectifs différents.
Bien que les langages fonctionnels aient des racines académiques, il me semble la bonne décision consciente de cacher cette logique dans des langages tels que F # et Elm. Par conséquent, F # n'est pas utilisé pour prouver des théorèmes, mais pour résoudre de vrais problèmes, c'est un langage très pragmatique. Et les universités sont désormais passées à des langues encore plus complexes, comme le coq, le F * et similaires. Ils sont beaucoup plus académiques et sont utilisés pour prouver des théorèmes.
Comme je l'ai dit, les scientifiques et les programmeurs font des choses différentes. Les programmeurs passent la plupart de leur temps à lire et à écrire des fichiers, à travailler avec des bases de données, à afficher des données à l'écran, à vérifier les données entrées, à les convertir, etc. Mais les scientifiques ne sont pas intéressés par de telles choses. Mais le fait est que des choses qui étaient purement académiques il y a 40 ans ne le sont peut-être plus aujourd'hui.
- Comme vous l'avez dit vous-même à propos du travail d'un charpentier, différentes approches sont bonnes dans différents contextes, il n'y a pas d'approches universelles. Et en particulier, F # est également le mieux adapté à certaines tâches. Quelles sont ces tâches?- Oui, ce n'est certainement pas un langage universel, je ne recommanderais certainement pas de l'utiliser du tout pour tout le monde, ce serait stupide. Mais il me semble que F # est un excellent remplacement pour C # - à l'exception des tâches nécessitant des performances très élevées. La programmation en F # est basée sur une approche complètement différente: immunité, égalité structurelle, dépendances explicites, F # n'a pas de valeurs nulles, etc. Et il me semble que cette approche est beaucoup plus utile pour résoudre les problèmes de programmation quotidiens.
Par conséquent, si une personne utilise C #, elle devrait certainement poser des questions sur F #, ce langage aidera à améliorer le code. Quant aux autres domaines d'application, il me semble que F # serait bien adapté à de nombreuses tâches pour lesquelles Python est désormais utilisé. F # et Python sont très similaires, et il me semble que F # a un grand potentiel pour le traitement des données. Pour le moment, il y a encore du travail à faire dans ce domaine, mais peut-être que dans quelques années, les gens utiliseront F # pour diverses choses liées au Big Data et à la science des données, pour lesquelles Python est maintenant utilisé.
Enfin, F # est très pratique pour travailler avec JavaScript. En général, personne ne veut travailler directement avec JavaScript, il existe donc de nombreux langages qui se compilent en JS: par exemple, ReasonML (qui fonctionne sur OCaml) et Fable (qui fonctionne sur F #). Personnellement, je préfère travailler avec l'une de ces options plutôt qu'avec JavaScript, donc lorsque je travaille sur le frontend, je choisirais quelque chose comme Fable. Ce sont donc les trois principaux domaines dans lesquels F # montre son meilleur côté.
- Comme vous l'avez noté dans votre rapport «F # pour les développeurs C #», l'essentiel dans le langage n'est pas la syntaxe, mais la philosophie. Mais là réside la difficulté pour ceux qui veulent comprendre rapidement "si cette langue me convient". Vous pouvez déjà comprendre si vous aimez la syntaxe par une introduction rapide. Mais combien de temps faut-il pour comprendre la philosophie du langage?- Une personne qui écrit en C # peut rapidement comprendre un langage comme Java ou Go, car la plupart de ces langages standard ont environ un modèle impératif. Passer d'elles à F # demande certainement beaucoup d'efforts, et cela arrête certaines personnes. D'après mon expérience, F # est beaucoup plus facile à apprendre si pendant un certain temps vous oubliez tout ce que vous savez sur la POO. Sinon, vous commencez à transférer toutes sortes de choses du C # au F #.
Quant au temps, quelque part en deux semaines de formation, il est déjà possible de commencer à écrire du code de travail, et il faudra plusieurs mois pour s'habituer plus ou moins à la langue. Enfin, pour un bon niveau de propriété, vous avez besoin de plus de temps, de 6 mois, peut-être plus - c'est si nous parlons de trier toutes les bibliothèques, idiomes et autres.
Mais honnêtement, le passage à F # n'est pas plus difficile que le passage à Entity ou WPF. Ils nécessitent également beaucoup de temps. Ne sous-estimez pas les efforts nécessaires, mais parfois ils disent que cette transition prend des années. Je le répète: pour commencer à écrire du code, il faut plusieurs semaines pour se mettre à l'aise - plusieurs mois. Je le dis à la fois de ma propre expérience et de celle des autres personnes avec qui j'ai parlé.
Dois-je connaître C # avant F #
- Il est clair que la plupart des utilisateurs de F # venaient de C #. Y en a-t-il beaucoup qui viennent en F # sans expérience C #?- Il n'y a pas beaucoup de ces personnes, et c'est assez difficile pour elles, car toutes les bibliothèques ont de la documentation pour C #, donc les gens de partout rencontrent des exemples de C #. Mais il y a toujours de telles personnes, et en plus, le F # est enseigné dans plusieurs universités.Il y a ceux qui essaient d'apprendre le F # après Python. Le problème est que F # est très dépendant de .NET, et .NET est lié à C #. La même situation avec Visual Basic, il y a aussi tous les exemples en C #. Espérons qu'au cours des prochaines années, cette situation pourra changer et rendre la langue plus facile à apprendre, c'est maintenant l'un des problèmes importants.— C#, F#, , F# . ? LINQ , , , ?— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .
— C# , F# ?— . , . , , . , - , Python JavaScript, .
, . JavaScript , F# . , . F# — , , C#, . F# .
— F# — «F# for fun and profit»? C#?— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.
Fun and profit
— «F# » («F# for fun and profit») - , «». , -, ?— . . , F# , , . , , F#, , . F# .
- , — . , - Java . , , , . , , F# C# .
— «»: , , , .— , . , , , . .
StackOverflow , , F# , . , , , , C#. , - , , 10 . .
, , F#, F#. F#, , . , . , F# .
— , F# . ? , , F# . F# ?— , F# . , . - , . , , , . , . F# null; , ; . F# .
, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .
- . , , . , , , , , . Google Amazon — .
— , F# , — , , . ?— , . , , C# , , C#. , C#, null, , - . F# . , , , .
- - , , , . C# F#, , , . , , . , , F#, .
— , Microsoft F# ( C# ). ?— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .
, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .
— Haskell. F# — .NET-, ?— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .
Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .
— . F#, , : , , ?— , F# . , , , . , . F# , , C#. , Haskell, - , .
, , , .
F# , , . , -, .
, - , , — , ? , , , . F#, C#, , . . - , F#.
, F# , , .
DotNext «The Power of Composition». , F#: , , , . , .