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

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

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

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

Ответ 1

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

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

Специальные F # -выходы:

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Прежде всего. Это не просто "функциональный против OO". Это "Функциональный + OO против OO". Функциональные функции С# довольно рудиментарны. F # нет. Между тем, F # выполняет почти все функции С# OO. По большей части F # заканчивается как супермножество функциональных возможностей С#.

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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