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


93

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

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

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


4
Мне кажется, что по SO уже довольно много вопросов, которые хотя бы частично отвечают на ваш вопрос. Вы пробовали использовать для поиска "[F #] keyword" вместо "f # keyword"? («[f #] преимущества», например)
Бенджол

Ответы:


86

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

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

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

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

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

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

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

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

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

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

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

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


16
Они сочетаются очень странным образом. Например, вы можете перегрузить оператор> в F #. После этого разработчики C # могут его использовать. Однако разработчики F # не могут. Правильно, F # может генерировать перегрузки оператора, которые он не может потреблять.
Джонатан Аллен

Ссылка "этот документ" не работает ...
Эдуардо Бритес

36

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

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


22
Если у вас есть только молоток, все выглядит как гвоздь. -Maslow
Чарли

20
Я не собираюсь голосовать за это, потому что он не дает никаких реальных подробностей, кроме одного примера данных. Я знаю, что это разные инструменты. Я спрашиваю, в какой работе эти два инструмента лучше и хуже всего по сравнению друг с другом. Я знаю, что Philips часто оказывается лучшим инструментом для работы, даже если подойдет плоская головка меньшего размера.
Gradbot 04

1
Ха-ха, спасибо @Spencer;) @gradbot - без проблем! Извините, мой ответ не совсем то, что вы ищете ... надеюсь, другие сочтут его полезным.
Rex M

14
Если у вас есть только молоток, все будет похоже на большой палец.
Эд Пауэр

6
Я согласен с gradbot, это хороший ответ, поэтому я не отказываюсь от него, однако он не касается специфики исходных вопросов. Этот ответ представляет собой лишь расплывчатое концептуальное объяснение, но на самом деле упускает суть точного ответа на вопрос.
Стэн Р.

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

6
О том, что F # имеет лучшую производительность, чем C # для математики: По-видимому, это неправда. См. Thinkfulcode.wordpress.com/2010/12/30/…
Joh

3
@Joh: inlineэто очевидный пример того, что может обеспечить значительное улучшение производительности в F #, чего не может выразить C #.
JD

@Jon Harrop: Я специально имел в виду запись в блоге Рината. Похоже, что время в пользу F #, которое он получил, было связано с неоптимальным кодом C #.
Joh

27

Чтобы ответить на ваш вопрос, насколько я понимаю: зачем использовать 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 #?


6

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

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


1
Хотя я думаю, что ваш общий ответ верен, что на самом деле вопрос заключается в сравнении парадигм программирования, а не языков, я считаю, что ответ на вопрос, на который вы ссылаетесь, немного поверхностный.
Jeroen Huinink 04

Не стесняйтесь предлагать другой вопрос, если у вас есть вопрос получше. Это самый высокий рейтинг, который я нашел при поиске в Google.
Спенсер Рупорт, 04

1
Я думаю, он пытался быть добрым, говоря, что вы говорите, что F # не требует особых усилий со стороны Micrsoft.
Matthew Whited

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

C # vs F #! = Процедурный vs функциональный.
JD

5

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

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

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


4
-1. F # - это мультипарадигмальный (OO + FP) язык. Только чисто функциональные языки не имеют побочных эффектов (например, Haskell), но F # не чист.
Маурисио Схеффер,

5

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

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

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


Мы надеемся, что массы вольются в них, и F # 5 будет более прагматичным.
Джонатан Аллен,

1
Я согласен с тем, что Nullable <T> должен заставить компилятор сделать за нас какое-то волшебное алиасинг. Я не уверен, что сделать "Some null" эквивалентным None всегда будет работать - некоторый код взаимодействия может полагаться на это. Но ссылка null? Как вы собираетесь обойти серьезную дыру в .NET? Обернуть каждый тип ссылки в опции? На практике это кажется проблемой только в определенных сценариях взаимодействия.
MichaelGG

12
FWIW, я профессионально кодирую на F # в течение нескольких лет (дольше, чем кто-либо другой в мире), и я никогда не видел этой проблемы или кода Some nullв каком- либо коде F # где-либо. Из всего, о чем люди могут беспокоиться, это должно быть в самом конце списка ...
JD

1
Сравнение F # и C ++ несколько надумано. Многие части C ++ имеют неопределенную или неясную семантику, F # прост и четко определен. Качество среды выполнения .NET не может сравниться с F #, поскольку любой язык .NET будет иметь те же проблемы.
Joh

1
За более чем 2 года профессионального программирования на F #, такого как @Jon, я никогда не видел проблем, связанных с "Some null". С другой стороны, я извлек огромную пользу из возможностей инфраструктуры .Net.
Marc Sigrist

5

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

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

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

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

  • C # не устанавливает порядок объявления между типами и не зависит от порядка компиляции файлов.
  • В C # есть некоторые неявные преобразования, которые F # не может себе позволить из-за вывода типа.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.