Как сторонники функционального программирования ответят на это утверждение в Code Complete?

На странице 839 второго издания Стив Макконнелл обсуждает все способы, с помощью которых программисты могут «преодолевать сложности» в больших программах. Его советы завершаются этим утверждением:

«Объектно-ориентированное программирование обеспечивает уровень абстракции, который применяется одновременно к алгоритмам и данным , своего рода абстракцию, которую не обеспечивала только функциональная декомпозиция».

В сочетании с его выводом о том, что «снижение сложности является, пожалуй, самым важным ключом к тому, чтобы быть эффективным программистом» (на той же странице), это кажется довольно сложной задачей для функционального программирования.

Дебаты между FP и OO часто устраиваются сторонниками FP по вопросам сложности, которые вытекают именно из задач параллелизма или распараллеливания. Но параллелизм - это, конечно, не единственный вид сложности, который нужно решать программистам. Возможно, сосредоточение внимания на уменьшении одного вида сложности значительно увеличивает его в других измерениях, так что во многих случаях выигрыш не стоит затрат.

Если бы мы сместили условия сравнения между FP и OO от конкретных вопросов, таких как параллелизм или повторное использование, к управлению глобальной сложностью, как бы выглядела эта дискуссия?

РЕДАКТИРОВАТЬ

Контраст, который я хотел подчеркнуть, заключается в том, что ОО, кажется, инкапсулирует и абстрагируется от сложности как данных, так и алгоритмов, тогда как функциональное программирование, кажется, поощряет, оставляя детали реализации структур данных более «открытыми» во всей программе.

Смотрите, например, Стюарт Халлоуэй (а Clojure FP поборник) здесь говорят , что «более-спецификация типов данных» является «негативным последствием идиоматического стиля ОО» и в пользу концептуализации в AddressBook как простой вектор или карты вместо богатого объекта OO с дополнительными (не векторными и не подобными карте) свойствами и методами. (Кроме того, сторонники OO и Domain-Driven Design могут сказать, что раскрытие адресной книги в виде вектора или карты приводит к чрезмерной экспозиции инкапсулированных данных с методами, которые не имеют значения или даже опасны с точки зрения домена).

Имейте в виду, что книга была написана более 20 лет назад. Для профессиональных программистов того времени FP не существовало - оно целиком принадлежало ученым и исследователям.

Нам нужно сформулировать «функциональную декомпозицию» в соответствующем контексте работы. Автор не имеет в виду функциональное программирование. Мы должны связать это со «структурированным программированием» и GOTOзаполненным беспорядком, который был до этого. Если ваша точка отсчета старая FORTRAN / COBOL / BASIC, в которой не было функций (возможно, если вам повезет, вы получите один уровень GOSUB), и все ваши переменные являются глобальными, то есть могут разбить вашу программу на слои функций является главным благом.

ООП является дальнейшим уточнением такого рода «функциональной декомпозиции». Вы можете не только объединять инструкции в функции, но и группировать связанные функции с данными, над которыми они работают. Результатом является четко определенный фрагмент кода, который вы можете посмотреть и понять (в идеале), не прибегая к поиску кода, чтобы выяснить, что еще может повлиять на ваши данные.

Я полагаю, что сторонники функционального программирования утверждают, что большинство языков FP предоставляют больше средств абстракции, чем «только функциональная декомпозиция», и фактически позволяют средства абстракций, сопоставимые по мощности с объектно-ориентированными языками. Например, можно привести классы типов Хаскелла или модули высшего порядка ML как такие средства абстракций. Таким образом, утверждение (которое, я уверен, касалось объектной ориентации или процедурного программирования, а не функционального программирования) к ним не относится.

Следует также отметить, что FP и OOP являются ортогональными понятиями и не являются взаимоисключающими. Поэтому не имеет смысла сравнивать их друг с другом. Вы можете очень хорошо сравнить «императивный ООП» (например, Java) с «функциональным ООП» (например, Scala), но приведенное вами утверждение не будет применяться к этому сравнению.

Я считаю, что функциональное программирование чрезвычайно полезно при управлении сложностью. Однако вы склонны думать о сложности по-другому, определяя ее как функции, которые действуют на неизменяемые данные на разных уровнях, а не на инкапсуляцию в смысле ООП.

Например, я недавно написал игру на Clojure, и все состояние игры было определено в единой неизменной структуре данных:

(def starting-game-state {:map ....
                          :player ....
                          :weather ....
                          :other-stuff ....}

И основной игровой цикл можно определить как применение некоторых чистых функций к игровому состоянию в цикле:

 (loop [initial-state starting-game-state]
   (let [user-input (get-user-input)
         game-state (update-game initial-state user-input)]
     (draw-screen game-state)
     (if-not (game-ended? game-state) (recur game-state))))

Ключевая функция называется update-game, которая выполняет этап моделирования с учетом предыдущего игрового состояния и некоторого пользовательского ввода и возвращает новое игровое состояние.

Так в чем же сложность? На мой взгляд, это было сделано довольно хорошо:

• Конечно, функция update-game выполняет много работы, но сама она создается путем составления других функций, поэтому сама по себе она довольно проста. После того, как вы пройдете несколько уровней, функции все еще будут довольно простыми, например, «добавить объект на плитку карты».
• Конечно, состояние игры - это большая структура данных. Но опять же, он просто создается путем составления структур данных более низкого уровня. Кроме того, это «чистые данные», а не встраивание каких-либо методов или определение класса (вы можете думать об этом как об очень эффективном неизменяемом объекте JSON, если хотите), поэтому здесь очень мало шаблонов.

ООП также может управлять сложностью посредством инкапсуляции, но если сравнить это с ООП, у функционала есть несколько очень больших преимуществ:

• Структура данных игрового состояния является неизменной, поэтому большую часть обработки можно легко выполнить параллельно. Например, совершенно безопасно иметь вызывающий отрисовку экран рисования в потоке, отличном от логики игры - они не могут влиять друг на друга или видеть несовместимое состояние. Это на удивление сложно с большим изменяемым графом объектов ......
• Вы можете сделать снимок состояния игры в любое время. Воспроизведение тривиально (благодаря постоянным структурам данных Clojure копии практически не занимают память, поскольку большая часть данных используется совместно). Вы также можете запустить update-game, чтобы «предсказать будущее», чтобы помочь AI, например, оценить различные ходы.
• Нигде мне не приходилось делать какие-либо сложные компромиссы, чтобы вписаться в парадигму ООП, такие как определение жесткой иерархии классов. В этом смысле функциональная структура данных ведет себя больше как гибкая система на основе прототипов.

Наконец, для людей, которые заинтересованы в более глубоком понимании того, как управлять сложностью в функциональных и ООП-языках, я настоятельно рекомендую видеоролик с основной речью Рича Хикки « Simple Made Easy» (снятый на технологической конференции Strange Loop ).

«Объектно-ориентированное программирование обеспечивает уровень абстракции, который применяется одновременно к алгоритмам и данным, своего рода абстракцию, которую не обеспечивала только функциональная декомпозиция».

Одной только функциональной декомпозиции недостаточно для создания какого-либо алгоритма или программы: вам также необходимо представлять данные. Я думаю, что приведенное выше утверждение неявно предполагает (или, по крайней мере, его можно понять так), что «данные» в функциональном случае имеют самый элементарный вид: просто списки символов и ничего больше. Программирование на таком языке, очевидно, не очень удобно. Однако многие, особенно новые и современные, функциональные (или мультипарадигмальные) языки, такие как Clojure, предлагают богатые структуры данных: не только списки, но и строки, векторы, карты и наборы, записи, структуры - и объекты! - с метаданными и полиморфизмом.

Огромный практический успех ОО абстракций вряд ли можно оспорить. Но это последнее слово? Как вы писали, проблемы параллелизма уже являются основной болью, и классический ОО вообще не содержит представления о параллелизме. В результате де-факто ОО-решения для работы с параллелизмом представляют собой просто наложенную клейкую ленту: работает, но легко облажается, отнимает значительное количество мозговых ресурсов от основной задачи и плохо масштабируется. Может быть, можно взять лучшее из многих миров. Вот что преследуют современные мультипарадигмальные языки.

Изменчивое состояние является корнем большинства сложностей и проблем, связанных с программированием и программным / системным проектированием.

ОО охватывает изменяемое состояние. FP не терпит изменчивого состояния.

И у ОО, и у ФП есть свои применения и приятные места. Выбирать мудро. И помните пословицу: «Закрытия - это объекты бедняков. Объекты - это замыкания бедняков».

Функциональное программирование может иметь объекты, но эти объекты имеют тенденцию быть неизменными. Чистые функции (функции без побочных эффектов) затем работают с этими структурами данных. Можно создавать неизменяемые объекты на объектно-ориентированных языках программирования, но они не были предназначены для этого, и это не то, как они обычно используются. Это затрудняет рассуждение об объектно-ориентированных программах.

Давайте рассмотрим очень простой пример. Допустим, Oracle решил, что Java Strings должен иметь обратный метод, и вы написали следующий код.

String x = "abc";
StringBuffer y = new StringBuffer(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString());

что оценивает последняя строка? Вам нужны специальные знания о классе String, чтобы знать, что это будет иметь значение false.

Что делать, если я сделал свой собственный класс WuHoString

String x = "abc";
WuHoString y = new WuHoString(x);
y.reverse();
x.reverse();
x.toString().equals(y.toString())

Невозможно знать, к чему относится последняя строка.

В стиле функционального программирования это будет написано так:

String x;
equals(toString(reverse(x)), toString(reverse(WuHoString(x))))

и это должно быть правдой.

Если одну функцию в одном из самых базовых классов так сложно рассуждать, то возникает вопрос: увеличилась или уменьшилась сложность представления об изменчивых объектах?

Очевидно, что есть все виды определений того, что представляет собой объектно-ориентированное и что значит быть функциональным и что значит иметь и то, и другое. Для меня вы можете иметь «стиль функционального программирования» на языках, в которых нет таких вещей, как функции первого класса, но для него созданы другие языки.

Я думаю, что в большинстве случаев классическая абстракция ООП не покрывает сложности параллелизма. Поэтому ООП (в своем первоначальном значении) не исключает FP, и поэтому мы видим такие вещи, как scala.

Ответ зависит от языка. Лисп, например, действительно правильно понимает, что код - это данные - алгоритмы, которые вы пишете, на самом деле являются просто списками Лиспа! Вы храните данные так же, как вы пишете программу. Эта абстракция одновременно проще и тщательнее, чем ООП, и позволяет вам делать действительно полезные вещи (посмотрите макросы).

У Haskell (и похожего языка, я думаю) есть совершенно другой ответ: алгебраические типы данных. Алгебраический тип данных похож на Cструктуру, но с большим количеством опций. Эти типы данных обеспечивают абстракцию, необходимую для моделирования данных; функции обеспечивают абстракцию, необходимую для моделирования алгоритмов. Классы типов и другие расширенные возможности обеспечивают еще более высокий уровень абстракции над обоими.

Например, я работаю над языком программирования под названием TPL для удовольствия. Алгебраические типы данных позволяют действительно легко представлять значения:

data TPLValue = Null
              | Number Integer
              | String String
              | List [TPLValue]
              | Function [TPLValue] TPLValue
              -- There's more in the real code...

Это очень наглядно говорит о том, что TPLValue (любое значение на моем языке) может быть Nullили Numberсо Integerзначением или даже Functionсо списком значений (параметров) и конечным значением (телом). ).

Затем я могу использовать классы типов для кодирования некоторых общих действий. Например, я мог бы сделать TPLValueи экземпляр, Showкоторый означает, что он может быть преобразован в строку.

Кроме того, я могу использовать свои собственные классы типов, когда мне нужно указать поведение определенных типов (включая те, которые я сам не реализовал). Например, у меня есть Extractableкласс типов, который позволяет мне написать функцию, которая принимает TPLValueи возвращает соответствующее нормальное значение. Таким образом, extractможно преобразовать a Numberв a Integerили a Stringв a, Stringесли Integerи Stringявляются экземплярами Extractable.

Наконец, основная логика моей программы заключается в нескольких функциях, таких как evalи apply. Это действительно ядро ​​- они берут TPLValues и превращают их в больше TPLValues, а также обрабатывают состояние и ошибки.

В целом, абстракции, которые я использую в своем коде на Haskell, на самом деле более мощные, чем те, которые я использовал бы в языке ООП.

Насколько я вижу, цитируемое предложение больше не имеет никакой юридической силы.

Современные ОО-языки не могут абстрагироваться от типов, тип которых не *, то есть типы с более высоким родом неизвестны. Их система типов не позволяет выразить идею «некоторого контейнера с элементами Int, который позволяет отобразить функцию над элементами».

Следовательно, эта основная функция, как Haskells

fmap :: Functor f => (a -> b) -> f a -> f b 

не может быть легко написано на Java *), например, по крайней мере, не безопасным способом. Следовательно, чтобы получить базовую функциональность, вы должны написать множество шаблонов, потому что вам нужно

1. метод применения простой функции к элементам списка
2. метод для применения одной и той же простой функции к элементам массива
3. метод для применения той же простой функции к значениям хеша,
4. .... поставил
5. .... дерево
6. ... 10. модульные тесты для того же

И, тем не менее, эти пять методов в основном представляют собой один и тот же код, один или несколько. Напротив, в Хаскеле мне понадобится:

1. Экземпляр Functor для списка, массива, карты, множества и дерева (в основном предопределенный или может быть автоматически получен компилятором)
2. простая функция

Обратите внимание, что это не изменится в Java 8 (просто можно проще применять функции, но тогда точно возникнет описанная выше проблема. Пока у вас даже нет функций более высокого порядка, вы, скорее всего, даже не в состоянии понять, для чего хороши более высокие типы.)

Даже новые ОО-языки, такие как Цейлон, не имеют более высокодобренных типов. (В последнее время я спрашивал Гэвина Кинга, и он сказал мне, что это сейчас не важно.) Не знаю, как насчет Котлина.

*) Если честно, у вас может быть интерфейс Functor с методом fmap. Плохо то, что вы не можете сказать: эй, я знаю, как реализовать fmap для библиотечного класса SuperConcurrentBlockedDoublyLinkedDequeHasMap, дорогой компилятор, пожалуйста, примите, что с этого момента все SuperConcurrentBlockedDoublyLinkedDequeHasMaps являются функторами.

Любой, кто когда-либо программировал в dBase, знал, насколько полезны однострочные макросы для создания кода многократного использования. Хотя я не программировал на Лиспе, я читал от многих других, которые клянутся макросами времени компиляции. Идея внедрения кода в ваш код во время компиляции используется в простой форме в каждой C-программе с директивой include. Поскольку Лисп может сделать это с помощью программы на Лиспе, а Лисп обладает высокой отражающей способностью, вы получаете гораздо более гибкие включения.

Любой программист, который просто взял бы произвольную текстовую строку из Интернета и передал ее в свою базу данных, не является программистом. Точно так же любой, кто позволил бы «пользовательским» данным автоматически становиться исполняемым кодом, явно глуп. Это не означает, что позволить программам манипулировать данными во время выполнения, а затем выполнять их как код - плохая идея. Я полагаю, что эта техника будет незаменимой в будущем, когда в большинстве программ будет «умный» код. Вся «проблема с данными / кодом» или нет - это вопрос безопасности на языке.

Одна из проблем большинства языков заключается в том, что они созданы для того, чтобы один человек в автономном режиме мог выполнять некоторые функции для себя. Реальные программы требуют, чтобы у многих людей был доступ в любое время и одновременно с нескольких ядер и нескольких компьютерных кластеров. Безопасность должна быть частью языка, а не операционной системы, и в недалеком будущем это будет.