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

Протягом усього минулого року мені писали код Scala (походить з фону Java). Мені дуже сподобалось, як можна створити простіший і чистіший код, використовуючи вали, класи регістрів, функції карти / фільтра / лямбда, імпліцити та умови виводу. Я використовував його здебільшого для програми на базі Akka .

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

Незважаючи на це, з моєї точки зору, весь цей синтаксис дійсно перешкоджає діловій логіці. Наприклад, тип "MyBusinessObject" є прекрасним, а також такі типи, як "Список [MyBusinessObject]", "Option [MyBusinessObject]" або навіть "Future [MyBusinessObject]". Всі вони мають чітке значення та призначення. З іншого боку, код:

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

чи додає це складності програмі, чи просто я не звик до такого способу програмування?

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

Не зрозумійте мене неправильно, я не рекомендую уникати розширених особливостей мови, але важливо знайти правильний баланс у заданому контексті. Коли ви пишете загальну бібліотеку для використання> 100 000 розробників у всьому світі, застосовуються різні заходи, як коли ви пишете індивідуальний генератор звітів лише для вашого місцевого офісу.

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

Щодо того, чи додає цей конкретний код складність програмі - я не знаю. Домовились, що загальний фрагмент коду може бути складним сам по собі. Але це утиліта, а не частина логіки бізнесу. Якщо ви хочете знати, чи робить це базу коду більш складною чи простою, вам доведеться уявити, як вона повинна виглядати без цього фрагмента коду. Часто буває з такими загальними конструкціями, що вони самі складні, але це складність, яку можна помістити на одному екрані. У той же час вони роблять всю кодову базу трохи простішою. Особливо це стосується монад.

Знову ж таки, це також може бути випадком "мистецтва заради мистецтва", як пропонує @Doc Brown. Не можу це виключити.

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

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

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

Крім того, Scala, як функціональна мова програмування, має деякі недоліки (частково через те, що у JVM є недоліки), що змусило авторів Scalaz писати гірші коди в деяких випадках. Наприклад, відсутність загального усунення хвостових викликів змушує використовувати батути в деякому коді, а відсутність "доброї системи" може ускладнити підписи типів.

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

Тримайся там. І це може допомогти.

Чи додає це складності програмі, чи просто ви не звикли до такого способу програмування?

Чому, на вашу думку, ці можливості не одне й те саме?

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

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