Які основні відмінності між Haskell та F #? [зачинено]


135

Я шукав в Інтернеті порівняння між F # і Haskell, але не знайшов нічого справді остаточного. Які основні відмінності і чому я хотів би вибрати одне над іншим?


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

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

Відповіді:


128

Haskell - це "чиста" функціональна мова, де як F # є аспекти як імперативу / ОО, так і функціональних мов. Haskell також має ліниве оцінювання, яке досить рідко зустрічається серед функціональних мов.

Що означають ці речі? Чисто функціональна мова означає відсутність побічних ефектів (або змін у загальному стані, коли функція викликана), що означає, що ви гарантовані, що якщо ви викликаєте f (x), нічого іншого не відбувається, крім повернення значення з функції, такі як вихід консолі, вихід бази даних, зміни глобальних або статичних змінних .. і хоча Haskell може мати нечисті функції (через монади), це повинно бути "явно" передбаченим через декларацію.

Чисті функціональні мови та програмування "Без побічних ефектів" набули популярності останнім часом, оскільки добре піддаються багатоядерному паралелізму, оскільки набагато складніше помилитися, не маючи спільного стану, а не безліч замків та семафорів.

Ліниве оцінювання - це те, коли функція НЕ оцінюється, доки це абсолютно не потрібно. це означає, що багатьох операцій можна уникнути, коли це не потрібно. Подумайте про це в базовому реченні C # if, наприклад:

if(IsSomethingTrue() && AnotherThingTrue())
{
    do something;
}

Якщо IsSomethingTrue()значення false, AnotherThingTrue()метод ніколи не оцінюється.

Хоча Haskell є дивовижною мовою, головною перевагою F # (на даний момент) є те, що він сидить над CLR. Це надає можливість самостійного програмування поліглотів. Одного разу ви можете написати свій веб-інтерфейс у ASP.net MVC, свою бізнес-логіку на C #, свої основні алгоритми в F # та свої модульні тести в Ironruby .... Усе серед середовища .Net.

Послухайте радіо Software Engineering з Саймоном Пейтоном Джонсом, щоб отримати додаткову інформацію про Haskell: Episode 108: Simon Peyton Jones on Functional Programming and Haskell


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

5
Пряме посилання на се-радіо Епізод 108 (Саймон Пейтон Джонс): se-radio.net/podcast/2008-08/…
Геррман,

9
Ще одна особливість, на яку варто звернути увагу, - це те, що мова, яка забезпечує чисте програмування, у компілятора НАБАГАТО більше свободи для багатьох оптимізацій. Такі мови, як F #, які заохочують чистоту, але все ще дозволяють неперевіреним нечистим операціям залишатись у кожному блоці коду, втрачаючи деякі потенційні оптимізації, оскільки компілятор змушений вважати, що кожен виклик містить необхідні побічні ефекти.
Бен,

12
@JonHarrop: Це твердження про алгоритми, яке не пов'язане із застосовністю оптимізацій компілятора. Мови примусової чистоти, як правило, дозволяють писати явно нечистий код, якщо вам це дійсно потрібно (якщо нічого іншого, використовуючи FFI для виклику C). Компілятор може застосовувати перетворення коду більш вільно, коли він не зобов'язаний зберігати порядок (невідомих) побічних ефектів. У мовах "заохочуваної чистоти" ви пишете здебільшого подібний код, тому застосовуються ті самі оптимізації, лише вони можуть призвести до втрати побічних ефектів (яких немає, але компілятор не може цього припустити).
Бен,

3
@JonHarrop Коли я стверджував, що всі вони є алгоритмами? У будь-якому випадку ми порівнюємо Haskell та F #, а не Haskell та C. F # - це мова "заохочуваної чистоти", тому ви часто пишете чистий код. Все, що я стверджую, полягає в тому, що точно такий самий код часто може бути оптимізований компілятором у налаштуваннях "примусової чистоти", оскільки компілятор F # повинен вважати, що дзвінки мають побічні ефекти. Ви говорите про переписування коду для використання іншого алгоритму (який залежить від побічних ефектів); Я беру про "оптимізацію" чистого коду у F # проти Haskell.
Бен,

53

Великі відмінності:

  • Платформа
  • Об'єктна орієнтація
  • Лінощі

Подібність важливіша за різницю. В основному, вам слід використовувати F #, якщо ви вже в .NET, а Haskell - інакше. Крім того, ОО та лінощі означають, що F # ближче до того, що ви (мабуть) вже знаєте, тому, мабуть, легше навчитися.

Платформа: Haskell має власну середовище виконання, F # використовує .NET. Я не знаю, яка різниця в продуктивності, хоча я підозрюю, що середній код приблизно такий самий до оптимізації. F # має перевагу, якщо вам потрібні бібліотеки .NET.

Орієнтація на об'єкт: F # має OO і дуже обережно переконуєсь, що класи .NET прості у використанні, навіть якщо ваш код не OO. У Haskell є класи типів, які дозволяють робити щось на зразок OO, дивним чином. Вони схожі на рубінові міксини, схрещені із загальними функціями Common Lisp. Вони трохи схожі на інтерфейси Java / C #.

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

Незначні відмінності:

  • Синтаксис: Haskell має дещо приємніший синтаксис, на мій погляд. Це трохи стисліше і регулярніше, і мені подобається оголошувати типи в окремому рядку. YMMV.
  • Інструменти: F # має чудову інтеграцію Visual Studio, якщо вам подобаються подібні речі. Haskell також має старий плагін Visual Studio , але я не думаю, що він коли-небудь вийшов із бета-версії. Haskell має простий режим emacs, і ви, ймовірно, можете використовувати tuareg-режим OCaml для редагування F #.
  • Побічні ефекти: Обидві мови роблять це досить очевидним, коли ви мутуєте змінні. Але компілятор Haskell також змушує вас позначати побічні ефекти щоразу, коли ви їх використовуєте. Практична відмінність полягає в тому, що ви повинні бути набагато більш обізнаними, коли також використовуєте бібліотеки з побічними ефектами.

1
дивись на продуктивність . Не впевнений, наскільки це законно
nawfal

35

F # є частиною сімейства мов ML і дуже близький до OCaml. Можливо, ви захочете прочитати цю дискусію про відмінності між Haskell та OCaml .


6
Хоча це посилання може відповісти на питання, краще включити сюди основні частини відповіді та надати посилання для довідки. Відповіді лише на посилання можуть стати недійсними, якщо пов’язана сторінка зміниться. - З огляду
mirabilos

33

Основною відмінністю, яка, мабуть, є результатом чистоти, але я менш бачу згадуваного, є поширене використання монад. Як часто зазначається, монади можна будувати майже будь-якою мовою, але життя сильно змінюється, коли вони широко використовуються в бібліотеках, і ти використовуєш їх сам.

Монади надають щось набагато обмеженіше в інших мовах: абстракція управління потоком. Вони є неймовірно корисними та елегантними способами робити всілякі речі, і рік Haskell повністю змінив спосіб програмування, так само, як перехід від імперативного до програмування ОО багато років тому змінив його, або, набагато пізніше, використовуючи функції вищого порядку.

На жаль, у такому просторі немає можливості надати достатньо розуміння, щоб зрозуміти, в чому різниця. Насправді, жодна письмова робота цього не зробить; Вам просто потрібно витратити достатньо часу на вивчення та написання коду, щоб отримати реальне розуміння.

Крім того, F # іноді може стати дещо менш функціональним або більш незграбним (з точки зору функціонального програмування), коли ви взаємодієте з платформою .NET / бібліотеками, оскільки бібліотеки, очевидно, були розроблені з точки зору OO.

Отже, ви можете розглянути своє рішення таким чином: ви хочете спробувати одну з цих мов, щоб отримати швидкий, відносно невеликий крок вдосконалення, або ви готові витратити більше часу і отримати менш негайну вигоду для чогось більшого в довгостроковій перспективі. (Або, принаймні, якщо у вас не виходить чогось більшого, легка можливість швидко переключитися на інше?) Якщо перший, F # - це ваш вибір, якщо другий - Хаскелл.

Пара інших непов'язаних моментів:

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

Що стосується платформ, F #, звичайно, .NET; наскільки добре це буде працювати на Mono, я не знаю. GHC компілюється в машинний код із власним середовищем виконання, добре працює як під Windows, так і під Unix, який порівнює з .NET так само, як це, скажімо, робить C ++. Це може бути перевагою за деяких обставин, особливо з точки зору швидкості та нижчого рівня доступу до машини. (Наприклад, у мене не виникло проблем із написанням сервера DDE у Haskell / GHC; я не думаю, що ви могли б це робити будь-якою мовою .NET, і, незважаючи на це, MS, безумовно, не хоче, щоб ви це робили.)


2

Ну, для одного я б сказав, що основною перевагою є те, що F # компілюється проти платформи .NET, що полегшує його розгортання на Windows. Я бачив приклади, які пояснювали використання F # у поєднанні з ASP.NET для створення веб-додатків ;-)

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

Наразі для F # я бачив лише одну реальну реалізацію, яка є доказом особливості концептуальної ОС. Я бачив більше реальних реалізацій Haskell.


4
F # вже мав кілька основних історій успіху (Halo 3, AdCenter, F # для візуалізації), які перекривають найближче, що Haskell має до історії успіху (Darcs).
JD

Варто зазначити, що у цього, звичайно, є мінус. (Обмеження CLR)
MasterMastic
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.