Это, конечно, не только джава, а любой проект архитектурных астронавтов. ‎- mark
А вот смотри какая у меня картинка есть! https://twitter.com/_solnic_/status/748108916979032064 ‎- а меня почему-то забыли
^ Тоже жесть, конечно. В оправдание рельсов могу сказать только, что они оптимизируют количество бойлерплейта, которое приходится писать программисту. Но уровень accidental complexity тоже внушающий, да. ‎- mark
Многим ли лучше был бы stack trace, в котором в 10 раз меньше вызовов, но каждая вызванная функция в 10 раз длиннее? Многим ли приятнее было бы писать проект, в котором покрашенный жёлтым написанный руками код занимал бы 90%, а покрашенный зелёным написанный и оттестированный другими — 10%? ‎- 9000
^ А вдруг сумма не обязана быть нулевой? ‎- mark
:|[/\/\/\/\/\]|: Modern IT is complex. Only urbit will save us. Purchase stars. UPD извините - пионэрский пост. Надо еще к нему написать - а вот в линуске такое делается в 3 вызова. ‎- Все собаки попадают в рай
Ну могу поверить, что это пишу, но Денис прав. К слову, Acegi Security не называется Acegi уже примерно *восемь лет*. ‎- alf
@markizko: Не очень понял про сумму. Но на плечах гигантов стоять довольно эффективно, даже если сам чуть выше среднего. То, что жёлтым там покрашено 2 строчки из всего огромного стектрейса — большая архитектурная победа, т.е. customer value обеспечен написанием 2 методов, а остальное, нужное для этого, взято бесплатно (кроме JBoss) и практически мгновенно готовое. Насколько нужно это всё остальное — отдельный вопрос, но часто именно что нужно. ‎- 9000
^^ ^^^ Баян! Ведь прикрытое клеёночкой наслоение мусора на говно было только тогда, а сейчас его и вовсе нет. А главный вопрос: а нужно ли это всё? Я вот смело скажу, что нет! ‎- mark
^^ "Насколько нужно это всё остальное — отдельный вопрос" — воооооооооооооот. ‎- mark
Only the jdbc is part of the java ee standard. ‎- nimsi
Безумству храбрых поем мы песню. В терминах "мусор" и "говно" я обсуждать не готов, это слишком высокий стиль. ‎- alf
^ Извините, наслоение архитектурной сложности на дизайн паттерны. ‎- mark
если мой код работает внутри Smalltalk image-а, и у меня есть работающий Smalltalk image, то что мне с того, что код маленький, а Smalltalk image большой? если мой код работает внутри интернета, ... ‎- visions of swastikas in my head
ну и давайте разрисовывать тогда, что там внутри Skylake делает с моими командами по сравнению с 386-ым ‎- visions of swastikas in my head
^ :) ‎- alf
Для меня вот ОП-картинка вообще о другом. Я согласен с большинством тезисов @9000, однако засада тут для меня главным образом не в том, что фреймворки и библиотеки функционально избыточны, а в том, что они создают иллюзию простоты решения - написал две строчки жёлтенького кода и всё работает. Но если что-то идёт не так[tm], то отлаживать приходится не только две жёлтые строчки, но и девяносто восемь синих, которые написаны неизвестно кем, неизвестно когда и не всегда совершенно понятно зачем. ‎- крадецът на ябълки
Ну и наконец все мы знаем: в Blub такие вещи как "org.blubframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy" — это обязательное, я подчёркиваю, обязательное условие для того, чтобы создать современное, комплексное приложение. ‎- mark
@mindszenty: Это вопрос качества библиотек, т.е. того, насколько их абстракции протекают. Когда что-то идёт не так в моей программе на Java, это в 99.5% случаях мой код, в 0.45% случаев библиотека (тогда ценишь открытые исходники), в 0.05% случаев это проблема DBMS, JVM или OS. Такой уровень изоляции кажется мне приемлемым. Если "отлаживать все 98 синих строчек" (и даже просто заглядывать в их реализацию) приходится чаще, чем в 1% случаев, вы либо неправильно выбираете источники синих строчек, либо сидите на таком bleeding edge, где вам должны адекватно платить за понимание этих 98 остальных. ‎- 9000
В моём случае это фронтенд :) суровый фронтир, да. (Который при этом потихоньку обрастает своими абстракциями, что временами приводит к показанному в https://mokum.place/markizko/690003) ‎- крадецът на ябълки
@markizko: Нет, не обязательно — это, насколько я понимаю, деталь реализации, которую пользователю бибилиотеки видеть обычно не приходится. Возможно, другая архитектурная модель была бы эффективнее (проще, менее ресурсоёмка, etc), возможно, если вместо Java взять другой язык, функциональный эквивалент этого можно было бы выразить лучше. Но прелесть библиотек в том, что они при правильном подходе являют собой чёрный ящик, который просто работает™, и всех деталей реализации которого можно и не знать. Совершенно те же силы ("бюджет и сроки"), которые толкают одних к решениям на rails или node, толкают других к решениям на Spring и hibernate; у них просто разный набор компромиссов. (А кто считает, что можно сделать намного проще — пусть сделает, все будут только рады.) ‎- 9000
^ но мой пойнт ещё и в том, что некоторые вещи нельзя сделать намного проще существующих решений в силу сложности самой задачи. То, что сложность реализации скрыта в чёрном ящике фреймворка, создаёт упомянутую иллюзию простоты, которая в некоторых случаях может быть опасной (например, если кто-нибудь желает избавиться от лишних слоёв абстракции и с водой выплёскивает и ребёнка). ‎- крадецът на ябълки
^^ Я понимаю и принимаю силы, кои нами управляют. Но абстракции имеют обыкновение течь. У меня на практике ломались _все_ части стека (ну ладно, аппаратных багов я ещё не ловил, не считая редких отказов дисковых контроллеров): сетевой стек операционки, компиляторы, инфраструктурные компоненты (дб, поиск, файловая система), библиотечный и фреймворчный код так и вовсе течёт непрерывно. Если вам не приходится влезать в чёрный ящик, то вы счастливый человек, я вам искренне завидую! Помимо условной когнитивной цены, которую мы платим за неоправданную сложность, есть ещё и цена исполнения, когда web-scale map-reduce кластер на сто машин считает то, что можно было бы сделать на одной. Камон, мы можем лучше. ‎- mark
@markizko: Про неустранимую сложность задачси уже выше написал @mindszenty. Если сложность _устранима_, то, конечно, её хорошо бы устранить! Только, опять же, не нарушив корректности решения. Тут за меня всё уже сказали великие: "Make it as simple as possible, but not simpler" + "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." ‎- 9000
^ "Если сложность _устранима_, то, конечно, её хорошо бы устранить!" — об чём собственно и речь с самого начала. А то, что мы, программисты, совершаем сделку с дьяволом сложности буквально ежедневно не означает, что это правильно, а только лишь то, что у нас очень слабые моральные и волевые качества! ‎- mark
@markizko: Так выходит, что почти всё в жизни — результат компромисса. Ярвиновы марсиане могли потратить миллион лет на то, чтобы довести температуру своего кода до нуля (https://github.com/urbit/old-urbit.org/blob/master/community/...). Мало кто в IT-индустрии может похвастаться такими бюджетами времени (а если взглянуть на живую природу, то понимаешь, что и миллиона часто кастрофически мало). То, как выглядит экосистема Java — результат кучи компромиссов, от начала 1990-х до наших дней. То, как выглядит Hibernate — результат не только многословности Java как языка (и компромисса, в результате которого JVM жёстко заточена под ООП), но и того, что Hibernate решает свою задачу для кучи возможных условий, а не только для вот этой задачки, где все его возможности, вероятно, избыточны, но возможности чего-то попроще, вероятно, недостаточны. У того, что код на Хаскеле для этой задачи, возможно, был бы в 10 раз короче, есть цена в плане найма грамотных программистов и трудностей с рядом библиотек (аналога JDBC там нет). У того, что код на рельсах для этой задачи, вероятно, был бы в 10 раз короче, есть цена в виде меньших гарантий целостности stringly-typed кода, трудности рефакторинга и ощутимо меньшей производительности. Etc, ad libitum. Суперкомпилятор, который оставит от вашего кода ровно нужные code paths, оптимизирует их глобально, выкинет все лишние слои и выдаст вам unikernel с близким к нулю оверхедом, пока коммерчески не доступен. ‎- 9000
^ Это всё мне, конечно же, понятно и близко, ибо я такой же прагматик, как и все. Ну не бывает иных людей в нашем деле, особенно когда сроки истекают вчера, спецификация, кажется, была написана сумасшедшим, а состояние кодобазы напоминает полотна босха. Просто некоторые компромиссы экономят нам немножко сил сегодня, а забирают множко сил послезавтра. Причём если в случае с техническим долгом это кажется всем самоочевидным, то в случае с наворотами абстракций далеко не всем. Понимаете, формально всё здорово и зашибись, всё по полочкам, все метрики указывают на то, что каждый метод не больше пяти строк, а в каждом классе не больше семи методов, а каждый класс в своём файле, а каждый файл в нужном месте в иерархии. Но если попытаться осознать структуру этой причудливой системы в целом, окажется, что это просто невозможно без предварительного приёма хотя бы сотки коньяка. Это, конечно, только один пример неоправданной сложности, тактический. А бывает ещё сложность стратегическая. Вот допустим, когда ты закладываешься на что-то такое, что в жизни не понадобится. XML-driven programming (shudder), вот это всё. В результате получается, что оверхеда на рубль, а полезного кода на три копейки. ‎- mark
Ну и извините, конечно, если мысль банальная и очевидная, а также если считаете, что не стоило её иллюстрировать джавовскими стектрейсами. Вон @zverok принёс рельсовых картинок, они ничуть не хуже! Я никак не могу быть виноватым в том, что джава именно такая и вынуждает порождать именно такое. Пол Грэм этот вопрос закрыл ещё сто лет назад (http://www.paulgraham.com/avg.html). ‎- mark
@markizko: ^^ Совершенно согласен. Единственнная проблема, которая заставиля меня ввязаться в дискуссию — то, что исходная картинка имеет к сказанному довольно косвенное отношение. ‎- 9000

2015-2016 Mokum.place