Каковы преимущества использования C # против F # или F # против C #? [закрыто]

Я работаю в технологической компании, которая больше занимается прототипированием, чем доставкой продукта. Меня только что спросили, в чем разница между C # и F #, почему MS создала F # и какие сценарии будут лучше, чем C #.

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

В чем преимущества использования C # против F # или F # против C #?

Общие преимущества функционального программирования перед императивными языками:

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

Особые преимущества F #:

• Асинхронное программирование чрезвычайно просто и интуитивно async {}понятно с -expressions - даже с ParallelFX, соответствующий C # -код намного больше

• Очень простая интеграция компиляторов компиляторов и предметно-ориентированных языков

• Расширение языка по мере необходимости: LOP

• Единицы измерения

• Более гибкий синтаксис

• Часто более короткие и элегантные решения

Взгляните на этот документ

Преимущества C # в том, что он часто более точен для «императивных» приложений (пользовательский интерфейс, императивные алгоритмы), чем функциональный язык программирования, .NET-Framework, который он использует, разработан императивно и более широко распространен.

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

Это все равно, что спросить, в чем преимущество молотка перед отверткой. На чрезвычайно высоком уровне оба делают по сути одно и то же, но на уровне реализации важно выбрать оптимальный инструмент для того, что вы пытаетесь выполнить. Есть задачи, которые в C # трудны и требуют много времени, но легко в F # - например, попытаться забить гвоздь отверткой. У вас точно получится - это не идеально.

Манипуляция данными - один из примеров, в котором я лично могу указать, где f # действительно сияет, а C # потенциально может быть громоздким. С другой стороны, я бы сказал (вообще говоря) сложный пользовательский интерфейс с отслеживанием состояния проще в OO (c #), чем функциональный (f #). (Вероятно, найдутся люди, которые не согласятся с этим, потому что сейчас «круто» «доказывать», насколько легко что- либо делать на F #, но я поддерживаю это). Есть бесчисленное множество других.

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

Чтобы ответить на ваш вопрос, насколько я понимаю: зачем использовать C #? (Вы говорите, что уже продали F #.)

Прежде всего. Это не просто «функциональное против ОО». Это «Функциональный + ОО по сравнению с ОО». Функциональные возможности C # довольно рудиментарны. F # - нет. Между тем, F # выполняет почти все функции объектно-ориентированного программирования C #. По большей части F # представляет собой надмножество функций C #.

Однако есть несколько случаев, когда F # может быть не лучшим выбором:

• Interop. Есть много библиотек, которые не слишком удобны для F #. Возможно, они используют некоторые вещи C # OO, которые F # не делает то же самое, или, возможно, они полагаются на внутренние компоненты компилятора C #. Например, Expression. Хотя цитату F # можно легко превратить в выражение, результат не всегда совпадает с тем, что может создать C #. У некоторых библиотек есть проблемы с этим.

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

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

• Инструменты дизайна. В F # их нет. Это не значит, что у него их не может быть, но прямо сейчас вы не можете создать приложение WinForms с выделенным кодом F #. Даже там, где он поддерживается, например, на страницах ASPX, в настоящее время вы не получаете IntelliSense. Итак, вам нужно тщательно продумать, где будут ваши границы для сгенерированного кода. В действительно крошечном проекте, в котором почти исключительно используются различные дизайнеры, возможно, не стоит использовать F # для «клея» или логики. В более крупных проектах это может стать меньшей проблемой.

  • Это не внутренняя проблема. В отличие от ответа Rex M, я не вижу ничего особенного в C # или F #, что заставило бы их лучше создавать пользовательский интерфейс с множеством изменяемых полей. Возможно, он имел в виду дополнительные накладные расходы, связанные с написанием «изменяемого» и использованием <- вместо =.

  • Также зависит от используемой библиотеки / дизайнера. Нам нравится использовать ASP.NET MVC с F # для всех контроллеров, а затем веб-проект C # для дизайнеров ASPX. Мы смешиваем фактический «встроенный код» ASPX между C # и F #, в зависимости от того, что нам нужно на этой странице. (IntelliSense по сравнению с типами F #.)

• Прочие инструменты. Возможно, они просто ожидают только C # и не знают, как работать с проектами F # или скомпилированным кодом. Кроме того, библиотеки F # не поставляются как часть .NET, так что у вас есть кое-что еще.

• Но проблема номер один? Люди. Если никто из ваших разработчиков не хочет изучать F # или, что еще хуже, испытывает серьезные трудности с пониманием определенных аспектов, то вы, вероятно, тост. (Хотя я бы сказал, что в этом случае вы все равно будете тостом.) О, и если руководство скажет «нет», это может быть проблемой.

Я писал об этом некоторое время назад: Почему НЕ F #?

Вы просите сравнить процедурный язык и функциональный язык, поэтому я считаю, что здесь можно ответить на ваш вопрос: в чем разница между процедурным программированием и функциональным программированием?

Что касается того, почему MS создала F #, ответ прост: создание функционального языка с доступом к библиотеке .Net просто расширило их рыночную базу. И, видя, что синтаксис почти идентичен OCaml, это действительно не потребовало больших усилий с их стороны.

F # - это не еще один язык программирования, если сравнивать его с C #, C ++, VB. C #, C, VB - это императивные или процедурные языки программирования. F # - это функциональный язык программирования.

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

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

F # - это, по сути, C ++ языков функционального программирования. Они сохранили почти все из Objective Caml, включая действительно глупые части, и поместили его поверх среды выполнения .NET таким образом, что он также привнес все плохие вещи из .NET.

Например, с Objective Caml вы получаете один тип нуля, параметр <T>. С F # вы получаете три типа null, option <T>, Nullable <T> и ссылочные нули. Это означает, что если у вас есть опция, вам нужно сначала проверить, имеет ли она значение «Нет», а затем вам нужно проверить, является ли она «Некоторые (ноль)».

F # подобен старому клону Java J #, просто убогий язык только для привлечения внимания. Некоторым он понравится, некоторым он даже воспользуется, но, в конце концов, это язык 20-летней давности, прикрепленный к CLR.

Один из аспектов .NET, который мне больше всего нравится, - это дженерики. Даже если вы напишете процедурный код на F #, вы все равно получите выгоду от вывода типов. Это упрощает написание универсального кода.

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

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

Однако есть ситуации, когда использование C # предпочтительнее, в зависимости от вкуса и стиля программирования.

• C # не устанавливает порядок объявления между типами и не зависит от порядка компиляции файлов.
• В C # есть некоторые неявные преобразования, которые F # не может себе позволить из-за вывода типа.