Почему haskell не взлетел в проде?

Вполне себе используется. Например, в Тинькове D:

Под не взлетел ты имеешь в виду то что нет джуновакансий?

Так-т если хаскел хорошо умеешь – с руками оторвут

Прям мой опыт Data flow programming (комментарий)

про ФП рассказывается. Так сладко рассказывает, а по факту оно не используется в проде

Может, поэтому? Вернее используется, но спрос на ФП много меньше, чем на «обычный» кодинг. Функции высшего порядка в «попсовых» ЯП не в счёт.

Потому что большая часть проблем, которые решает Haskell, возникает не из-за инструментов, а из-за прокладки между стулом и клавиатурой.

Поэтому эффективнее обкладывать разработку дополнительными инструментами, позволяющими снижать требования к разработчикам, чем давать им микроскоп, которым они раздолбают продукт.

Сейчас все хотят нанять 100500 программистов и менять раз в пару месяцев. С хаскелем 100500 программистов не найти, а заменить одного будет почти самоубийством

У тебя вопрос, почему в рекламе товара его хвалят, или в чем смысл ОП? И с каким «продом» имеешь дело ты сам, чтобы утверждать отсутствие там хачкеля?

Так сладко рассказывает, а по факту оно не используется в проде

ФП вообще в целом не взлетело в проде, не только поцкель.

Значит оно не так хорошо, как о нём поют?

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

Потому что ты его туда не присунул. Я вот присунул, у меня взлетел. Вывод: главное в жизни – уметь присовывать.

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

Программисты (IT-шники вообще) считают себя самыми умными, но это точно не так.

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

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

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

оопота хоть и взлетела, там все очень не сладко на деле

Что там не так, если отбросить кривые реализации из 90-х подкостыленные для 21 века, чтобы уж совсем не рукалицо?

а по факту оно не используется в проде

По факту мы живём не в мире розовых пони и здесь нужно писать ПО под конкретный процессор, даже джава разрабы наконец это поняли. А Спольский еще в начале нулевых писал о дырявых абстракциях. Поэтому «сладкие» ЯП сегодня не взлетят, только хардкор в эпоху застопорившегося железного прогресса.

Ты не тот прод смотришь.

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

Инкапсуляции не существует (рефлексия)

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

наследование жуткое месиво

Опять же не умение в ООП, в SDK всех популярных ЯП это есть. Но можно понять, тогда ни у кого не было опыта. И сейчас нет современного ЯП с ООП, учитывающий пласт накопившегося опыта за последние 20 лет. Либо поделки от хипстеров, либо корпоративные недоязычки для безмозглых олимпиадников, даже в ржавом не осилили ООП (но там вообще горе от ума).

когда объекты пытаются между собой общаться

Что там страшного? Делай сообщения иммутабельными и всё будет ок. Другой вопрос, что легаси ЯП это не предусмотрели в изначальной архитектуре и пытаются закрыть проблему костылями.

Опять же не умение в ООП, в SDK всех популярных ЯП это есть.

про это все и говорят. Вон emorozov отлично все изложил. Языки то прекрасные, но увы, большинство людей – рукожопы, многие 2+2 посчитают с ошибкой на калькуляторе.

Поэтому и взлетают решения попроще, а не получше. Потому что сложнее выстрелить себе в ногу, проще поддерживать, проще заменить одного программиста на другого.

почему взлетел го? Потому что в го для вебни есть все либы «из коробки» и потому что 10 программистов один и тот же кусок кода напишут идентично, потому что по другому го не даст это написать

Там FizzBuzzEnterprise

Рефлексия это либо начинающий разраб не умеющий в грамотное приготовление ООП

А кто умеет? Я что-то спрашиваю, так все говорят, «вот разраб не умеет», а когда просишь показать, так никто ничего показать не может.

Инкапсуляции не существует (рефлексия)

Я как спринг начал ковырять, так понял, что всё, на этом их ооп ничего сделать нельзя. Рефлексия там корявая и тормозная, но без неё будешь копипастить и кодогенить. То, что в продакшоне распространена такая вещь как loombok уже говорит о том, что «классическое ООП», на которое обычно наяривают ставя всем в пример - просто гальванизированный труп.

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

Просто на JS или Python или Java, эти люди соберут все грабли, расстреляют себе все ноги, но в итоге сделают работающий продукт. Под капот лучше не заглядывать (благо, в индустрии программ и вебсайтов это норма), потому что волосы встанут дыбом.

Да, спустя месяцы появляется кое-как работающий продукт, соответствующий требованиям. Любое изменение, правда, требует месяцев, потому что приходится рыться в тоннах дурно пахнущего copy paste, использующего 5% от возможностей языка (потому что кто дочитывает хотя бы tutorial по языку до конца? написал Hello, world - считай уже миддл, а то и сеньор). Каждое следующее изменение становится делать всё тяжелее. Никто код не понимает, тем более, что написавший «сеньор» давно свалил в другую компанию на x2 зарплату, наговнокодил там, и уже в третьей на x4 зарплате.

А на Haskell всё бы разбилось сразу же на том, что эти люди месяцы просидели бы, и сказали бы: «У нас ничего не получается» или «Этот Haskell - говно, надо писать на крутом и удобном PHP или JS, за ними будущее!»

Всё правильно. ООП не состоялось и нынче считается ошибкой природы. В принципе те, кто работал в нулевых/десятых знают, что ООП существовало _только_ в вопросах на собеседованиях. В проде был ад и израиль.

Ну тут видишь, теоретические столпы ООП врезаются в реальность и рушатся. Теория-то классная, я ее в вузе изучал и она мне нравилась. До того как увидел продакшен код.

Так проблема-то не в ООП, а в неумении применять. И это не только к ООП относится.

Я вот только вчера увидел код на Пыхтоне, который в 9 строк форматирует число с пробелом в качестве разделителя разрядов. И этот код скопипасчен в 5-6 других мест. То, что можно сделать одной строкой, если почитать доку по основам Пыхтона.

И, например, люди концентрируются на какой-то байде. Например, если в коде на Пыхтоне вижу попытки в «приватные» переменные (self.__variable), то 100% дальше будет адский говнокод. Потому что книги рассказывают, что один из столпов ООП — это «инкапсуляция». А на деле, она вообще ни на что не влияет, особенно в скриптовых языках, гораздо больше на поддерживаемость и читаемость влияет общая архитектура, которую нельзя так просто изучить и применять, как расставлять всюду private или __, чувствуя себя гением ООП. «Инкапсуляция - это же хорошо? Хорошо, каждая книжка так пишет. Поэтому всюду расставлю private, и получу хороший код автоматом!»

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

Проблема в том, что напрочь отсутствует понимание как и когда это применять, чтобы получать хороший код. Этому уже нельзя научиться заучиванием определений и расстановкой «правильных» ключевых слов типа «private». Для этого нужно много практики и талант, и время, и черт знает что ещё…

Так проблема-то не в ООП, а в неумении применять.

Я про это уже 10 лет слушаю, но что-то не видно, чтобы у кого-то было умение применять. Загнать в угол ООПшника - это как нечего делать. А если там будет присутствовать второй оопэшник он начнется сраться с первым. А если 3-й, то с остальными двумя. И каждый будет говорить разное.

Загнать в угол ООПшника - это как нечего делать. А если там будет присутствовать второй оопэшник он начнется сраться с первым. А если 3-й, то с остальными двумя. И каждый будет говорить разное.

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

Хуже всего, что люди (и я, наверное, в том числе) даже не пытаемся освоить полностью те инструменты, которыми пользуемся. Например, дочитать до конца доку по языку программирования, которым пользуемся. Дочитать доку по bash, sed, awk, grep, и прочим повседневным утилитам.

И отчасти всё ужасно-корявое из-за того, что все нахватались по верхам, и хреначат используя самые примитивные подходы… Типа, зная цикл for, но не зная while.

хреначат используя самые примитивные подходы

Как глаголил Аристотель «природа во всех своих проявлениях избирает кратчайший или легчайший путь» ©.
Вследствие чего мысли и деяния человеков формируют «монады с ленивыми вычислениями», а не «функционально-непорочные λ-ангелы» :)

Нет. Проблема в принципиальной неприменимости этой чепухи на практике. Как коммунизм. Понимаешь? На картинке все норм, на практике мы видели как оно.

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

Я на самом деле очень рад, что крупные игроки рынка стряхнули налет идиотизма с себя и начали делать ЯП без поддержки ООП.

А кто умеет?

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

К тому же ООП в практическом плане очень молод, серьёзно применять его стали вначале нулевых, а раньше не до жиру было. А понимание как нужно делать в последние лет 10 стало приходить. Поэтому нет у людей опыта. Нет известных проектов на которых можно учиться.

Так я и говорю, что люди просто заучивают термины и определения не понимая, как использовать их на практике.

Есть люди, которые назубок знают определения SOLID, и оттарабанят их на собесе, но сами пишут код, который регулярно нарушает правила SOLID.

А надо ли нам чистое ФП за пределами домена? Оно же за его пределами и чистым не будет.

Так или иначе элементы ФП сейчас в каждом втором ЯП, а большего нам и не надо.

Но циклы можно делать и так и так, а ооп как не сделай все будет плохо.

Не знаю

Вот и я тоже не знаю. И походу никто не знает.

Вообще, по своему опыту нужно много рефакторить, чтобы приблизиться к хорошему ООП

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

К тому же ООП в практическом плане очень молод

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

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

Философия ООП:

• программа состоит из множества объектов
• каждый объект может иметь множество состояний
• объекты связны друг с другом и обмениваются сообщениями которые меняют состояния объектов

Потому нужен IDE чтоб скакать по классам, деббагер чтоб отлавливать изменения внутренних состояний, UML чтоб пытаться все это описать. Живите с этим :)

Нету теоретического аппарата

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

Его и не будет.

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

Живите с этим :)

Не не. Пошли они все в жопу, пусть сами с этим живут.

программа состоит из множества объектов

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

Там думать надо, а думать дорого. Моск — самая энергожоркая падла в организме. Ну и прод проду рознь. В некоторых сегментах и кобол в проде.

ФП вообще в целом не взлетело в проде, не только поцкель.

Не знаю - не знаю, по моему ФП вполне себе взлетело. Да, оно не так широко сейчас как ооп, но работу найти можно. На хаскеле, на окамле. и на более экзотических вещах (например, на Coq).

сладко рассказывает, а по факту оно не используется в проде.

Значит он опережает своё время. Такое случалось и будет случаться с технологиями. Это нормально. Надо просто подождать.

Для ООП даже нормальных IDE нет, поэтому его мало кто глубоко понимает, потому что по сути ООП это не 1D императивщина, а уже 2D или даже 3D код, типа диаграмм UML.

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

Это не про ООП, а вообще любой продакшен код. Проекты становятся легаси через полтора-два года. Люди, закладывавшие видение и архитектуру, уходят; на их место приходят другие, кто начинает новый проект правильно на замену легаси. Затем часть новых проектов загибается, тогда как старые обрастают костылями под предлогом «deprecated»; вторая часть через год сама становится легаси.

В ООП нет никаких проблем как таковых, все проблемы растут из культуры разработки. Более того, ООП выгодно отличает то, что на него естественно ложится DDD (domain-driven development) — мощнейшее средство поддержания системы в адекватной сложности.

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

в принципе все полезное из ФП уже извлекли и освоили.

в этом смысле идеи ФП вполне себе живы и вполне себе в проде используются.

все очень не сладко на деле.

гранаты не той системы (с)

Для ООП даже нормальных IDE нет

Для джавы есть более-менее нормальные IDE. Проблема в том, что нет ЯП с очень строгой типизацией, чтобы еще на этапе компиляции полностью гарантировать консистентность рантайма. В джаве с её популярными IDE в этом плане еще можно как-то смоделировать консистентность не запуская код. Конечно, при наличии опыта у программиста и затрат времени на рефакторинг. С остальными ЯП кошмар и ужас в этом плане.

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

тесты на этапе компиляции - это можно и на жабе запилить, новый ЯП для этого не нужен.

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

ну, поругать что-нибудь я и сам могу )

Но лучше ничего сейчас нет.

вот )

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