на машине Тьюринга никуда не уедешь :)

Архитектура котлиновской программы никогда не будет чисто функциональной. Да и чистым языком котлин не будет. Так зачем?

Просто для того, чтобы сердце грело?

Я понимаю, зачем нужны чистые языки и какие в этом плюсы. Ради этого можно идти на много разных жертв. Но если чистоты нет, то на фига?..

Я понимаю, зачем нужны чистые языки и какие в этом плюсы. Ради этого можно идти на много разных жертв. Но если чистоты нет, то на фига?..

Ну, например, за счёт этого есть возможность разделить чистые вычисления и сайд эффекты. Конечно проблема, что к этому никак нельзя принудить, но по мне, так возможность - лучше, чем ничего.

В котлине это нельзя сделать. И не надо пытаться, слишком много всего нужно выкинуть для того, чтобы было можно

В котлине это нельзя сделать. И не надо пытаться, слишком много всего нужно выкинуть для того, чтобы было можно

Почему это? Что мешает?

Нет возможноть гарантировать чистоту функции

В котлине это нельзя сделать. И не надо пытаться, слишком много всего нужно выкинуть для того, чтобы было можно

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

Я могу, но я не могу гарантировать, что он будет изолированным.

Хаскель про гарантии

Нет возможноть гарантировать чистоту функции

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

ага

Но если нет гарантии, зачем мучиться

Но если нет гарантии, зачем мучиться

Простота тестирования и композиции

Ну отвечая на вопрос о смысле "упарываться": смысл в том, чтобы программировать в математически корректных, выверенных абстракциях, с хорошо определённым поведением.

Применимо ли это, к динамикодриснявым? Типа https://dry-rb.org/gems/dry-monads/ ? Как по мне, использование задает какой-то каркас, архитектуру приложения. Но все равно, больше похоже на карго культ.

Но если нет гарантии, зачем мучиться

люди же зачем-то внедряют чистую архитектуру в андроид проекты, хотя она там держится на добром слове и профессионализме

Ну незнаааю. Функциональные конструкции проще тестировать, но значительно сложнее отлаживать. Тут вполне возможно, что шило на мыло

Применимо ли это, к динамикодриснявым? Типа https://dry-rb.org/gems/dry-monads/ ? Как по мне, использование задает какой-то каркас, архитектуру приложения. Но все равно, больше похоже на карго культ.

Скорее просто мода

в общем, тут каждый сам решает для себя

Ну незнаааю. Функциональные конструкции проще тестировать, но значительно сложнее отлаживать. Тут вполне возможно, что шило на мыло

Ну вот ради простоты тестирования это всё и делается. Сложно отлаживать мы в JVM мире, с его DI, процессингом аннотаций в рантайме и прочим, уже получили и так ?

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

Что там в DI сложно отлаживать) Для проекта больше 30 классов и одного разработчика DI must-have.

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

DI в текущем виде - это как раз про то, как намертво склеить чистые вычисления с сайд эффектами в один монолитный комок Если что, в Хаскеле тоже вполне есть DI, я тут пробовал замокать IO монаду для тестирования main - вполне себе мокается для тестов, при этом в проде остаётся вполне себе IO

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

Самая мякотка, что DI должна облегчать отладку, но протагонисты DI совершенно не умеют ее готовить

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

имеются же в виду контейнеры, а не инверсия как таковая?

Скажем, так чрезмерное использование инверсии при помощи контейнеров. Классический жуть - это когда объекты, которые явно должны передаваться как параметры в конструкторе зачем-то генерят при помощи DI

Просто чтобы не думать

Скажем, так чрезмерное использование инверсии при помощи контейнеров. Классический жуть - это когда объекты, которые явно должны передаваться как параметры в конструкторе зачем-то генерят при помощи DI

Подожди, а что тут плохого? И что невозможно дебажить?

Невозможно глядя на код понять какой объект откуда приходит и в каком состоянии

Отладкой в среде наверное все победить можно

Отладкой в среде наверное все победить можно

Нет, не всё. Состояние объекта на отладчике может не совпадать с реальным, если отлаживаешь многопоточное приложение

Я в последний раз расковыривал вот это: https://github.com/JavaEden/Orchid Очень хорошая идея, но код там адский внутри. Полнейший abuse guice и еще и с lombok впридачу. Ну не говоря о том, что там какие-то нелокальные изменения состояния и прочие радости

Невозможно глядя на код понять какой объект откуда приходит и в каком состоянии

У тех кто нормально использует DI есть только одно состояние объекта - он создан со всеми зависимостями и проинициализирован (если в di есть @PostConstruct например). А чтобы понять как вызван конструктор тебе в любом случае нужно пойти посмотреть объявление. В DI оно часто декларативное, а не полотна объектов

Ага, это подразумевает то, что у инжектируемых объектов нет своего состояния. Если так, то все конечно замечательно

Скажем, так чрезмерное использование инверсии при помощи контейнеров. Классический жуть - это когда объекты, которые явно должны передаваться как параметры в конструкторе зачем-то генерят при помощи DI

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

Ага, это подразумевает то, что у инжектируемых объектов нет своего состояния. Если так, то все конечно замечательно

@PostConstruct как раз таки подразумевает что есть состояние.

Ну оно же не меняется после инициализации?

Это происходит на этапе инициализации объекта контейнером.

До того как он отдаст тебе управление.

Ты ессно можешь это заабьюзить, как и просто говнокода написать без DI

наличие @PostConstruct — уже невероятный говнокод

Но с DI у тебя говнокод аккуратно в кучках лежит, и его разгребать проще

Подожди, а что тут плохого? И что невозможно дебажить?

Насчёт того, что тут плохого: 1. Если про DI вообще, то он часто приводит к сильному смешению чистых вычислений и работы с состоянием, что приводит к невозможности проследить поток данных и управления. 2. Если про DI на процессинге аннотаций в рантайме, то дополнительно усложняется отслеживание того, кем, когда и как эти аннотации процессятся. 3. Если Spring like DI, то добавляются грабли с AutoWired и всякими неявными умолчаниями (подробно не помню, Spring боль была последний раз 3 года назад)

Но с DI у тебя говнокод аккуратно в кучках лежит, и его разгребать проще

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

говнокод с применением DI сложнее разгребать, чем без него

Насчёт того, что тут плохого: 1. Если про DI вообще, то он часто приводит к сильному смешению чистых вычислений и работы с состоянием, что приводит к невозможности проследить поток данных и управления. 2. Если про DI на процессинге аннотаций в рантайме, то дополнительно усложняется отслеживание того, кем, когда и как эти аннотации процессятся. 3. Если Spring like DI, то добавляются грабли с AutoWired и всякими неявными умолчаниями (подробно не помню, Spring боль была последний раз 3 года назад)

1. Не понял как ваше фп влияет на невозможность понять поток выполнения. У тебя есть класс, у него есть зависимости. Вызываем метод класса, в методе дергаем зависимости - все просто и понятно. Можно пример? 2. Да, есть определенная "магия", это же на старте приложения кто-то читает аннотации, складывает в мапку и потом из мапки достатает. Очень сложно, пожалуй сам буду делать свою мапку или просто филды в классе. 3. Ну если spring-context - то там вообще умолчаний нет, там все надо самому настроить. А вот spring-boot действительно нужно понимать как работает, но там внутри все достаточно очевидно, сорцы легко читаются. На практике со всем этим успешно работают *большие* команды разработчиков, и проблем в DI нету.

говнокод с применением DI сложнее разгребать, чем без него

говнокод без применения DI сложнее разгребать, чем без него

вывод - не писать говнокод ?

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

Я говорю как разработчик на большом бекендов проекте с кучей модулей. Где сидит 10+ человек на монолите.

Если у вас микросервис на 100 строк - то да, вам вероятно будет хорошо и без DI

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

Но guice "вымораживает"

Я говорю как разработчик на большом бекендов проекте с кучей модулей. Где сидит 10+ человек на монолите.

Аргументы, подкреплённые статусом говорящего сильно прибавляют в цене ?

Но guice "вымораживает"

У guice ужасный репортинг ошибок. Понять почему $Proxy45 can't be cast to Provider невозможно. Нужно смотреть на код и думать. У Spring-Context в этом плане все намного лучше, всегда понятно что и где случилось не так.

Аргументы, подкреплённые статусом говорящего сильно прибавляют в цене ?

Собственно, да. Если, проведя параллель, спросить у hype-driven-андроидщика, как он чувствует себя с Rx+Dagger+Moxy+AAC, он тоже ответит, что всем доволен.

Аргументы, подкреплённые статусом говорящего сильно прибавляют в цене ?

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

Собственно, да. Если, проведя параллель, спросить у hype-driven-андроидщика, как он чувствует себя с Rx+Dagger+Moxy+AAC, он тоже ответит, что всем доволен.

Moxy+AAC это надо постараться

Собственно, да. Если, проведя параллель, спросить у hype-driven-андроидщика, как он чувствует себя с Rx+Dagger+Moxy+AAC, он тоже ответит, что всем доволен.

я такую комбинацию даже представить не могу))

Moxy+AAC это надо постараться

ну можно разные экраны на разном делать)0)

ну можно разные экраны на разном делать)0)

тогда где-то там вглубине еще должен быть редукс

кстати редакс то достаточно удобно, тот-же групоновкий Grox

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

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

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

Буду очень рад если мне покажут альтернативы для Kotlin мира)

ну можно разные экраны на разном делать)0)

но ведь лучше все на одном екране

ERROR: S client not available

Буду очень рад если мне покажут альтернативы для Kotlin мира)

Ну про альтернативы, которыми можно пользоваться в мире ФП, написано здесь: http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ В Kotlin я не вижу принципиальных проблем с тем, чтобы структурировать код аналогичным образом.

Ну про альтернативы, которыми можно пользоваться в мире ФП, написано здесь: http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ В Kotlin я не вижу принципиальных проблем с тем, чтобы структурировать код аналогичным образом.

404

но ведь лучше все на одном екране

Именно на «екране», да. Сильно.

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

+

404

Сорян, два раза ссылка вставилась. http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/

Ну про альтернативы, которыми можно пользоваться в мире ФП, написано здесь: http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ В Kotlin я не вижу принципиальных проблем с тем, чтобы структурировать код аналогичным образом.

Нет, это плохой ответ. Хороший ответ был бы пример приложения с таким подходом. Вот пример IoC без DI, и он неплох для маленьких проектов, но для больших, на мой взгляд, поддерживать это будет очень сложно: https://github.com/Heapy/tgto/blob/master/src/main/kotlin/app/hea/tgto/Application.kt#L37-L81

Вот много противников DI, покажите как нужно писать приложения без DI, by example.

Нет, это плохой ответ. Хороший ответ был бы пример приложения с таким подходом. Вот пример IoC без DI, и он неплох для маленьких проектов, но для больших, на мой взгляд, поддерживать это будет очень сложно: https://github.com/Heapy/tgto/blob/master/src/main/kotlin/app/hea/tgto/Application.kt#L37-L81

а вот это и есть DI

а вот это и есть DI

Это IoC, под DI обычно подразумевают какой-то контейнер который сам делает dependency injection

Вот тут DI https://github.com/Heapy/tgto/compare/koin

Это IoC, под DI обычно подразумевают какой-то контейнер который сам делает dependency injection

окей, с такой терминологией тоже согласен

Вот много противников DI, покажите как нужно писать приложения без DI, by example.

Я не противник и не стороник, но магия бесит

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

Вот тут DI https://github.com/Heapy/tgto/compare/koin

Видел физ-баз в интрпрайз стиле? ?

Я не противник и не стороник, но магия бесит

Это компромис. Сначала писали много шаблонного кода, людей начал бесить шаблонный код. Потом начали заменять шаблонный код на магию. А правда она посередине. Магии и без DI куча, а DI магия в том же spring-context это прочитать аннотации и прогнать внутренний pipeline по созданию контекста, достаточно понятная на самом деле.

Видел физ-баз в интрпрайз стиле? ?

Конечно. Можете мой говнокод в репе tgto переписать на правильный стиль. Для примера переписать на koin у меня заняло минут 10-15.

Это компромис. Сначала писали много шаблонного кода, людей начал бесить шаблонный код. Потом начали заменять шаблонный код на магию. А правда она посередине. Магии и без DI куча, а DI магия в том же spring-context это прочитать аннотации и прогнать внутренний pipeline по созданию контекста, достаточно понятная на самом деле.

Причем не обязательно аннотации, там можно и на xml описать и на java config, т.е. объекте с пачкой методов которые создают объекты.

Это компромис. Сначала писали много шаблонного кода, людей начал бесить шаблонный код. Потом начали заменять шаблонный код на магию. А правда она посередине. Магии и без DI куча, а DI магия в том же spring-context это прочитать аннотации и прогнать внутренний pipeline по созданию контекста, достаточно понятная на самом деле.

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

Конечно. Можете мой говнокод в репе tgto переписать на правильный стиль. Для примера переписать на koin у меня заняло минут 10-15.

Да зачем. Вижу, что достаточно идиоматично получилось и если обложиться моками/стабами, то и тестируемо даже.

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

Но да это редкость

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

Борисов все-таки там рассказывает не только про болячки в спринге, но и про то как его расширять. А курсы делаются не потому что спринг плох, а потому что разработчик нынче слишком нежный пошел, не может отличную документацию осилить) https://docs.spring.io/spring/docs/5.0.8.RELEASE/spring-framework-reference/

Борисов все-таки там рассказывает не только про болячки в спринге, но и про то как его расширять. А курсы делаются не потому что спринг плох, а потому что разработчик нынче слишком нежный пошел, не может отличную документацию осилить) https://docs.spring.io/spring/docs/5.0.8.RELEASE/spring-framework-reference/

Вот и я о том, часто виделись вопросы "у меня проблема, какую анноташку нужно повесить". Мой посыл что не нужно зацикливаться и посматривать на альтернативы. П.С. сам рекомендовал спринг бут

Вот и я о том, часто виделись вопросы "у меня проблема, какую анноташку нужно повесить". Мой посыл что не нужно зацикливаться и посматривать на альтернативы. П.С. сам рекомендовал спринг бут

А я сейчас наоборот spring-boot не пользуюсь, т.к. считаю его раздутым, в основном мне не нравится время старта конечно же. В остальном - все из коробки: конфигурация, actuator, куча стартеров на все случаи жизни. Если бы стартовали проект с большой командой - то это оптимальный выбор. Если команда меньше и условно говоря все опытные разработчики - то можно и решения уровня ktor брать. И DI как раз таки один из плюсов для большой, разноуровневой команды.

Так наоборот, чтобы спринг правильно сконфигурировать и вдуплить все его невнятные сообщения об ошибках нужна опытная команда.

Так наоборот, чтобы спринг правильно сконфигурировать и вдуплить все его невнятные сообщения об ошибках нужна опытная команда.

Для этого нужен один человек который уже работал со спрингом. Другие должны просто не путать аннотации Controller и Repository чтобы писать рабочий код под готовую инфрастуктуру всего от spring. Если у вас будет проект на чем-то легковесном, то все сведется к тому что теже люди будут писать то что уже есть в спринге.

Вот смотри. Я беру spring-boot, , подключаю пару зависимостей, пишу @controller, @service, @repository и бам. У меня production grade приложение с логированние, метриками, rest, базой, транзакциями, миграциями и прочим.

И непонятно, что откуда берётся, почему, как и куда пробрасывается CSRF, кем обрабазываются заголовки авторизации и т. п.

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

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

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

Все верно. Вопрос в том какие нужны для этого компетенции и сколько это будет стоить. Что будет дешевле - разобраться в готовом оттестированном решении, или писать свое с нуля. Особенно если это старт проекта и у тебя 10 разработчиков от джуна до сеньера.

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

О, интересно. Можно пример?

Все верно. Вопрос в том какие нужны для этого компетенции и сколько это будет стоить. Что будет дешевле - разобраться в готовом оттестированном решении, или писать свое с нуля. Особенно если это старт проекта и у тебя 10 разработчиков от джуна до сеньера.

Я предлагаю не писать с нуля, а писать понятный, строгий код вместо рефлективного.