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

37

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

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

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

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

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

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

нганю
источник
7
«Пул нанятых F # программистов [...] не существует» - почти не существует. Однако, если вы найдете программиста, который специализируется на F # или желает специализироваться, он, скорее всего, будет особенным.
Тим Робинсон
Вы просите реальных подводных камней, но включаете в свой вопрос потенциальные подводные камни. Это приглашает к более «мнимым» ошибкам в ответах или не по теме ответов, опровергающих те ловушки, которые вы рассматриваете. Если бы вы понизили ваш голос из-за этой проблемы формулировки, если бы я мог (репутация слишком низкая)
Джох
Ник, я бы сказал: выбери некоторых высококвалифицированных фанатов языка, которые у тебя уже есть, и позволь им играть с F #, чтобы сделать компанию умнее / лучше / продуктивнее, а не просто для удовольствия. Есть пара таких парней, где я работаю.
Работа

Ответы:

28

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

МК
источник
13

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

На практике главная ошибка, которую я вижу в попытках людей использовать 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 #.

НТН!

Джон Харроп
источник
3
Непосредственное утверждение: язык, который вы можете выучить так быстро, не стоит добавлять в комплекс развития бизнеса. Смысл в F # - писать функциональный код, и большинство людей не собираются изучать функциональное программирование так быстро.
Дэвид Торнли
8
Пример плоского счетчика: LINQ. Написание функционального кода абсолютно не является целью F #, по любому определению «функционала». В контексте существующих разработчиков C # они уже должны быть на полпути с System.Func.
Джон Харроп
1
Если F # в первую очередь не о функциональном программировании, то о чем оно на самом деле? Как вы знаете, когда F # лучше подходит, чем, скажем, C #?
Роберт Харви
5
@ Роберт: F # предлагает множество функций, которые могут сделать его гораздо более продуктивным, чем C #. Типы вариантов и сопоставление с образцом чрезвычайно мощны для создания и управления деревьями, которые встречаются во всем, от компиляторов до компьютерной графики. Вывод типа облегчает написание сильно обобщенного кода, который идеально подходит для плотной алгоритмики. Интерактивные сеансы идеально подходят для одноразового кода, например, для массирования наборов данных из одной формы в другую или даже для проведения сложного анализа. Эти функции только случайно связаны с функциональным программированием и хорошо работают в императивном коде.
Джон Харроп
8

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

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

KVB
источник
1
@kvb, мой комментарий немного не по теме, но я просто хотел бы поделиться этим, хотя, как правило, идеально, на практике многие компании не имеют специализированных позиций, как вы описали, и требуют, чтобы, как в вашем примере, у одного разработчика был глубокий (достаточно) знание SQL, HTML, Javascript, CSS и т. д. и, возможно, бизнес-анализа. Я лично работал над обоими сценариями ( не определяемыми размером компании), и у каждого есть свои преимущества и недостатки, и он может быть более или менее подходящим для каждого проекта, но специализация, безусловно, роскошь.
Стивен Свенсен
7

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

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

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

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

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

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

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

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

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

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

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

Джо
источник
5

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

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

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

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

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

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

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

Темная ночь
источник
15
Вы собираетесь платить своим разработчикам, чтобы они работали над этим в выходные? Господь знает, что я проводил много выходных и вечеров, изучая F #, но в качестве хобби. Хотя это правда, что когда меня привлекли к проекту Grails, я учил себя этой платформе частично в нерабочее время, но это только моя личность, и мне это нравилось, но если бы кто-нибудь сказал мне сделать это в свободное время, я бы не был счастлив.
Стивен Свенсен
+1 но: Haskell и Lisp представляют чисто академический интерес. Я не думаю, что это принесет пользу программисту .NET для их изучения этих языков. Я думаю (как автор нескольких книг по F # ;-), что чтение хорошей книги было бы более продуктивным, чем попытка написать код F # (например, головоломки проекта Эйлера) в вакууме. С руководством они могут быть в курсе за один месяц.
Джон Харроп
4

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

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

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

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

gradbot
источник
Если кто-то уже знает C # и платформу .Net, изучение F # обычно стоит менее одного месяца. (основываясь на опыте двух моих коллег.)
4

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

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

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

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

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

Рей Миясака
источник
1
Если 39 фунтов стерлингов - это «огромные деньги» для обучения разработчика, то изучение F # - это наименьшее из ваших беспокойств, ИМХО.
Джон Харроп
Ой, сам человек. Человек, ты везде, не так ли? На самом деле 39 фунтов стерлингов - это огромные деньги за ту информацию, которую в наше время почти всегда можно найти в блогах или технических документах.
Рей Миясака
2
Вся очень актуальная информация, я не уверен, почему люди голосуют против вашего поста. Как бы мне ни нравился F #, вопрос касается его отрицательных сторон, и посты, указывающие на них, не должны быть отвергнуты любителями F #.
Джох
1

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

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

leppie
источник
Что если следующий сопровождающий также знает Схему? Я прочитал на comp.lang.lisp, что программисты на Лиспе работают с целью предоставления замен своим работодателям, если это необходимо.
Ларри Коулман
0

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

Неманья Трифунович
источник