All streams
Search
Write a publication
Pull to refresh
34
0.1
Regis @Regis

User

Send message

У вас может быть библиотка с какой-то сложной математикой написанной под Java 1.4. И при переходе на Java 8 она все еще будет корректно рабоать (и почти наверняка станет работать быстрее).


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

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

Очень сильно несогласен с заявлением. Если есть потенциальная возможность затюнить ORM под запрос — то очень часто выгодней все же попытаться такой возможностью воспользоваться. Потому как воспользовавшись Native запросом нередко лишаешься некоторых дополнительных плюшек ORM (готовый маппинг, отслеживание границ транзакций, lazy-поля и т.п).


Естественно, что всё должно быть в пределах разумного: если запрос сильно выбивается из того, что конкретный ORM умеет — то тратить время на "подгонку" скорее всего будет непродуктивно. Но и сразу отказываться от ORM только потому, что у вас есть готовый native запрос — глупо.

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

Обычно либо хватает простого SQL, либо, если уж хочется статической проверки, то полноценно подключается тот же упомянутый JOOQ. А тут довольно странный промежуточный шаг. Впрочем, на вкус и цвет...

Допустим я раскидал десяток классов по по 4-5 пакетам просто ради более логичной организации стуктуры. Предлагаете всё это конвертировать в 5 модулей и делать изоляцию на уровне JVM? Оверхэд же будет дикий.

Ничего, что Kotlin поверх JVM работает?

Потратил 5 минут, чтобы найти у вас на сайте стоимость отправки СМС через вашу систему. Не нашел. До свидания.

tl;dr: совеременные люди предпочитают получать и отправлять текст вместо того, чтобы делать звонки. Мы предоставляем услуги отправки SMS.

Интересно, а JetBrains допускает копирование своих учебных материалов курса без ссылки на них?

Преждевременная оптимизация — корень всех зол.

Эх, как же надоела эта вырванная из контекста цитата.

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

Вы не просто её упомянули, а вынесли её в заголовок. И при этом в самой статье про это написали полтора предложения. Конечно будут претензии :)

Эээ… И много вы можете назвать языков с аналогом модулей, которые будут в Jigsaw?

Но ведь эти фичи вроде как были изначально заявлены как "out of scope" для Jigsaw в 9-ке. Я ошибаюсь?

Тогда становится не очень понятна позиция RedHat — ведь даже если с ней согласятся (добавят циклы), то проблему RedHat'а это не решит. В чем тогда смысл?

Очевидно, это разные люди — те, кто пишет спецификации и те, кто разрабатывает софт.

Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM?


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

Такие анализы делались. Другое дело, что, очевидно, у разработчиков Java нет возможности изучить и протестировать всё. Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".

Если так, то непонятно, почему проблемы не были адресованы раньше. Попытка продавить, что есть?

Почему IBM и RedHat стали предъявлять претензии только сейчас? Ведь спеке не один год. Почему они раньше не высказались?

Основная проблема: система плохо масштабируется. При увеличении числа компонентов будут быстро расти потери на трение, что приведет к необходимости прикладывать больше усилий на входах, что, в свою очередь, будет вызывать повреждение/деформацию элементов.
Как выводы статьи связаны с тем, что вам трудно уделить пару минут для того, чтобы оформить код как следует?
поскольку ни один космический корабль никогда не приближался настолько близко к Сатурну
Не один земной космический корабль никогда не приближался настолько близко. Про остальные трудно сказать наверняка ;)

Information

Rating
3,709-th
Registered
Activity