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

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

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

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

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

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

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

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

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

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

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

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

  • также зависит от используемой библиотеки / конструктора. Мы любим использовать ASP.NET MVC с F# для всех контроллеров, а затем веб-проект C#, чтобы получить дизайнеров ASPX. Мы смешиваем фактический ASPX "код inline" между 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 вы получаете один тип null, параметр. С помощью F# вы получаете три типа null, option, Nullable и ссылочные значения null. Это означает, что если у вас есть возможность, вы должны сначала проверить чтобы увидеть, если это "нет", то вам нужно проверить, если это"некоторые(null)".

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

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

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

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

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

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