Кого расспрашивать про F#, как не человека, посвятившего этому языку подробный сайт? Скотт Влашин создал ресурс «F# for Fun and Profit», знакомый многим хабравчанам: на Хабре переводили оттуда и серию статей «Функциональное мышление», и статью «Железнодорожно-ориентированное программирование».
А в ноябре он выступит в Москве на нашей конференции DotNext с докладом «The power of composition». И в преддверии этого выступления мы расспросили его про F# и вообще функциональное программирование.
— Зайдём с самого начала: чем вы занимались до функционального программирования, как вы пришли к F# и как создали сайт?
— Я человек уже почтенного возраста, и когда я учился в университете, отдельных программ по computer science ещё не было. Я получил математическое образование, но заниматься математикой не хотел, поэтому после университета я где-то 10 лет работал на самых разных работах, в том числе плотником.
В один прекрасный день в конце 1980-х мой отец купил для своей работы компьютер, CP/M Kaypro, с мизерным количеством памяти и 5.25-дюймовыми дискетами. Это было ещё до того, как появился Windows, так что на нём стоял DOS. Именно на нём я и начал программировать. Я занимался базами данных, поначалу для моего отца, ему это нужно было для его работы. А потом я стал делать это уже профессионально.
Моим первым языком был Turbo Pascal, а в 1989-м или 1990-м я познакомился со Smalltalk, и он мне очень понравился, это до сих пор один из моих любимых языков. Одна работа сменяла другую, и в итоге я, как и большинство программистов, попал на работу в крупную компанию писать скучные бизнес-приложения (я называю их «BLOBs»: Boring Line-of-Business applications). И в течение очень долгого времени занимался только этим.
Какое-то время я писал на Python, где-то 10 лет — на C#. А в 2011 году, то есть уже не так давно, я решил, что мне надоела моя работа и хорошо бы попробовать что-нибудь новенькое; поэтому я захотел заняться функциональным программированием. Оказалось, что в моём Visual Studio уже был функциональный язык, поэтому я попытался разобраться в F#. И поначалу он казался очень странным, я ничего не мог понять, настолько сильно он отличался от всего того, с чем я работал раньше.
По F# было несколько неплохих блогов, но их было очень мало, и документации тоже было мало. В итоге мои знакомые дали мне отличный совет: если хочешь как следует что-то изучить, попытайся начать учить этому других, потому что это заставляет очень хорошо разобраться в теме. Кроме того, мне посоветовали завести блог, это позволяет выделиться среди других программистов.
В общем, в 2012 я завёл блог «F# for fun and profit» и стал публиковать в нём статьи каждый раз, когда узнавал что-то новое об F#. Сейчас там несколько сотен страниц, и он обрёл большую популярность. Поначалу это было просто хобби, я занимался им в свободное от работы время. А где-то 3 или 4 года назад я решил уйти с моей работы и стать консультантом-фрилансером. В позапрошлом году я написал книгу, которая тоже оказалась довольно популярной. Вот так и состоялось моё знакомство с F#.
— Как фрилансер вы работаете именно с F#, или не только?
— В основном F#, хотя вообще говоря, за что заплатят — по тому и консультирую *смеётся*. Если мне нужны деньги, а у кого-то есть работа по C#, и она выглядит интересно, я за неё берусь. А прошлом году я три месяца работал с Python. Мне важнее не язык, а то, какую именно проблему приходится решать. Мне нравится учиться, а когда тебя нанимают решить какую-то проблему, приходится стать если не экспертом, то по крайней мере разобраться в какой-то новой области.
Мне таким образом пришлось изучить экономику недвижимости и страховые риски. Я считаю, что хороший код можно написать только тогда, когда хорошо понимаешь предмет, которым занимаешься, а не просто пишешь, что тебе говорят другие. Для меня это самое интересное — не язык, а проблема.
— В России, хотя у части разработчиков есть интерес к F#, бизнесу с этим языком сложно: разработчика сложнее найти или заменить, чем с C#. А те компании, с которыми вы работаете, как решаются на F#?
— Тут есть две наиболее распространённых ситуации. Первый вариант — это когда компания уже использует F#, у них обычно есть какой-нибудь экспериментальный проект. Они зовут меня и просят помочь им запустить этот проект и научить их языку. Обычно они готовы потратить где-то полгода на такой проект, чтобы разобраться, хотят ли они этим заниматься дальше.
Помимо этого, я занимаюсь обучением людей предметно-ориентированному проектированию (domain-driven design), и здесь F# не в центре внимания, но я его использую как язык. Я демонстрирую программистам, привыкшим к C#, насколько короче может быть один и тот же код на F#, чем на C#. То есть я тихой сапой продвигаю язык. Этому помогает то, что на F# не обязательно переходить целиком, можно модель предметной области (domain model) написать на F#, а всё остальное — на C#.
— Вы говорите, что C# и F# можно использовать вместе. Но в энтерпрайзе на C# чаще всего используются Entity Framework, NHibernate или что-то подобное. А среди разработчиков на F# такое куда менее популярно. Как смешивать эти языки с учётом разницы подходов?
— Одна из компаний, с которой я работал, использует Entity Framework. Они пытались перейти на архитектуру Ports and Adapters, то есть вывести все операции ввода/вывода из ядра архитектуры. Для этого Entity Framework подходит довольно плохо. В таких ситуациях значительно удобнее использовать нечто вроде Dapper, позволяющее не заниматься SQL посредине вашего кода. Помимо прочего, это упрощает тестирование.
Пускай они не используют функциональное программирование, но ситуация всё равно толкает их к тому, чтобы иметь чистое ядро программы, а базу данных держать где-то на периферии. Если мышление перешло на такой формат, то это уже важный шаг в направлении отказа от Entity. В такой компании я, на самом деле, не стал бы уже ничего менять. Нельзя заставить людей измениться, они должны сами хотеть изменений. Я не пытаюсь себя продавать и навязывать кому-то тот способ, который я считаю лучшим. Обычно люди уже хотят измениться, и я им только помогаю этого добиться. Вы понимаете, о чём я?
— То есть ваши клиенты — это компании, которые уже сами переходят на более функциональный подход.
— Даже если они работают с C#, они переходят на более функциональный C#, начинают использовать LINQ, иммутабельные структуры данных, то есть в целом идут в этом направлении. Поэтому для них переход на F# уже не является большим скачком.
Похожи ли профессии разработчика и плотника
— У вас в твиттере есть интересный тред, сравнивающий работу программиста и плотника. Хочется поспрашивать о «функциональщине», оттолкнувшись от этого треда. Но можете для начала пересказать для наших читателей его суть?
— Разработчики любят сравнивать себя с инженерами, а разработку софта — с возведением зданий или мостов. И есть много споров о том, действительно ли программирование близко этим занятиям, или они принципиально различаются. Мол, у нас требования к проекту каждый день меняются — когда строишь мост, вероятно, всё совсем не так? Или на самом деле и там тоже так?
Я же считаю, что в этом споре нет единого правильного ответа. Инженером я никогда не был, зато был плотником. И могу сказать, что у плотников есть много разной работы, сильно отличающейся по формату, и для каждой нужен свой подход.
Например, на одной из работ я делал кухонные шкафы. В Америке они все очень сильно стандартизированы, все одинакового размера, подогнаны друг под друга, и работа ведётся электроинструментами. Какое-то качество обеспечить необходимо, но в Америке старую кухню обычно выбрасывают, когда дом меняет владельца, то есть очень долго она служить не будет. Так что в такой работе всё завязано на скорость и на экономию средств.
Потом у меня было другое задание, где мне нужно было заменить большую, 6-дюймовую дубовую балку посередине комнаты в здании, которому было 400-500 лет. Здесь всё было наоборот: всё было изогнутым, никаких прямых углов, и чтобы её заменить, нужно было от руки подогнать новый кусок дерева так, чтобы он имел ровно такую же форму, что и старый. Это требовало большой аккуратности.
Наконец, была третья работа, на которой я делал декорации для сцены. Они делались из фанеры и очень тонкого дерева для подпорок.
Моя мысль в том, что каждая работа требует своего подхода. В случае с кухонными шкафами нужна точность, использование электроинструментов и воспроизводимость результатов. В старом деревянном доме ты работаешь с легаси-системой, тут важно быть аккуратным, не торопиться, нужна не скорость, а правильность результата. Наконец, в случае с декорациями ты сознательно создаёшь хрупкую конструкцию, которая не должна быть прочной, зачастую её приходится за несколько минут распиливать и собирать заново, вечно такие конструкции не служат.
Когда говорят, что программирование похоже на инженерное дело, это верно только по отношению к некоторым типам программирования. Например, если вы пишете софт, управляющий самолётом, нужно быть очень аккуратным и добиться очень большой точности. Совсем другое дело — скрипт в одну строку для поиска файлов, это больше похоже на создание декораций. Нет никакого смысла тратить 20 часов на то, чтобы доказать, что этот скрипт работает, и писать для него 1000 юнит-тестов. Вся работа должна занять не больше 5 минут. А когда работаешь с унаследованной системой, нужно максимально подогнать свой код под уже существующий, большие рефакторинги тут нежелательны.
То есть в каждом случае важен контекст. Иногда нужно много планировать, много обдумывать проект, писать много тестов. В других случаях достаточно сделать что-то на скорую руку. Многим людям в этом отношении не хватает гибкости, они считают, что если ты не используешь юнит-тестов или не пользуешься некоторым языком программирования, то ты не профессионал. На самом деле, мысль о том, что всё зависит от контекста, довольно очевидная. Удивительно скорее то, насколько упрямо некоторые программисты настаивают на своих идеях, и если ты хоть как-то отступаешь от их идеалов, тебя тут же отправляют в чёрный список. По-моему, это глупо.
— Вы говорите, что для стороннего наблюдателя деятельность выглядит единообразной, но когда видишь её изнутри, обнаруживаются совершенно разные случаи. И хочется спросить: а с функциональным программированием так же? У тех, кто смотрит извне, общий стереотип, а на самом деле есть гигантские различия?
— Совершенно верно. Со стороны может казаться, что все «функциональщики» мыслят одинаково, но там множество различных групп, которые спорят друг с другом: сторонники Haskell, F#, Clojure, Elm. Даже внутри F# есть сильные разногласия относительно того, в каком направлении этот язык должен развиваться — следует ли пытаться имитировать Haskell или приоритетом должна быть простота использования. Так что вы правы, внутри это поле значительно более многообразное, чем его обычно представляют сторонние наблюдатели.
— Для различий в работе плотника вы привели очень наглядные примеры. Можете ли различия в функциональном программировании тоже проиллюстрировать конкретными примерами?
— Существует школа функционального программирования, которая считает, что нужно стараться всё доказать, и чтобы всё было математически идеально. В этой школе используется много математического жаргона, например, «моноиды» или «монады». Это в основном пользователи Haskell, и тут большое влияние академической среды.
А есть люди, которым важнее добиться результатов. Их интересует не столько математика, сколько иммутабельность и вынос I/O на периферию. Лучший пример этого подхода — сообщество Elm. Тут в первую очередь занимаются созданием веб-приложений. В противоположность первой группе, здесь сознательно не пользуются математическим жаргоном, и сознательно отказываются от части функциональности, которая есть в Haskell и которую пользователи Haskell считают жизненно необходимой.
Помимо этого, есть спор между сторонниками сильной типизации и динамической типизации. В представлении обывателя функциональное программирование — это что-то вроде Haskell или F#, но помимо них, есть языки вроде Clojure, у которых динамическая типизация и совсем другой подход к решению проблем. Если собрать всю эту разношёрстную компанию в одной комнате, они могут и подраться. Я же считаю, что у всех подходов есть свой резон, и когда я работаю на кого-то, я им не говорю, что их подход неправильный.
— Многих отпугивает упомянутая «академичность» («F# уходит корнями в ML, который для строгих научных доказательств, а я тут реальные проблемы решаю»). Но, получается, люди зря боятся?
— Мне вообще кажется странным, что так много людей привыкли считать академичность чем-то отрицательным. Ну то есть как, одни считают отрицательным, другие — положительным.
Дело в том, что многие технологии, которые мы сейчас используем в программировании, возникли в академической среде, например, сборка мусора или типы. Так что в самих по себе академических приёмах ничего плохого нет. Другой вопрос, что излишний акцент на них может принести вред, потому что у учёных и у программистов разные цели.
Хоть у функциональных языков и академические корни, но мне кажется правильным сознательное решение скрыть эту логику в таких языках, как F# и Elm. Поэтому F# используется не для доказательства теорем, а для решения реальных задач, это очень прагматический язык. А в университетах сейчас перешли на ещё более сложные языки, такие, как Coq, F* и тому подобные. Они значительно более академичные, и используются для доказательства теорем.
Как я уже сказал, учёные и программисты занимаются разными вещами. Программисты большую часть времени проводят с чтением и записью файлов, работой с базами данных, отображением данных на экране, проверкой введенных данных, преобразованием их и т. п. А учёным такие вещи не интересны. Но дело в том, что вещи, бывшие сугубо академическими 40 лет тому назад, могут таковыми и не быть сегодня.
— Как вы сами сказали в связи с работой плотника, в разных контекстах хороши разные подходы, нет универсальных. И конкретно F# тоже лучше всего подходит к определённым задачам. Что это за задачи?
— Да, это определённо не универсальный язык, я точно не стал бы рекомендовать его использовать вообще всем подряд, это было бы глупо. Но мне кажется, F# является отличной заменой C# — за исключением задач, требующих совсем уж высокой производительности. Программирование на F# основано на совершенно другом подходе: на иммутабельности, структурном равенстве, эксплицитных зависимостях, в F# нет значений null и так далее. И мне кажется, что этот подход значительно полезнее при решении повседневных задач программирования.
Поэтому если человек использует C#, ему определённо следует поинтересоваться F#, этот язык поможет сделать код лучше. Что касается других областей применения, то мне кажется, что F# хорошо подошёл бы для многих задач, для которых сейчас используется Python. F# и Python очень похожи, и мне кажется, что у F# отличный потенциал для обработки данных. Пока что в этой области нужно ещё поработать, но, возможно, через несколько лет люди будут использовать F# для различных вещей, связанных с big data и data science, для которых сейчас используется Python.
Наконец, на F# очень удобно работать с JavaScript. В общем-то, напрямую с JavaScript работать никто не хочет, поэтому существует множество языков, которые компилируются в JS: например, ReasonML (который работает на OCaml) и Fable (который работает на F#). Лично мне предпочтительнее работать с любым из этих вариантов, чем разбираться с JavaScript, поэтому при работе над фронтендом я выбрал бы что-нибудь вроде Fable. Так что это три основные области, в которых F# показывает свои лучшие стороны.
— Как вы заметили в своём докладе «F# for C# developers», главное в языке — не синтаксис, а философия. Но здесь кроется сложность для тех, кто хочет побыстрее понять «подходит ли мне этот язык». Понять, нравится ли синтаксис, можно уже по беглому знакомству. А вот сколько времени нужно, чтобы разобраться в философии языка?
— Человек, который пишет на C#, может довольно быстро разобраться в языке вроде Java или Go, потому что у большинства этих стандартных языков примерно одна императивная модель. Перейти от них к F# определённо требует больших усилий, и это некоторых людей останавливает. По моему опыту, F# значительно проще научиться, если на какое-то время забыть всё, что знаешь про ООП. В противном случае начинаешь переносить в F# всякие вещи из C#.
Что касается времени, то где-то через две недели обучения уже можно начать писать работающий код, и ещё несколько месяцев понадобится, чтобы более-менее освоиться с языком. Наконец, для хорошего уровня владения нужно больше времени, 6 месяцев, может больше — это если речь идёт о том, чтобы разобраться во всех библиотеках, идиомах и тому подобном.
Но, если честно, перейти на F# не сложнее, чем перейти на Entity или WPF. Они тоже требуют больших затрат времени. Не стоит преуменьшать необходимые усилия, но иногда говорят, что на этот переход нужны годы. Повторюсь: чтобы начать писать код, нужно несколько недель, чтобы освоиться — несколько месяцев. Я это говорю как по собственному опыту, так и по опыту других людей, с которыми я общался.
Нужно ли до F# знать C#
— Понятно, что среди использующих F# большинство пришли в него из C#. А много ли таких, кто приходит в F# без опыта C#?
— Таких людей не очень много, и им довольно тяжело, потому что у всех библиотек документация для C#, поэтому человек везде натыкается на примеры из C#. Но всё-таки такие люди есть, а кроме того, F# преподаётся в нескольких университетах.
Есть такие, кто пытается учить F# после Python. Проблема в том, что F# очень сильно зависит от .NET, а .NET завязан на C#. Та же самая ситуация с Visual Basic, там тоже все примеры на C#. Будем надеяться, что в ближайшие несколько лет эту ситуацию удастся изменить и сделать язык проще в освоении, сейчас это одна из важных проблем.
— Если студентам дают и 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#: наоборот, он рассчитан на тех, кто раньше с функциональным программированием особых дел не имел, так что базовые понятия там будут разъяснены. А кроме этого доклада, на конференции будет ещё много интересного для дотнетчиков.
