Реальные подводные камни внедрения F # в большую кодовую базу и команду инженеров [закрыто]

Я технический директор программной фирмы с большой существующей кодовой базой (все на C #) и значительной командой инженеров. Я вижу, как некоторые части кода будет гораздо проще писать на F #, что приведет к более быстрому времени разработки, меньшему количеству ошибок, более легким параллельным реализациям и т. Д., В основном к общему увеличению производительности для моей команды. Тем не менее, я также вижу некоторые подводные камни производительности введения F #, а именно:

1) Каждый должен изучать F #, и это не так тривиально, как переход, скажем, с Java на C #. Члены команды, которые не изучили F #, не смогут работать с F # частями кодовой базы.

2) Пул наемных программистов на F # на данный момент (декабрь 2010 г.) отсутствует. Поиск в различных базах резюме резюме программиста по слову "F #", причем менее 1% резюме содержат ключевое слово.

3) Поддержка сообщества на данный момент (декабрь 2010 г.) менее доступна. Вы можете погуглить практически любую проблему в C # и найти кого-то, кто уже имел дело с этим, не так с F #. Поддержка сторонних инструментов (NUnit, Resharper и т. Д.) Также схематична.

Я понимаю, что это немного Catch-22, то есть, если такие люди, как я, не используют F #, тогда сообщество и инструменты никогда не материализуются и т. Д. Но у меня есть компания, которую я могу запустить, и я могу быть передовой, но не кровоточащий край.

Любые другие подводные камни, которые я не рассматриваю? Или кто-нибудь хочет опровергнуть упомянутые мною подводные камни? Я думаю, что это важная дискуссия, и я хотел бы услышать ваши контраргументы на этом публичном форуме, который может многое сделать для увеличения внедрения F # в промышленности.

Поиск резюме для других функциональных языков, таких как Scheme, Lisp или Haskell. Многие люди изучают их в школе и имеют их в резюме; Я уверен, что многие из них не будут против изучения F #. У меня есть Схема в моем резюме, хотя я никогда не использовал ее после школы, и работа с F #, вероятно, также привлекла бы мое внимание.

Любые другие подводные камни, которые я не рассматриваю?

На практике главная ошибка, которую я вижу в попытках людей использовать F #, - это проблемы, когда он не подходит для работы.

Или кто-нибудь хочет опровергнуть упомянутые мною подводные камни?

Все они, очевидно, в какой-то степени справедливы, но я бы спросил, в какой степени.

Например, вы говорите, что каждый должен изучить F #, чтобы работать с кодом F #. Хотя это правда, на практике это не имеет большого значения. Изучение F # не более важно, чем изучение WPF, Silverlight или TPL. Я учу около 30 разработчиков, как использовать F # для клиента в Лондоне прямо сейчас, и около десятка работали полный рабочий день над кодом F # всего за несколько недель, и они только что отправили свой первый продукт (вовремя и в рамках бюджета! ) почти полностью написана на F # всего через несколько месяцев. Фактически, у них было больше технических трудностей с Silverlight, чем с F #, и они обнаружили, что техническая поддержка Silverlight намного хуже, чем для F #.

Вы ссылаетесь на сравнительно небольшой пул доступных программистов на F #, но, опять же, учитывая, как легко подобрать F #, я не думаю, что это серьезная проблема. Я сомневаюсь, что вам придется нанимать многих, если таковые имеются. У моего клиента есть два парня F # для более чем 100 программистов, и наша работа заключается в том, чтобы начинать и контролировать использование F #.

Ваша третья и последняя проблема связана с меньшей поддержкой сообщества, поиском Googling для C # по сравнению с F # и поддержкой сторонних инструментов. Опять же, я не нашел это проблематичным на практике. Я отправил fsbugs по электронной почте комментарий о единицах измерения в F # и получил ответ в течение 24 часов от исследователя, который изобрел его с подробным объяснением того, почему моя интерпретация была неправильной и почему она работает так, как работает. Я никогда не получал это от Андерса Хейлсберга ;-). Я постоянно ищу решения и нахожу их написанными на C #, VB или даже IronPython, но за 3 года использования индустрии F # могу вспомнить только один случай, когда перевод решения на F # не был тривиальным. Фактически, я недавно преобразовал образец сериализатора данных C # из MSDN в F #, и он был в 5 раз короче. Наконец, вы упомянули поддержку F # в таких инструментах, как NUnit, когда мы Уже некоторое время без проблем использую NUnit из F #. Это инструменты .NET, а не инструменты C #.

Пример из практики : Мой текущий клиент не только использует NUnit для модульного тестирования, но и построил TickSpec в F # поверх NUnit как технически превосходную альтернативу SpecFlow для BDD. Автор показал, что TickSpec - это небольшая часть размера SpecFlow и предоставляет больше возможностей. Более того, некоторые разработчики, не имеющие опыта работы с F # (и, я полагаю, не имея опыта работы с функциональным программированием), подхватили его и начали использовать его в несвязанных проектах без проблем именно потому, что F # + TickSpec облегчает решение их проблем. проблемы.

FWIW, я дал своему клиенту бесплатную подписку на сайт в нашем F # .NET Journal, что хорошо сочеталось со многими разработчиками, изучающими F #.

НТН!

Как вы уже поняли, ваши программисты, которые не знают F #, не могут работать с F # частью вашей кодовой базы. Однако вам не нужно переписывать всю кодовую базу на F #, чтобы получить преимущества от ее использования - просто переписайте части, где вы увидите наибольшую выгоду. Тот факт, что F # действительно хорошо взаимодействует с C #, позволяет относительно легко вырезать определенные детали и создавать из них сборки F #.

Если бы ваши инженеры работали над традиционным трехуровневым приложением, вы, вероятно, не стали бы настаивать на том, что им всем необходимо иметь глубокие знания SQL, HTML, Javascript, CSS и т. Д. Вместо этого у вас, естественно, будут работать некоторые специалисты. на разных частях приложения. Поэтому я не думаю, что добавление нового языка для одной части вашего приложения должно быть слишком большим препятствием. Кроме того, вы можете использовать стандарты кодирования и другие методы, чтобы удостовериться, что ваш код F # читабелен даже инженерами без глубокого знания F #.

Подводные камни при добавлении F # к используемым языкам включают в себя подводные камни при внедрении любой новой технологии. Независимо от преимуществ, если некоторые из вашей команды не хотят или недостаточно гибки в обучении, они не смогут работать над проектами F #. Тем не менее, если вы позволите динозаврам в вашей команде препятствовать внедрению новых технологий, ваша компания обречена.

Единственные подводные камни, которые я лично испытал:

1. Трудности при отладке. Следить за ходом выполнения программы на основе выражений в отладчике, предназначенном для языков на основе операторов, может быть сложно.

2. Расстраивающий intellisense. Автозаполнение перестает работать именно тогда, когда вам это нужно. Microsoft должна работать над тем, чтобы сделать анализатор фона более отказоустойчивым.

3. Чувствительный к отступам синтаксис затрудняет копирование-вставку или переформатирование кода.

4. Отсутствие рефакторинга.

5. Некоторые из существующих удобных VS-расширений для F # (свертывание кода, раскраска глубины) немного медленны, что делает процесс набора текста немного разочаровывающим.

На мой взгляд, ни один из этих вопросов не является стоп-шоу, и я могу жить с ними в настоящее время. Инструменты легче улучшить и исправить, чем языки.

Ваши опасения, что нанять новых программистов, способных писать на F #, будут довольно сложными, на мой взгляд, неоправданны. Если бы вы написали руководство по кодированию, вы бы посоветовали или запретили какие-либо из следующих функций в C #: yield returnLINQ к объектам, лямбды, предстоящее async?

Если вы считаете, что эти функции помогают лучше писать код, то нет причин воздерживаться от F #. Язык поддерживает эти функции плавно и хорошо продуманно, чего C # не может сделать из-за своего наследия.

Если ваша команда достаточно умна, чтобы понять концепции, о которых я говорил, у них есть все, что им нужно, чтобы быть отличными программистами на F #. То же самое касается будущих новобранцев: наймете ли вы кого-либо, кто не способен или не желает использовать функции, появившиеся после C # 1.0?

Я обдумывал эту точную ситуацию.

Вот что я планирую для своей команды:

• Смешайте C # с F #, это можно сделать с помощью C # для большей части кода. Там, где требуется интенсивная обработка данных , напишите связанные функции в F # и поместите их в dll, или обратитесь к ним. Пример здесь

• Медленно пересмотрите существующую кодовую базу вышеописанным способом.

• Не весь код должен быть функциональным.

• Получите вашу команду, чтобы изучить основы Haskell, LISP по выходным .

• Заставьте их изучать F #, пытаясь разгадать загадки Euler Project (это мне очень помогло, когда я изучал F #). Опять же, это должно быть сделано в конце недели или во время работы, если вы хотите выделить день для «тренировок».

1) Изучение функционального языка увеличит общие возможности кого-то как программиста, однако это относится только к тем, кто хочет учиться и совершенствоваться. Не каждый программист хочет стать лучше и не хочет перемен в своей рабочей среде (знайте свою команду).

2) Я не могу спорить с этим. Вы должны будете заплатить за 6-месячную кривую изучения любого нового языка, однако знание библиотек .net исключает дополнительные годы, необходимые для изучения новых библиотек.

3) Поддержка сообщества, хотя и меньше, чем C #, имеет довольно много высококвалифицированных активных разработчиков F #, размещающих в Интернете. Не забывайте, что большая часть языковой поддержки - это поддержка библиотек, и есть отличная поддержка .NET.

Горилла за тысячу фунтов здесь - управление рисками. «Я могу быть режущим, но не кровоточащим». Я бы сказал, что F # не является передовой Он был выпущен с VS2010 и напрямую поддерживается Microsoft. Bleeding edge - это «бета» и отказ от Microsoft, говорящий о том, что мы ни за что не несем ответственности.

С практической точки зрения поддержка IntelliSense совершенно отсутствует - до такой степени, что прирост производительности при выводе типов опережает менее сложное автозаполнение, доступное в C #.

Сообщения об ошибках, вызванные ошибочными выводами типов, также требуют больше времени для исправления для начинающих (и часто для промежуточных пользователей, таких как я), просто потому, что вы менее склонны предоставлять аннотации типов, чем вы бы делали на языке, подобном C #.

ООП также удивительным образом не хватает в F #; например, нет поддержки для вложенных типов / классов. Вы должны быть осторожны при переносе кода, потому что есть некоторые вещи, которые вы можете сделать в C #, которые вы не можете сделать в F #, к сожалению.

И последнее, но не менее важное: размер и качество сообщества F # разочаровывают. Большая часть информации F #, размещенной в Интернете, либо относится к старым версиям, либо просто не очень хороша - либо не идиоматична, либо плохо работает, либо некорректна. Кроме того, есть люди, которые берут огромные деньги за информационные бюллетени, которые в основном представляют собой только существующие информационные дайджесты.

Я сам использую C # для рабочих проектов и F # для своих собственных вещей. Как бы я ни любил F #, к сожалению, довольно сложно предсказать, как / когда все может развалиться.

Основной проблемой всегда является ремонтопригодность.

Я хотел бы написать код в Scheme, но следующий сопровождающий, вероятно, захочет выследить меня и замучить.

Я бы сказал, что первое, что вам нужно сделать, это спросить членов вашей команды, что они думают о представлении F #. Если им понравится идея, все пойдет намного лучше, а если нет.