Які переваги використання C # vs F # або F # vs C #? [зачинено]

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

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

Які переваги використання C # проти F # чи F # проти C #?

Загальні переваги функціонального програмування над імперативними мовами:

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

Спеціальні переваги F #:

• Асинхронне програмування надзвичайно просто та інтуїтивно зрозуміло з async {}-вираженнями - Навіть з 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 #.)

По-перше. Це не просто "функціонал проти ОО". Це "Функціональний + OO проти OO". Функціональні функції C # досить рудиментарні. F # 's не є. Тим часом F # має майже всі функції O # C #. Здебільшого F # закінчується як надмножина функціональності C #.

Однак є кілька випадків, коли F # може бути не найкращим вибором:

• Інтероп. Є багато бібліотек, які просто не будуть занадто зручними для F #. Можливо, вони використовують деякі речі C # OO, які F # не робить те саме, або, можливо, вони покладаються на внутрішні компоненти компілятора C #. Наприклад, Expression. Хоча ви можете легко перетворити пропозицію F # у вираз, результат не завжди є саме тим, що створить C #. Деякі бібліотеки мають проблему з цим.

  • Так, інтероп - це досить велика мережа, яка може призвести до тертя з деякими бібліотеками.

  • Я вважаю, що інтероп також включає, якщо у вас є велика наявна база коду. Можливо, не має сенсу просто починати писати частини у 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 # - функціональна мова програмування.

Дві основні переваги функціональних мов програмування (порівняно з імперативними мовами) полягають у тому, що вони не мають побічних ефектів. Це значно спрощує математичні міркування про властивості вашої програми. 2. що функції є першокласними громадянами. Ви можете передавати функції як параметри іншим функціям так само легко, як і іншим значенням.

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

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

Наприклад, з Objective Caml ви отримуєте один тип null, параметр <T>. За допомогою F # ви отримуєте три типи нульових параметрів, параметр <T>, Nullable <T> і опорні нулі. Це означає, що якщо у вас є опція, вам потрібно спершу перевірити, чи є вона "None", а потім вам потрібно перевірити, чи є "Some (null)".

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

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

У C # ви пишете конкретний код за замовчуванням, і вам доведеться ввести додаткову роботу, щоб написати загальний код.

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

Однак є ситуації, коли краще використовувати C #, залежно від смаку та стилю програмування.

• C # не встановлює порядок декларування серед типів і не чутливий до порядку компіляції файлів.
• C # має деякі неявні перетворення, які F # не може дозволити собі через умовиводи типу.