История изменений

А чего именно не хватает в функциональщине, кроме наследования реализации?

Простоты. Если совсем утрировать в теории, то создал ты некоторый объект, скажем car, который где-то в своих недрах скрывает геометрию, текстуры (ты их даже не видишь, они тебе не нужны на верхнем уровне абстракции, чтобы, скажем, гонять разные машинки по дороге), методы для перемещения и т.д.. В результате если у тебя нет скриптового движка (по идее его и писать будет проще) который гоняет все машинки по дороге, то ты легко можешь поглядеть и на структуру твоей машинки (по методам) и более-менее просто ее создать, задав какие-то параметры, вроде скорости, ускорения, 3D модельки в конструкторе. Ты не сможешь забыть о чем-то если всё грамотно сделано.

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

Ах да, самое плохое в том, что та же инкапсуляция через модули или ещё как-то неявным и ненаглядным образом похожа на удаление гланд через жопу. Т.е. подход ООП к функциональному программированию плох. Не надо делать из функциональщины ООП, когда есть сам ООП. А значит пользоваться им надо иначе. Думать о машине, как об объекте плохо, это пахнет изобретением ООП, прямо как в Glib.

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

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

Конечно, я не функциональный программист и смотрю на вашу тусу несколько издалека и могу ошибаться по поводу ряда пунктов. Единственный ЯП на котором я иногда пишу в этом виде — Python, но он не совсем функциональный, а скорее с элементами.

А чего именно не хватает в функциональщине, кроме наследования реализации?

Простоты. Если совсем утрировать в теории, то создал ты некоторый объект, скажем car, который где-то в своих недрах скрывает геометрию, текстуры (ты их даже не видишь, они тебе не нужны на верхнем уровне абстракции, чтобы, скажем, гонять разные машинки по дороге), методы для перемещения и т.д.. В результате если у тебя нет скриптового движка (по идее его и писать будет проще) который гоняет все машинки по дороге, то ты легко можешь поглядеть и на структуру твоей машинки (по методам) и более-менее просто ее создать, задав какие-то параметры, вроде скорости, ускорения, 3D модельки в конструкторе. Ты не сможешь забыть о чем-то если всё грамотно сделано.

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

Ах да, самое плохое в том, что та же инкапсуляция через модули или ещё как-то неявным и ненаглядным образом похожа на удаление гланд через жопу. Т.е. подход ООП к функциональному программированию плох. Не надо делать из функциональщины ООП, когда есть сам ООП. А значит пользоваться им надо иначе. Думать о машине, как об объекте плохо, это пахнет изобретением ООП, прямо как в Glib.

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

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

Конечно, я не функциональный программист и смотрю на вашу тусу несколько издалека и могу ошибаться по поводу ряда пунктов. Единственный ЯП на котором я иногда пишу в этом виде — Python.