Про будущее систем управления зависимостями

#шозабредятолькочтопрочитал?

алгоритмическая сложность управления зависимостями принципиально не поменялась

— Что это было, Ватсон? :)

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

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

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

А чем плохо?

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

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

Поддерживаю анонима выше про веб-разработчиков и ad-hoc решения :)

ТС, это ты просто в такой ниши варишься. То, что ты предлагаешь, «хочется чтобы какой-нибудь веб, чтобы вон те тесты выполнялись» будет еще хуже, совсем потеряет связь с реальностью. Но, чую, для веб это нормальный путь, продолжайте делать leftpad и import github.com/repo123, сами себе могилу роете

стандартизируешь API
внедряешь профессиональную подготовку и лицензию программиста
теперь, например, Server.run() во всех фреймворках делает одно и тоже, т.к. метод run() в стандарте прописан
отбираешь лицензию у особо одарённых, которые делают метод pleaseRun()
появляется нечеткое управление зависимостями, теперь неважно что там за фрейворк, главное что он быстрее остальных работает.

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


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

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

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

и уж конечно, типичный программист не должен самостоятельно писать системные компоненты («кирпичики») - он их будет собирать из репов на Гитхабе.

как уже видно на практике, разработка путем комбинирования лефтпадов с гитхаба приводит к разрастанию скоупа до сотен тысяч зависимостей. У меня сейчас на SSD и i7, npm install отрабатывает пять минут - а ведь он ничего не компилирует в прямом смысле, просто чекает зависиомсти. В джаве все немного побыстрее (пара минут при несравнимо большем объеме кода), но и Maven сильно более продвинутая штука

если уж программе (npm) приходится пять минут гулять по интернету и числодробить, то что говорить о живом человеке? Он съедет с катушек немедля!

то есть задача напрямую вытекает из тренда на то, что программирование становится простым и общеупотребительным, как умение читать и писать. Это часть предметной области, нельзя просто так сказать «а мы просто не будем этим заниматься», это ведь часть задачи

ты про Хабр? Изысканный комплимент. Да, пишу туда переводы and proud

Держи нас в курсе.

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

Ужасы какие. Ты сорвал покровы.

нечеткое управление зависимостями

Это твой метущийся разум так солверы обозвал?

мы (люди)

С каких пор вы, макаки-быдлокодеры, стали людьми?

Автор похоже слишком долго юзает всякий orm в java. Да это мусор. Просто не юзайте его.

По-моему, в офтопике уже давно некое подобие ИИ отвечает за обновления, установку программ и прочее.

поэтому вопрос - кто из присутствующих прямо сейчас чувствует себя в силах написать нечеткое управление зависимостями?

- такое уже есть:

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

Главное, чтобы они там были + спеки (наверное это доступно в аннотацих)

Мне кажется проблема несколько надумана.

Пример: https://ru.wikipedia.org/wiki/Экзоядро

Увы, но твоими зависимостями уже ничто не сможет управлять

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

А ты попробуй быть недисциплинированным в Си. Тебе руки оторвёт первым же сегфолтом.

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

расскажи вкратце, как у них сказано?

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

Как показывает практика, сотни тысяч обезьян не напишут тебе «войну и мир», разве что случайно и через миллион лет.

Значит уровень входа в эту задачу - должен быть не сложнее учебника восьмого класса.

Кому «должен»? Обезьяны не осиливают? Вон из профессии значит, всё равно ничего путного такой «разработчик» не напишет. Самодисциплина и минимализм, о которых ты так недоумённо отзываешься - это необходимое условие для разработки на перспективу. Иначе всё скатывается в leftpad, композер и чудовищные nero-like комбайны.

разработка путем комбинирования лефтпадов с гитхаба приводит к разрастанию скоупа до сотен тысяч зависимостей. У меня сейчас на SSD и i7, npm install отрабатывает пять минут

«истории узбека» - тег очень правильный и ёмкий. Попробуй сменить область работы.

Как показывает практика, сотни тысяч обезьян не напишут тебе «войну и мир», разве что случайно и через миллион лет.

А они и не будут писать войну и мир.

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

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

Люди когда «умеют обращаться с холодильником» - не знают как сделать новый холодильник, но могут подрегулировать на нем индикаторы, воткнуть запчасти, итп

Например, если какой-то модуль в любимом фитнес-приложении сломался (интеграция Strava с MyFitnessPal?), то человеку не нужно быть программистом, чтобы сходить на гитхаб и прикрутить какой-то другой модуль

Или вот например, у меня друг - до мозга костей гуманитарий, учитель истории по профессии, рекламщик по карьере. Однако же спокойно правит сайты на Вордпрессе, и даже копается в коде плагинов. Чтобы копаться в коде на PHP он ни секунды не изучал PHP, но тем не менее его правки работают

Вон из профессии значит

Так тут речь и идет о том, что казуальное «программирование» станет таким же навыком как счет, чтение или письмо

Давно ты видел профессиональных щетунов на калькуляторе? Или профессиональных машинистрок? Или профессильнальных чтецов книг?

Просто однажды ВСЕ поняли, что набор текста - это слишком легко, чтобы быть профессией

Так вот и казуальное програсммироваммирование - это слишком легко, чтобы быть профессией

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

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

Всё сводится к сфокусированности отдельного модуля на решении задач, которые перед ним поставлены. Если ему для этого нужно обращаться в том числе к другим модулям, то появляется связность или зацепленность - в зависимости от того, плохо или хорошо написан модуль. То есть приходим к разделению ответственности между независимыми программными сущностями - всё как в жизни - начальники и работяги. Вот ещё: https://ru.wikipedia.org/wiki/Связность_(программирование)

Не скейлится.

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

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

Вобще не понял где связь между простотой использования и внутренними деталями типа управления зависимости. Какой-то логический провал.

Связь прямая. Ты собираешь приложение из «кирпичиков» лежащих на Гитхабе (или Maven Central в случае Java), а не кодишь эти кирпичики самостоятельно. Это означает тысячи зависимостей на внешние библиотеки.

Потом склеиваешь эти кирпичики копипастой со Stackoverflow. Изучать ничего не надо - в нормальных языках (типа Java, C#) можно кодить с помощью автодополнения.

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

Самая печальная фигня - это динамическая несовместимость зависимостей, но с ней пока пакетные менеджеры справляться не могут. Например, у меня в проекте сейчас несколько версий Spring Framework, и сделать чтобы они все одновременно хорошо работали - это адский ад, и целые НЕДЕЛИ, проведенные в отладчике, без какого-то написания кода, просто чтобы понять, что происходит.

т. Например, у меня в проекте сейчас несколько версий Spring Framework

Как так? Есть ограничения самой JVM, один класслоадер - одна версия класса. Но т.к. происходит позднее связывание, то по мере исполнения и начнутся всякие runtime exception'ы с ненайденными методами, потому как классы будут подгружаться из разных jar отличающихся только версией. Во всех проектах которых я участвовал, всегда просто использовали <exclude> и форсировали нужную версию в транзитивных зависимостях. Дел на 10-15 минут, в мавене есть несколько плагинов которые помогают ваилидровать зависимости, в том числе на уникальность версий библиотек, проект просто не соберется если в зависимостях будут обнаружены две версии одной библиотеке в прямых или транзитивных зависимостях.

в. Это задача достаточно сложная, чтобы ты задолбался. Особено учитывая, что зависимости постоянно обновляются, выходят новые версии

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

Раздули из мухи слона.

например, раньше люди печалились, что обычный Hello World в Java заставляет загружаться 2000 классов. Сейчас чтобы написать Hello World уже недостаточно функции main с принтом - теперь нужно подключить гипервизоры докеров, внутри которых живет микросервисная платформа

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

ИМХО работа в организации, когда ты встроен в иерархию да еще если есть строгое следование идеи collective code ownership, когда тебе не дают завершить разработку модуля, только потому, что ты стал слишком ключевым разработчиком этого кода и его срочно нужно передать другому, все это может очень демотивировать. Я принял то, что интересы компании зачастую != личным интересам. Может поменять работу/компанию? Можно и перегореть, так что на код даже смотреть не захочется.

Ты собираешь приложение из «кирпичиков» лежащих на Гитхабе (или Maven Central в случае Java), а не кодишь эти кирпичики самостоятельно. Это означает тысячи зависимостей на внешние библиотеки.

А по мне это ничего не означает. Откуда тысячи зависимостей?

Сколько там классов - уже никто не считает. Десятки тысяч, сотни?

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

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

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

прикладники - уже всё

Как это себе представляешь? Думаешь ИИ в ближайшее время осилит создание новых типов UI и их взаимодействие с пользователем? Сможет изобрести UI под раскладываемые гибкие экраны, удобные пользователю? Или создать учебную программу по Химии и Физики для VR устройств?

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

Только в дрыснявом вебмирке.

Я бы рассматривал ИИ в плане более интеллектуальной IDE, например, тебе нужно открыть файл и система тебе выдает какими способами ты это можешь сделать, какие у них преимущества и недостатки. Т.е. это некоторая интеграция интернет форумов типа Stackoverflow и IDE.

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

Не все хотят жить в фашистском мирке с армейской иерархией, общим врагом, и дальше по описанию.

Я хочу жить в больших децентрализованных проектах, где каждый как хочет — так и пишет.

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

Но при этом нельзя надеяться, что у тебя всегда самый ТОП, ибо обязательно найдутся люди, которым просто влом сейчас этим заниматься, они обновятся через неделю :)

Для современных людей нормально обновляться. Если этого не делать, то в конце концов начнешь жить в пещере и использовать Debian Stable :)

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

Под «разной природой» может быть такое, что последовательность бинов в context.xml может влиять на работу системы. Или например, если в один context.xml вложить context2.xml с помощью импорта, то в бинах из context2 не будут работать PropertyPlaceholderConfigurer, а если руками заменить импорт на копипасту полного содержания context2 - то оно заработает. Или иногда, в контексте перестают искаться бины, и ты день напролет сидишь и степаешь F8 в поисках, а где же алгоритм поиска сломался (а он ведь немного разный в разных версиях, и черт знает с какой версией в какой конфигурации на сервере ошибка).

OSGi не знаю, может потому не понимаю сложностей с версионностью.

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

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

где каждый как хочет — так и пишет.

Это другая крайность. Надо стремится к балансу. Кстати, из-за стремления к свободе лучше идти в Scala, т.к. инструменты статического анализа не так развиты как против java. Но в scala-ориентированных конторах практикуют больше код ревью. Т.е. больше личного общения со всеми плюсами и минусами. Но это только мои догадки из общения с такими командами.