Чи є система типу Haskell перешкодою для розуміння функціонального програмування? [зачинено]

33

Я вивчаю Haskell з метою розуміння функціонального програмування, сподіваючись, що я застосую розуміння, яке я здобуваю в інших мовах (в основному Groovy, Python, JavaScript.)

Я вибрав Haskell, тому що у мене склалося враження, що він дуже чисто функціональний і не допускає ніякої опори на державу.

Я не вирішив вивчити Haskell, тому що мені було цікаво орієнтуватися на надзвичайно жорстку систему типу.

Моє запитання таке: чи є система сильного типу необхідним побічним продуктом надзвичайно чистої функціональної мови, чи це не пов'язаний вибір дизайну з Haskell?

— Ерік Вілсон
джерело

6

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

— Анон.

4

@ Так, але ваші списки повинні бути однорідними. Повірте, такі речі можуть заважати навіть при виведенні типу.

— Ерік Вілсон

13

@FarmBoy, а що не так із використанням Можливо? Java справді змушує вас використовувати Можливо на всіх заняттях, що дивно робити.

— альтернатива

3

І якщо ви дійсно хочете використовувати неоднорідний список, ви, звичайно, можете використовувати алгебраїчні типи даних.

— альтернатива

1

@mathepic на даний момент ми справді втратили моє оригінальне запитання, яке було цілком коректним питанням.

— Ерік Вілсон

40

Я вважаю, що розуміння типу типів Haskell є підсилювачем розуміння функціонального програмування.

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

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

Якби Хаскелл не був набраний сильно, такі поняття, як монади, додаткові функціонери тощо, ніколи не застосовувалися б до програмування.

— Вакуо
джерело

2

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

— Негайно

2

Я знаю, що це дуже стара відповідь, але я насправді не згоден. Я думаю, що настільки явні, як деякі речі є в мові, система типів, особливо з монадами, такими як State та Parsec, підкидає ТОН речі під килим. Це насправді дуже сильно заважає моїй здатності вивчати бібліотеки мови.

— Саванні Д’Герінель

4

@ SavanniD'Gerinel: Я думаю, що в цій відповіді "засунути речі під килим" не означає додавати неявну функціональність (що Haskell робить контрольованим способом, наприклад, через монади, і що допомагає зменшити котельну плиту), а навпаки дозволяють деякий фрагмент коду робити щось, чого не передбачається робити. Напр .: чиста функція в Haskell ніколи не матиме побічних ефектів. Період. У багатьох інших мовах ви можете пообіцяти це в документації до функції, але ніщо на вашій мові не заважатиме вам забивати якісь побічні ефекти десь у вашому коді.

— Джорджіо

33

Найбільш динамічно набраною функціональною мовою, можливо, є схема. Однак, система типу Haskell є показником її чистоти. Це питання "як можна виміряти чистоту?". Система типу Haskell дозволяє легко обмежувати нечисті дії IO. Для цього вам потрібна система статичного типу.

Але скажімо, система типу Haskell не має нічого спільного з функціональним програмуванням. Все ще було б на висоті голосу стверджувати, що система типу не допоможе вам у цьому навчальному процесі. Система типів Haskell багата і складна, і тим більше цікава в порівнянні з типовими системами C ++ і OCaml.

Це перешкода? Ні, я думаю, що це надбання. Спробуйте подумати, як боротися з лінню Хаскелла, IOнаприклад.

— Логан Капальдо
джерело

8

+1 Система типу Haskell може стати вашим другом, як тільки ви звикнете до неї.

— Ларрі Коулман

"Для цього вам потрібна система статичного типу". Дійсно?

— Джон Харроп

1

"тим більше цікаво порівняно з типовими системами C ++ та OCaml". Ви вивчали першокласні модулі вищого порядку OCaml і структурно набирали об'єктну об'єктну систему та поліморфні варіанти?

— Джон Харроп

2

@JonHarrop або система ефектів або якийсь спосіб вимірювання / оцінки чистоти. Так, тому їх цікаво порівнювати. Різні варіанти для різних мов.

— Логан Капальдо,

20

Clojure є динамічно набраним і майже таким же чистим, як Haskell, тому є хороший аргумент, що система типу Haskell була скоріше вибором дизайну, ніж абсолютною вимогою. У обох, безумовно, є свої сильні моменти, тому ви можете розглянути Clojure, якщо вам дійсно не подобається жорсткість Haskell (але дивіться нижче).

Коли я вперше почав використовувати Haskell, я вважав систему типів дратівливою і допустив її лише через умовиводи типу. Я незабаром виявив, що багато помилок типу компілятор скаржився на речі, які б не працювали, навіть якби компілятор дозволив мені їх робити (наприклад, випадково використовуючи карту замість concatMap). Потім я виявив, що програми, які пройшли перевірку типу, зазвичай були правильними або принаймні близькими до правильних. У мене навіть була ледача фаза, коли я робив рефакторинг, змінюючи тип функції і дозволяючи компілятору сказати мені, що ще потрібно змінити. Нарешті я зрозумів, що система типів Haskell насправді дуже виразний, і почав проектувати мої програми навколо типів. Це святий Грааль Хаскелл.

— Ларрі Коулман
джерело

Ще одне, що слід зазначити: я вивчив функціональне програмування, використовуючи і схему, і Haskell приблизно в один і той же час (перший для класу, а другий для розваги). Я виявив, що розуміння рекурсії було набагато простіше з узгодженням картини Хаскелла, ніж зі ifсхемами s і conds в схемі, яку, як я думаю, також переносить на Clojure.

— Тихон Єлвіс

@Larry Coleman: +1 для опису саме мого власного досвіду роботи із системами типів: спочатку C ++, потім Ocaml, а тепер моя власна мова Felix. Так, я все ще рефактор, переслідуючи помилки компілятора.

— Іттріл

8

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

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

Система типу не повинна бути величезною перешкодою. Люди, які програмують, як правило, навіть користуючись динамічними мовами, дотримуються правил набору тексту, які можна закодувати за допомогою системи типу Haskell. Haskell також має тип виводу, який зменшує багатослівність у порівнянні з мовами, такими як C ++ та Java. Коли ви отримуєте повідомлення про помилку, компілятор лише повідомляє вам під час компіляції, що мова з динамічними типами сказала б вам під час виконання.

Протилежністю системи динамічного типу є система статичного типу, а не система сильного типу. Система сильного типу - це протилежність системі слабкого типу.

— dan_waterworth
джерело

1

Наприклад, C статично, але слабо набрано. У вас є типи, але легко підкорити типову систему повністю, пограти з базовими машинними уявленнями тощо. Багато динамічно набраних мов OTOH досить сильно набрані - мало неявних кастів, декілька способів (якщо такі є) підривати систему типів.

— Steve314

4

Це говорить вам одразу, коли ви робите німі помилки. Це корисно. Я працював у Ракетці (Схемі) в останній термін, і неодноразово я проходив нерозбірливий s-exp, де я очікував на синтаксичний розбір якоїсь функції в моєму перекладачі, і це виявилося лише в моєму середній розмір тестового набору. Якби у мене був якийсь статичний набір тексту, це було б відразу до мене до відома.

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

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

Чистота Haskell закодована в його системі типів. Монада IO - це конструкція на рівні типу, яка зупиняє нечистий код не протікати в чисті функції, тому чистота гарантується системою типів.

— Тео Белер
джерело

8

Якщо ви думаєте, що можете ігнорувати систему типів Haskell, то, я думаю, ви не кодували багато Haskell.

— Ерік Вілсон

Не ігноруйте настільки, скільки ігноруйте її, як наберіть функцію, завантажте її в GHCi та перейдіть: t на ній. Але вам все одно доведеться іноді посипати деякі функції інтеграла чи інші функції.

— Theo Belaire

1

Tyr, навіть при виведенні типів, 90% використання та кодування функцій Haskell отримує прокляті речі, щоб з'єднатися між собою, що вимагає розуміння його типу типів та таємних повідомлень про помилки під час перевірки типу. Навіть ": t" - це не магічне рішення, а лише перший крок до розуміння того, як зробити компіляцію програми.

— Андрес Ф.

Ну, деякі частини безладні, я згоден. Я дійсно думаю, що чисельний матеріал у прелюдії міг би бути виправленим та виправленим, бо, як це є, це жахливий безлад. Але більшість ключових функціональних аспектів досить чисті. карта, фільтр, foldr / l та інші цікаві функціональні функції працюють досить непогано.

— Тео Белаар

2

Будучи "функціональною" мовою, означає (крім інших речей), що функції є першокласними об'єктами в мові.

Бути "чистою" мовою означає, що функції - це математичні функції (на відміну від процедур) - якщо давати однаковий вхід, вони завжди дають однаковий вихід.

"Чиста функціональна мова" - це та, де обидва вищезазначені дотримуються. Я не знаю , про «pure- LY функціонального мови».

Система сильного типу - це один чистий спосіб володіти чистою, але практичною мовою. Типи допомагають компілятору розібратися в оптимізації, крім того, що надалі забезпечує правильність. (Але це не єдиний спосіб - кложур чистий, але не має такої міцної системи типу, як Haskell.)

Якщо система типів вас турбує, я б запропонував вам спробувати більш динамічну мову, як-от Схема, або обійтись використанням системи виводу типу Haskell.

— pyNem
джерело

0

Так, система типів - неймовірний актив. Було б дуже важко навіть описати, як працюють монади або як деякі комбінатори працюють без системи типу. Розглянемо, скільки навчальних посібників з Haskell спочатку просять розглянути тип відповідної функції з: t у відповіді. Це просто недоступно для вас динамічно набраною мовою. Звичайно, вся складність системи типів все ж є. Монада - це все ще монада. Але мова вирішила вимити свої справи і зовсім не надати допомоги. Ти сам, товариш. Я не стукаю динамічно набрані мови. Я люблю їх дорого. Схема - це електроінструмент par excellance. Але ви помітите, що коли ми говоримо про такі речі, як монади в динамічних мовах, ми часто вигадуємо позначеннядля опису типу процедур. Функціональний програміст буде битися з типами в той чи інший спосіб. Програма перевірки типу Haskell просто дає хороші інструменти, щоб навчитися це робити.

— Ара Вартанян
джерело