Проблема в том(говорю о ссылке на доклад) что асинхронщина не нужна в 99%, и не дает какого то существенного увеличения производительности на среднем проекте тем более что её ещё нужно понимать чего нет у рядовых специалистов.
По этому все подобные плюсы перевешиваются минусами в сложности поиска сотрудников, потраченном времени на "идеальную" абстрактную и асинхронную архитектуру и её рефакторинг.
Twitter и т.п. гигантов, на мой взгляд, приводить в пример некорректно, у этих компаний практически неограниченные бюджеты по сравнению с рядовой конторой на постсоветском пространстве. Бюджет "разглаживает" почти все проблемы.
Некоторые оптимизации которые дает язык, в виде различных асинхронных моделей построенных на акторах, не нужны в 99% проектов. Как минимум в начале роста самого проекта, они даже вредны потому что заставляют продумывать то что пока не имеет смысл — рост нагрузки.
Уменьшение бойлерплейта даётся за счет усложнения кода, если взвесить это, возникает вопрос что лучше, нужно отталкиваться от проекта.
Согласен что уровень практики и контроля очень важен. Но всё же я больше хотел сказать что есть языки где при сопоставимом уровне 'инженерной практики' можно получить лучший результат. Java я бы не стал приводить как контрпример Scale т.к. она также имеет массу нюансов, но своих своих.
Имхо, Scala хорошо развивает мозг и позволяет обогатить себя как профессионала за счет изучения новых подходов и принципов.
Но как язык промышленного программирования я бы не стал его использовать. Когда работаешь в команде понимание кода других участников может быть затруднительно, даже если вы более менее согласились с тем что и как будете применять. Разработка на Scala даёт много вольностей и возможности написать сложный для понимания код. Чем любят заниматься люди с целью повышения своего ЧСВ.
Сама Scala мотивирует активно думать над тем что бы писать выского абстрактный код и постоянно планировать абстрактную архитектуру. Что ни как не помогает быстро и качественно решать задачу а скорее подобно творчеству. А когда эта абстрактная архитектура написана кем то другим понять её зачастую затруднительно, хотя задачи которые она решает могут быть достаточно простыми.
Так же такую сильносвязанную абстрактную архитектуру сложно рефакторить. Потому что хоть она и должна быть отстранена от прикладной задачи(суть абстракции), в реальности основана на решаемой задаче, а новые задачи(бизнес требования) могут требовать существенных измений в коде для поддержки его согласованности или костыля, что обычно и происходит, со временем сильно ухудшая понимание кода.
По этому я начал искать другие языки которые позволяют писать быстро и качественно. Остановился на Clojure и очень доволен, язык соответствует тому что я хотел найти — быстро писать качественный код.
Удивляюсь все время, люди не готовы использовать новые/другие языки, где данные проблемы или решены или минимизированы до безобразия, на уровне самого языка. Но готовы использовать странные библиотеки которые помимо минимизации типового кода, несут доп. сложности в отладке и др.)
У кого нибудь есть идеи как это объяснить, кроме консерватизма и других искажений восприятия?
Scala, мне не понятно чем он так хорош, на мой взгляд только геморой. То что можно написать на Clojure быстро и хорошо на скала потребует кучу времени и плясок с типами. Это из опыта в продакшене а не домашних хелоуворлдов.
По CL, не могу говорить т.к. его не знаю могу опираться только на clojure, те особенности что вы перечислили я для себя не могу отнести к преимуществам. Интеграция с JVM для меня огромный плюс, думаю это обьективно, есть сомнения что доступность библиотек и базовых возможностей необходимых для современной разработки хоть немного близка — поддержка многопоточной среды, средства отладки и мониторинга. Хотя может вам это не нужно. Но я не представяю как возможны современные серверные приложения без этого.
В Clojure есть ООП, за счёт полной совместимости с Java. Хотя я не представляю зачем это может понадобиться кроме обратной совместимости.
Макросы чтения в Clojure тоже есть если я правильно разобрался что это означает — можно экранировать выражение используя ` и оно не вычислиться.
Скомпилированная программа на CL загружается мгновенно.
Это особенности платформы JVM, на Node.js ClojureScript так же мгновенно запускается.
Европа подгоняет законодательство имхо. Вся соль это идеи и частично GDPR, создать законодательно условия для местного IT.
Понятно же что перенос данных это не какая не польза для пользователя — в первую очередь.
Это поможет компаниям из ЕС получить 'на халяву' данные которые накопили другие компании, в основном из США.
Об общих стандартах должны думать специалисты, но как обычно юристы имея возможность лезут во что не понимают. Стандарт может быть корявый, но вы будите к нему привязаны, потому что закон, хорошо если ещё будет возможность внутри своей системы использовать собственный подход. Сейчас наблюдаем как происходит зарегулирование IT в европе, исторический момент.
Круто конечно, создал систему — накопил пользователей, и тут все накопленные данные уходят к конкуренту потому что он например вложился в какую ни будь фичу которая смогла привлечь пользователя. Это не обязательно будет что то лучшее, какой нибудь галимый маркетинговый ход например.)
ИМХО, бред что собранные метрики и другие данные это не интеллектуальная собственность компании, а информация о которую она должна раскрывать. Возможность удалить все собранные личные данные, с этим я согласен, но передача это пипец.) Хотя может это выльется в жесткую борьбу за качество ПО, т.к. за накопленными данными (захваченным рынком) уже не укрыться, посмотрим, может я и ошибаюсь. Идеи крайне спорные.
Обычно такие вопросы возникают у тех кто не смирился с мыслью, что объект в ООП не равен объекту реального мира.
Причем тут реальный мир, я писал что-то о реальном мире? А вот во всех книгах про ООП обычно и моделируются объекты из реального мира — животные и иерархия в компании и подобное.
В реальности 99% кода это не реальный мир — кэш, HTTP, ответ от БД, обход коллекции, и т.д. На них как раз ооп и не ложится в отличии от вымышленных примеров.
ФП в целом проектировать позволяет
Что именно из деталей ФП мешает проектированию?)
Т е там где буксует ФП — отлично растет ООП и наоборот.
Можно привести примеры и теоретические выкладки где ФП буксует а ООП нет и наоборот. Без них вы как бы просто пустословите, ИМХО.
P.S.
Хотелось бы в проектировании/программировании обойтись без искусства иначе спорить можно до бесконечности.)
Что бы самому не быть голословным, приведу примеры того как предметная область не ложится на ООП из-за чего вылазит геморой.
ORM исключительно продукт ООП, попытка натянуть эту парадигму на реляционную. Из-за чего для достаточно простой задачи извлечь данные из БД нужно городить кучу классов и хитрых связей между ними. Как итог вам нужно знать SQL + ORM, две системы вместо одной. Я уже не говорю о том что ORM библиотеки между собой могут существенно отличаться.
Во пример отличного применения ООП:) https://github.com/spring-projects/spring-framework/tree/master/spring-web/src/main/java/org/springframework/http
90% кода просто перегоняют данные из одного типа(класса) в другой.
И все это чтобы представить такую простую штуку как HTTP запрос/ответ:
GET /wiki/страница HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
(пустая строка)
Которую в любом ЯП можно представить как ассоциативный массив.
Вот к чему приводит попытка все сделать в лучших традиция ООП, минимальное кол-во полезного выхода на объем кода.
И даже если для самой бизнес-логики классы и объекты оказались не очень-то нужны, то они могут пригодиться, к примеру, для тестирования и избавления от жестких зависимостей.
Т.е. вы предлагаете писать лишний код, чтобы решить проблемы которые при тестировании создает ООП, подход? Я это так понимают.
Вас удивит когда вы попробуете писать на языках с упором на минимальное количеством сэйта и чистые функции.
Все эти доп объекты "помогающие" в тестировании покажутся смешными и неудобными.
А можете прояснить свою мысль более развернуто? И предложить парадигму, более подходящую для вашей бизнес-логики?
Я не хотел тут развиваться холивары по этому альтернативы специально не писал. А сделал акцент на недостатках ООП, которые на мой взгляд ставят эту парадигму под сомнения.
наследование — лишь один из инструментов, и не обязательно его везде пихать, если для конкретной задачи оно не нужно
В ооп все пропитано наследованием. Сама парадигма делает упор на то чтобы пытаться искать иерархию типов и пытается дать "удобный" инструмент для работы с ней. На мой взгляд.
Разумеется можно на это забить. Но тогда встает вопрос, если вы игнорирует ключевые части некоторой парадигмы — зачем она вам?
а что мешает их разнести на классы, представляющие данные, и на классы, которые умеют их обрабатывать?
Тогда мне так же, непонятно зачем нужен ООП. Если вы игнорируете идею объекта — как вещи в себе.
Какой нибудь JSON или HTTP запрос в своей сути является сочетанием 2-х коллекций ассоциативного массива и списка. Для манипуляции этими двумя типами (ассоциативный массив и список) есть отличные функции в любой стандартной библиотеке, для чего нужна обертка в виде класса?
что для чисто-функциональных языков нужно неслабо вывихнуть мозг тем, кто с ними будет работать.
Думаю что в вашем случае представление о FP извращено представителями вида Haskell, языки поддерживающие основные концепции FP не обязательно должны иметь сложную систему типов. Erlang, Clojure простые, но реализуют самые важные, С ПРАКТИЧЕСКОЙ, точки зрения концепции из FP.
ИМХО. С++ как один из инициаторов ООП 'эры' это беда.
Ещё студентом ощущал что c ооп что-то не так — на нем не удается красиво написать код увязав бизнес логику и ООП парадигму.
Сейчас по прошествии лет работы с разными языками это понимание только укрепилось.
Для котиков и окошек ООП отлично подходит, для бизнес логики где нет четкого наследования и нет необходимости в объектах, т.к. в основном код это данные и функции работы над данными(но не вместе) — не подходит.
Касаемо описанных вами проблем, по сути, согласен что связанность в приложении растет, количество стейтов так же. Только регулярный рефакторинг уменьшает эту проблему.
Но не понял как вы увязали параллельные запросы и модули. Модуль, в моем понимании это просто набор функций так или иначе связанных между собой, обособленных в файле или другой схожей сущности. Любую функцию или цепочку функций можно выполнить в отдельном потоке, вариантов реализации множество. ИМХО описанный выше подход вносит больше сложностей чем решает.
Вложенность точно такая же как влюбом другом языке. Можете сделать эксперемент, два варианта одного и тогоже алгоритма и подсчитать. На своем опыте могу утверждать синтаксис осваивается очень быстро и тогда начинаешь понимать что как это не странно(на первый взляд) программы на clojure читать проще.
Для начала поиграться с синтаксисом, к нему нужно просто привыкнуть, чтобы он легко читался, это неделя-две. 4clojure.com отличный сайт.
Разобраться с основными структурами данных (если не знакомы), список и ассоциативный массив.
Разобраться с основными функциями для работы со структурами в Clojure assoc, conj.
Разобраться с основной функцией в FP — reduce, и её производными map, filter,…
Ну и прочитать хорошую книгу, я рекомендую следующую:
"Эмерик, Карпер, Гранд: Программирование в Clojure. Практика применения Lisp в мире Java"
Если как рус так и анг вариант.
А какую архитектуру / фреймворк вы используете для декомпозиции приложения на модули
Мы используем только стандартные средства, 1-н файл это один модуль (ns) стараемся чтобы он отвечал за обособленную часть логики.
… поддержки состояния каждого модуля?
По сути не так много мест где нужно состояние. Это некоторые инфраструктурные моменты, абстракции для работы БД(connection pool), конфиги, возможно ещё что-то и некоторые алгоритмы с бизнес логикой, которые требуют стэйта. У нас это отдельные модули.
У нас очень мало стейта(условно переменных) в приложении, можно пересчитать по пальцам, только там где без этого не обойтись. В остальном мы стремимся чтобы каждая функция была чистой(т.е. без side effect), это значительно упрощает приложения и что уменьшает кол-во багов. В основном когда приходит запрос извне мы подготавливаем все необходимые данные в коллекцию и передаем их вместе с данными из запроса далле, а не запрашиваем в в каждой функции отдельно(в цепочке вычислений). Там где нужен стейт мы используем обычный def или atom, второе соответственно позволяет выполняет изменения стейта в runtime.
Там где это сделать не возможно напрямую получаем нужный стэйт, проблем это не доставляет.
Вообще нужно стремиться минимизировать количество стейтов, это сильно упрощает код, что уменьшает кол-во багов.
Могли бы вы привести конкретную проблему которая заставила вас внедрять вышеописанные библиотеки? Нам достаточно описанного выше.
Проблема в том(говорю о ссылке на доклад) что асинхронщина не нужна в 99%, и не дает какого то существенного увеличения производительности на среднем проекте тем более что её ещё нужно понимать чего нет у рядовых специалистов.
По этому все подобные плюсы перевешиваются минусами в сложности поиска сотрудников, потраченном времени на "идеальную" абстрактную и асинхронную архитектуру и её рефакторинг.
Twitter и т.п. гигантов, на мой взгляд, приводить в пример некорректно, у этих компаний практически неограниченные бюджеты по сравнению с рядовой конторой на постсоветском пространстве. Бюджет "разглаживает" почти все проблемы.
Некоторые оптимизации которые дает язык, в виде различных асинхронных моделей построенных на акторах, не нужны в 99% проектов. Как минимум в начале роста самого проекта, они даже вредны потому что заставляют продумывать то что пока не имеет смысл — рост нагрузки.
Уменьшение бойлерплейта даётся за счет усложнения кода, если взвесить это, возникает вопрос что лучше, нужно отталкиваться от проекта.
Согласен что уровень практики и контроля очень важен. Но всё же я больше хотел сказать что есть языки где при сопоставимом уровне 'инженерной практики' можно получить лучший результат. Java я бы не стал приводить как контрпример Scale т.к. она также имеет массу нюансов, но своих своих.
Имхо, Scala хорошо развивает мозг и позволяет обогатить себя как профессионала за счет изучения новых подходов и принципов.
Но как язык промышленного программирования я бы не стал его использовать. Когда работаешь в команде понимание кода других участников может быть затруднительно, даже если вы более менее согласились с тем что и как будете применять. Разработка на Scala даёт много вольностей и возможности написать сложный для понимания код. Чем любят заниматься люди с целью повышения своего ЧСВ.
Сама Scala мотивирует активно думать над тем что бы писать выского абстрактный код и постоянно планировать абстрактную архитектуру. Что ни как не помогает быстро и качественно решать задачу а скорее подобно творчеству. А когда эта абстрактная архитектура написана кем то другим понять её зачастую затруднительно, хотя задачи которые она решает могут быть достаточно простыми.
Так же такую сильносвязанную абстрактную архитектуру сложно рефакторить. Потому что хоть она и должна быть отстранена от прикладной задачи(суть абстракции), в реальности основана на решаемой задаче, а новые задачи(бизнес требования) могут требовать существенных измений в коде для поддержки его согласованности или костыля, что обычно и происходит, со временем сильно ухудшая понимание кода.
По этому я начал искать другие языки которые позволяют писать быстро и качественно. Остановился на Clojure и очень доволен, язык соответствует тому что я хотел найти — быстро писать качественный код.
Удивляюсь все время, люди не готовы использовать новые/другие языки, где данные проблемы или решены или минимизированы до безобразия, на уровне самого языка. Но готовы использовать странные библиотеки которые помимо минимизации типового кода, несут доп. сложности в отладке и др.)
У кого нибудь есть идеи как это объяснить, кроме консерватизма и других искажений восприятия?
Scala, мне не понятно чем он так хорош, на мой взгляд только геморой. То что можно написать на Clojure быстро и хорошо на скала потребует кучу времени и плясок с типами. Это из опыта в продакшене а не домашних хелоуворлдов.
По CL, не могу говорить т.к. его не знаю могу опираться только на clojure, те особенности что вы перечислили я для себя не могу отнести к преимуществам. Интеграция с JVM для меня огромный плюс, думаю это обьективно, есть сомнения что доступность библиотек и базовых возможностей необходимых для современной разработки хоть немного близка — поддержка многопоточной среды, средства отладки и мониторинга. Хотя может вам это не нужно. Но я не представяю как возможны современные серверные приложения без этого.
Все проблемы с библиотеками решены в Clojure.
В Clojure есть ООП, за счёт полной совместимости с Java. Хотя я не представляю зачем это может понадобиться кроме обратной совместимости.
Макросы чтения в Clojure тоже есть если я правильно разобрался что это означает — можно экранировать выражение используя ` и оно не вычислиться.
Это особенности платформы JVM, на Node.js ClojureScript так же мгновенно запускается.
У Common LISP есть какие либо преимущества перед Clojure? Или хотя бы то чего не в Clojure, может кто рассказать?
Гомоиконичности в приведенных вами языках нет, как минимум:)
GDPR обязывает предоставлять возможность переноса.
Предложение обязать всех иметь единый протокол это не попытка зарегулировать?
Европа подгоняет законодательство имхо. Вся соль это идеи и частично GDPR, создать законодательно условия для местного IT.
Понятно же что перенос данных это не какая не польза для пользователя — в первую очередь.
Это поможет компаниям из ЕС получить 'на халяву' данные которые накопили другие компании, в основном из США.
Об общих стандартах должны думать специалисты, но как обычно юристы имея возможность лезут во что не понимают. Стандарт может быть корявый, но вы будите к нему привязаны, потому что закон, хорошо если ещё будет возможность внутри своей системы использовать собственный подход. Сейчас наблюдаем как происходит зарегулирование IT в европе, исторический момент.
Круто конечно, создал систему — накопил пользователей, и тут все накопленные данные уходят к конкуренту потому что он например вложился в какую ни будь фичу которая смогла привлечь пользователя. Это не обязательно будет что то лучшее, какой нибудь галимый маркетинговый ход например.)
ИМХО, бред что собранные метрики и другие данные это не интеллектуальная собственность компании, а информация о которую она должна раскрывать. Возможность удалить все собранные личные данные, с этим я согласен, но передача это пипец.) Хотя может это выльется в жесткую борьбу за качество ПО, т.к. за накопленными данными (захваченным рынком) уже не укрыться, посмотрим, может я и ошибаюсь. Идеи крайне спорные.
Причем тут реальный мир, я писал что-то о реальном мире? А вот во всех книгах про ООП обычно и моделируются объекты из реального мира — животные и иерархия в компании и подобное.
В реальности 99% кода это не реальный мир — кэш, HTTP, ответ от БД, обход коллекции, и т.д. На них как раз ооп и не ложится в отличии от вымышленных примеров.
Что именно из деталей ФП мешает проектированию?)
Можно привести примеры и теоретические выкладки где ФП буксует а ООП нет и наоборот. Без них вы как бы просто пустословите, ИМХО.
P.S.
Хотелось бы в проектировании/программировании обойтись без искусства иначе спорить можно до бесконечности.)
Что бы самому не быть голословным, приведу примеры того как предметная область не ложится на ООП из-за чего вылазит геморой.
ORM исключительно продукт ООП, попытка натянуть эту парадигму на реляционную. Из-за чего для достаточно простой задачи извлечь данные из БД нужно городить кучу классов и хитрых связей между ними. Как итог вам нужно знать SQL + ORM, две системы вместо одной. Я уже не говорю о том что ORM библиотеки между собой могут существенно отличаться.
Во пример отличного применения ООП:)
https://github.com/spring-projects/spring-framework/tree/master/spring-web/src/main/java/org/springframework/http
90% кода просто перегоняют данные из одного типа(класса) в другой.
И все это чтобы представить такую простую штуку как HTTP запрос/ответ:
Которую в любом ЯП можно представить как ассоциативный массив.
Вот к чему приводит попытка все сделать в лучших традиция ООП, минимальное кол-во полезного выхода на объем кода.
Т.е. вы предлагаете писать лишний код, чтобы решить проблемы которые при тестировании создает ООП, подход? Я это так понимают.
Вас удивит когда вы попробуете писать на языках с упором на минимальное количеством сэйта и чистые функции.
Все эти доп объекты "помогающие" в тестировании покажутся смешными и неудобными.
Я не хотел тут развиваться холивары по этому альтернативы специально не писал. А сделал акцент на недостатках ООП, которые на мой взгляд ставят эту парадигму под сомнения.
В ооп все пропитано наследованием. Сама парадигма делает упор на то чтобы пытаться искать иерархию типов и пытается дать "удобный" инструмент для работы с ней. На мой взгляд.
Разумеется можно на это забить. Но тогда встает вопрос, если вы игнорирует ключевые части некоторой парадигмы — зачем она вам?
Тогда мне так же, непонятно зачем нужен ООП. Если вы игнорируете идею объекта — как вещи в себе.
Какой нибудь JSON или HTTP запрос в своей сути является сочетанием 2-х коллекций ассоциативного массива и списка. Для манипуляции этими двумя типами (ассоциативный массив и список) есть отличные функции в любой стандартной библиотеке, для чего нужна обертка в виде класса?
Думаю что в вашем случае представление о FP извращено представителями вида Haskell, языки поддерживающие основные концепции FP не обязательно должны иметь сложную систему типов. Erlang, Clojure простые, но реализуют самые важные, С ПРАКТИЧЕСКОЙ, точки зрения концепции из FP.
ИМХО. С++ как один из инициаторов ООП 'эры' это беда.
Ещё студентом ощущал что c ооп что-то не так — на нем не удается красиво написать код увязав бизнес логику и ООП парадигму.
Сейчас по прошествии лет работы с разными языками это понимание только укрепилось.
Для котиков и окошек ООП отлично подходит, для бизнес логики где нет четкого наследования и нет необходимости в объектах, т.к. в основном код это данные и функции работы над данными(но не вместе) — не подходит.
Касаемо описанных вами проблем, по сути, согласен что связанность в приложении растет, количество стейтов так же. Только регулярный рефакторинг уменьшает эту проблему.
Но не понял как вы увязали параллельные запросы и модули. Модуль, в моем понимании это просто набор функций так или иначе связанных между собой, обособленных в файле или другой схожей сущности. Любую функцию или цепочку функций можно выполнить в отдельном потоке, вариантов реализации множество. ИМХО описанный выше подход вносит больше сложностей чем решает.
Вложенность точно такая же как влюбом другом языке. Можете сделать эксперемент, два варианта одного и тогоже алгоритма и подсчитать. На своем опыте могу утверждать синтаксис осваивается очень быстро и тогда начинаешь понимать что как это не странно(на первый взляд) программы на clojure читать проще.
Для начала поиграться с синтаксисом, к нему нужно просто привыкнуть, чтобы он легко читался, это неделя-две. 4clojure.com отличный сайт.
Разобраться с основными структурами данных (если не знакомы), список и ассоциативный массив.
Разобраться с основными функциями для работы со структурами в Clojure assoc, conj.
Разобраться с основной функцией в FP — reduce, и её производными map, filter,…
Ну и прочитать хорошую книгу, я рекомендую следующую:
"Эмерик, Карпер, Гранд: Программирование в Clojure. Практика применения Lisp в мире Java"
Если как рус так и анг вариант.