Англійська для розробників Haskell

Сильна система типів та лінійна модель оцінки Haskella створюють словник, який точний, але легко зловживати в розмові — «клас типів», «монада» і «строгость» означають щось конкретне. Цей підручник містить інформацію про англійську мову, яку використовують під час обговорення коду Haskell з командою.

Ключовий словник

** Клас типу ** — інтерфейс, що описує набір операцій, які тип має підтримувати ( Eq, Functor, Monad ), що дозволяє писати поліморфний код проти інтерфейсу, а не конкретного типу. “Замість написання трьох майже ідентичних функцій для цих типів, визначте клас типу, що захоплює спільну поведінку, і напишіть одну функцію проти нього.”

** Monad ** — клас типів, що захоплює шаблон для послідовних обчислень, які мають певний контекст (несправність, стан, введення/ виведення), дозволяючи автоматичне виконання потоків у цьому контексті замість виконання потоків вручну. “Опаковування цього в монаді Maybe означає, що нам не потрібні явні нульові перевірки на кожному кроці — коротке замикання на Nothing відбувається для нас.”

** Leziness ** — типова стратегія оцінки Haskell, за якою вирази не обчислюються до тих пір, поки їх результат не буде дійсно потрібним, що дозволяє створювати нескінченні структури, але також спричиняє витік простору, якщо використовувати його неправильно. “Цей аккумулятор створює величезний ланцюг неоцінених дій — вимагайте строгого оцінювання з foldl' замість лінивого foldl, або ми розірвемо купу на великих вхідних даних.”

** Виведення типів ** — здатність компілятора виводити тип значення з контексту без явної анотації, при цьому все ще забезпечуючи повну безпеку статичного типу.

• “Вам не потрібно анонсувати кожне проміжне прив’ язування — дозвольте виведенню типів обробляти це, і додавайте лише явні підписи у функціях верхнього рівня для документації.” *

** Чиста функція / межа побічних ефектів ** - строге розділення, яке Haskell накладає між чистими обчисленнями і ефективним кодом, з ефектами, які відстежуються явно в підписі типу (зазвичай через IO ). “Якщо тип цієї функції не згадує IO, компілятор гарантує, що вона не має побічних ефектів — це набагато сильніша гарантія, ніж коментар, що обіцяє те ж саме.”

Алгебраїчний тип даних (ADT) — тип, побудований за допомогою поєднання інших типів з сумою (або/або) і добутку (і) складу, зазвичай визначається data і повністю збігається з шаблоном. “Модельуйте це як ADT з одним конструктором на стан замість структури з декількома додатковими полями — тоді компілятор зможе змусити нас обробляти кожен випадок.”

Звичайні фрази

• Чи дійсно цей клас типів повинен бути таким загальним, чи буде конкретна функція яснішою?»
• Чи буде цей ланцюг дій вимагати всіх зразу і розірвати стек, чи буде він споживатися поступово?»
• Чи варто нам додати явний підпис типу тут для документації, навіть якщо виведення працює?»
• Чи підпис типу відображає, що ця функція чиста, або ж десь ховає ефект?»
• Чи зробить ADT з явними конструкторами ці недійсні стани невідображуваними?»

Приклади висловлювань

Перегляд запиту на звантаження: “Сигнатура цієї функції говорить, що вона чиста, але вона викликає unsafePerformIO внутрішньо — це підриває всю гарантію, яку система типів повинна нам дати.”

Пояснення рішення про проектування: “Ми моделювали стан запиту як ADT з одним конструктором на стадію замість запису з декількома полями Maybe, тому неправильні комбінації просто не можуть бути побудовані.”

Опис події: “Вибух пам’яті стався через лінивість foldl, який побудував величезний неоцінений ланцюг думок замість того, щоб скоротити список, як це було — переключення на foldl' виправило це.”

Професійні поради

• Скажіть “непредставлений”, коли ви пропонуєте сильніший ADT — це точне скорочення, яке розробники Haskell використовують для проектів, які роблять недійсні стани неможливими для побудови.
• Розрізняйте “строгий” від “лінивий” явно, коли обговорюєте продуктивність — нечітка мова, наприклад, “це повільно” приховує, яка стратегія оцінки насправді є помилкою.
• Використовуйте “типовий підпис гарантує…” замість “Я думаю, що це чисто” — це відображає, наскільки сильно розробники Haskell спираються на систему типів як документацію.
• Прапор ** unsafePerformIO ** за назвою у перегляді — це добре відома люкова помилка, яка заслуговує на уважнішу увагу, а не на прохідний коментар.

Практичні вправи

1. Поясніть двома реченнями, чому ледь не вся лінивість може призвести до витоку простору у наївному складі.
2. Написати коментар перегляду коду у одному реченні, який ставить під сумнів чистоту функції.
3. Опишемо вашими словами, які переваги дає вам алгебраїчний тип даних у порівнянні з записом з декількома необмеженим полями.

На практиці: Навігація нюансів — фокус на не-рідних мовців

Для багатьох розробників, які вивчають професійну англійську, початковою перешкодою є не тільки розуміння окремих слів; це розуміння того, як ці слова використовуються в певному контексті, особливо в технічних контекстах. Haskell, з його акцентом на чистоту і незмінність, вже представляє унікальний набір концепцій, і ефективне їх поширення англійською мовою вимагає точності і обізнаності про поширені фрази. Недостатньо просто перекласти терміни; вам потрібно зрозуміти * чому * вони використовуються в певний спосіб. Розглянемо, наприклад, коментар перегляду коду, який виглядає так: « Ця функція могла б отримати користь від більш явного підпису типу. Хоча виведення типів в Hasskell є потужним, додавання :: прояснює призначене використання і зменшує потенційну неоднозначність. ” Ключ тут не тільки в тому, щоб знати, що робить :: – це розуміння * чому * рецензент пропонує це; для того, щоб сприяти ясності і запобігти майбутнім непорозумінням. Аналогічно, повідомлення Slack, що обговорює складну реалізацію монади, може виглядати так: «Я борюся з природою стану цього MaybeT екземпляра. Чи може хтось пояснити, як функція modify взаємодіє з монадним контекстом?» — формулювання тут визнає справжню труднощі — «боротьба» — і оформляє її як запит на пояснення, а не критику.

Інша поширена область плутанини виникає при обговоренні лінійності і стратегій оцінки. Фрази на кшталт «оцінити охоче» проти «оцінити лінько» є не тільки технічними термінами; вони мають значні наслідки для продуктивності і використання ресурсів. Опис PR може мати такий вигляд: « Перероблено конвеєр обробки даних, щоб використовувати ліниве оцінювання, зменшуючи проміжні обчислення і покращуючи загальну пропускну здатність ». Зауважте, що у цій фразі йдеться про « переваги » лінького обчислення — « зменшення проміжних обчислень », а не просто про те, що воно « ліньке ». Крім того, під час обговорення класів типів, звертайте увагу на мову, яку використовується. Ви можете сказати « Ця функція не реалізує клас типу Eq », але більш професійним підходом буде сказати: « У даній функції на даний момент відсутня реалізація класу типу Eq, що перешкоджає безпосередньому порівнянню з іншими значеннями ». Невеликі зміни у формулюванні можуть суттєво змінити сприйняття вашої роботи і розуміння вами її змісту.

Нарешті, пам’ ятайте, що коротка і точна мова часто є кращою. Уникайте надто довгих пояснень, якщо існує простіша альтернатива. Сфокусуйтеся на тому, щоб передати * що * потрібно зробити, а не * як * це робиться - якщо тільки не запитати про деталі. Метою завжди є чітке спілкування, незалежно від вашої рідної мови. Це вимагає активного слухання і пошуку пояснень, коли ви не впевнені в тому, що стосується наміченого значення або нюансів.

Ось приклад використання ghc для перевірки зкомпільованого модуля:

ghc -version

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