In the direction of adding more functionality, we could allow lazy fields to be non-static and/or non-final, preserving current correspondences and analogies between static and non-static field behaviors.
Всё-таки имелось в виду именно то что написано :)
И вот именно поэтому модификатор lazy не имеет смысла сокращать несколько слов, ибо именно их комбинация задаёт разные конфигурации поведения.
Видел кучу проектов, где в геттерах присутствует манипуляция с данными. И в сеттерах. И вообще где угодно.
Естли в них нет никакой кастомной логики, зачем они вообще нужны-то? Ну сделайте публичные поля, и пишите туда с чистой совестью. Заодним и перфоманс повысите :)
Так потому и не обрабатывается, что мне не хочется его обрабатывать. Не хочется тратить на это время. Если кто-то выше по стеку потратил на это время — хорошо, нет — ну упадет все с ошибкой в гуях веб-приложения например, «произошла неизвестная ошибка» или что-то такое.
Я не хочу обрабатывать того, чего я не хочу.
Если в язык встроен механизм эксплицитного принуждения делать неприятные вещи и им кто-то пользуется — ты сразу видишь, как это происходит. В Java есть checked exceptions, все просто в IDE генерят пустые обработчики для них, и давай досвиданья.
Если же способа бороться с эксплицитным принуждением нет, то люди просто не пользуются такой технологией и все.
Можно написать, с кем вам еще хотелось бы послушать интервью. Рихтер просто чувак, который всем интересен, поэтому это статья — про него. Но наверняка существует еще куча интересных людей.
Отличная идея! Надо будет обкатать в следующем интервью. Например, только что сделал бомбическое интервью с Бреславом, и хотя он вроде бы и про Kotlin, но там столько яростного материала вроде рассуждений о полигамии, что стоит попробовать оформить это на Хабр. (Непонятно в какой хаб только).
Нет, нету. Это был разговор голосом при очень фиговом качестве записи (интернет у них там в США временами бывает ни к чёрту). Кое-что приходилось разбирать под десятью фильтрами в аудиоредакторе. Поэтому сразу писали на русском.
Область нашей деятельности — динамические рантаймы. Туда входит и Java, и .NET. Логично, что мы разговариваем на актуальные темы — кто у себя чего запилил, как это внутри работает, какие недостатки, как решать. В нашей жабе стремные дженерики, этим никого не удивить, но мы их улучшаем. Рихтер не обязан корпеть над почтовыми рассылками экспериментальных проектов, а я — обязан, поэтому мне есть что ему рассказать про дженерики. Имхо то, что вы это восприняли вот так скорей говорит о вашей точке восприятия :)
Про Go и Python у меня есть отдельное мнение, и да — это мнение в том, что языки очень сырые. Но разводить холивар об этом, имхо, стоит в отдельном топике, ибо к позиции Рихтера это не относится никак. Это моя личная позиция.
Если ты напишешь int main и пойдешь там создавать сокеты, то потом твоих объяснений что «так нужно было для задачи», «здесь и этого хватит» никто слушать не будет. Есть общепринятые стандартные практики, изволь действовать в рамках этих практик. Кто так не делает — тот лох, код — в мусорку. Если вся компания пишет на Spring Boot, то даже если у тебя консольный хэлловорлд, изволь оформить его в виде консольного приложения Spring Boot.
В этом кардинальное отличие джава-комьюнити от какого-нибудь C/C++ комьюнити. Это вот им можно рассказывать что «не серверами приложений едиными» и «бывает же разное». Почти никогда не бывает.
Хотя может быть, я просто вращался в соответствующих кругах, и где-то в других кругах — говнокодят. Их даже немного жаль :)
Лично для меня очень актуален вопрос совмещения написания статей с разработкой кода и участием в бизнесовых активностях. Очень. Мне было важно услышать ответ человека, который с блеском решил эту проблему.
Это как с паттернами организации кода или архитектурами ынтерпрайзной интеграции — пока тебя это не касатеся напрямую, ты ни книг не читаешь, ни докладов не слушаешь, на всё отвечая «да можно хоть так, хоть по-другому, как больше нравится, или как от задачи зависит». Но как только тебе реально нужно что-то закодировать, или прописать архитектурку в договоре — вот тут попа и начинает возгораться.
Даже если ответ Рихтера и является клише (то есть, применением типового паттерна к типовой сиутации), уже само понимание «в такой ситуации — вот этот паттерн» уже ценная информация.
В частности, раньше я решал все подобные вопросы с помощью kanban-подобной методологии. Но по отзывам нескольких успешных блоггеров вижу, что на самом деле это решается исключительно маниакальной дисциплиной и жестоким планированием.
Я попытался как-то разбавить простыню текста картиночками и подобием структуры. Не факт, что это получилось. Если есть идеи, что можно улучшить в плане подачи материала — обязательно напишите.
Сейчас в ынтерпрайз джаве очень просто. Или у тебя или Spring, или JEE, и еще несколько «легких» фреймворков на сдачу. Несмотря на то, что в обеих технологиях понапихано всякой всячины, принято исповедовать вполне конкретные философии. Так же как у эскимосов есть 50+ названий для цвета снега, у джавистов очень важно различать тонкие градации использования сервисов, бинов и так далее. Можно ли из сервиса звать сервис, и если нет — как устроена такая архитектура? Вот достойный вопрос для обсуждения. Сам факт того, что сервисы писать нужно, и во вполне определенной сервисной архитектуре — никто не обсуждает, это стандарт.
А ещё ты обязан знать паттерны проектирования, ооп, enterprise integration patterns, паттерны использования конкретной вещи типа Hazelcast. Стандартизация. Стандартные практики, стандартные философии, стандартные паттерны. Всё очень жестко задано и определяется в том числе модой и популярностью конкретных подходов.
Но если ты наговнякаешь код одним куском внутри сервлета — тебя будут за лоха считать все. Ну то есть, вообще все.
В C++ этого нет, там люди «пишут, исходя из задачи», и вот это всё. Многие ооп-то не используют, так в процедурном стиле и пишут, «си с классами». С «модными» архитектурами вообще беда. Проверено неоднократным общением с C++-разработчиками.
Если вместо того, чтобы поднять в докере аппликейшен-сервер и собрать под него war-ник специальными мегафреймворками, ты пойдешь и зафигачишь экзешник с int main, куда кривыми своими руками попытаешься закодить хттп-сервер — в C++ никто тебе, скорей всего, слова не скажет. Все так делают.
Наниматель дал задание рекрутерам найти побольше админов. Концепция DevOps слишком сложная, чтобы понять её за пару минут неквалифицированным рекрутером. Но рекрутер знает, что если назовет вакансию «DevOps» (даже если она не совсем понимает, что это вообще значит, даже если это неправда), то это может выполнить план по набору админов. Причем админов с высоко актуальными кейвордами в резюме (всякие CI/CD, скриптовые языки, итп).
> стоит сначала чего-то добиться, чтобы чему-то остальных учить
2 монаха шагали по дороге. Оба были довольно голодны. Вдруг один из них заметил лежащую у дороги палку.
— Давай сьедим эту палку! — предложил он.
— Она не сьедобна нихрена! — возразил второй монах.
— Откуда ты знаешь не попробовав? — спросил монах и укусил палку. Все передние зубы монаха сломались.
— Нефиг всё пробовать, чтобы знать! — сказал второй монах и ударил первого ногой в паховую область.
//кто-то внимательно читает мои переводы жепов, о_О
Всё-таки имелось в виду именно то что написано :)
И вот именно поэтому модификатор lazy не имеет смысла сокращать несколько слов, ибо именно их комбинация задаёт разные конфигурации поведения.
Естли в них нет никакой кастомной логики, зачем они вообще нужны-то? Ну сделайте публичные поля, и пишите туда с чистой совестью. Заодним и перфоманс повысите :)
Я не хочу обрабатывать того, чего я не хочу.
Если в язык встроен механизм эксплицитного принуждения делать неприятные вещи и им кто-то пользуется — ты сразу видишь, как это происходит. В Java есть checked exceptions, все просто в IDE генерят пустые обработчики для них, и давай досвиданья.
Если же способа бороться с эксплицитным принуждением нет, то люди просто не пользуются такой технологией и все.
Про Go и Python у меня есть отдельное мнение, и да — это мнение в том, что языки очень сырые. Но разводить холивар об этом, имхо, стоит в отдельном топике, ибо к позиции Рихтера это не относится никак. Это моя личная позиция.
В этом кардинальное отличие джава-комьюнити от какого-нибудь C/C++ комьюнити. Это вот им можно рассказывать что «не серверами приложений едиными» и «бывает же разное». Почти никогда не бывает.
Хотя может быть, я просто вращался в соответствующих кругах, и где-то в других кругах — говнокодят. Их даже немного жаль :)
Это как с паттернами организации кода или архитектурами ынтерпрайзной интеграции — пока тебя это не касатеся напрямую, ты ни книг не читаешь, ни докладов не слушаешь, на всё отвечая «да можно хоть так, хоть по-другому, как больше нравится, или как от задачи зависит». Но как только тебе реально нужно что-то закодировать, или прописать архитектурку в договоре — вот тут попа и начинает возгораться.
Даже если ответ Рихтера и является клише (то есть, применением типового паттерна к типовой сиутации), уже само понимание «в такой ситуации — вот этот паттерн» уже ценная информация.
В частности, раньше я решал все подобные вопросы с помощью kanban-подобной методологии. Но по отзывам нескольких успешных блоггеров вижу, что на самом деле это решается исключительно маниакальной дисциплиной и жестоким планированием.
А ещё ты обязан знать паттерны проектирования, ооп, enterprise integration patterns, паттерны использования конкретной вещи типа Hazelcast. Стандартизация. Стандартные практики, стандартные философии, стандартные паттерны. Всё очень жестко задано и определяется в том числе модой и популярностью конкретных подходов.
Но если ты наговнякаешь код одним куском внутри сервлета — тебя будут за лоха считать все. Ну то есть, вообще все.
В C++ этого нет, там люди «пишут, исходя из задачи», и вот это всё. Многие ооп-то не используют, так в процедурном стиле и пишут, «си с классами». С «модными» архитектурами вообще беда. Проверено неоднократным общением с C++-разработчиками.
Если вместо того, чтобы поднять в докере аппликейшен-сервер и собрать под него war-ник специальными мегафреймворками, ты пойдешь и зафигачишь экзешник с int main, куда кривыми своими руками попытаешься закодить хттп-сервер — в C++ никто тебе, скорей всего, слова не скажет. Все так делают.
2 монаха шагали по дороге. Оба были довольно голодны. Вдруг один из них заметил лежащую у дороги палку.
— Давай сьедим эту палку! — предложил он.
— Она не сьедобна нихрена! — возразил второй монах.
— Откуда ты знаешь не попробовав? — спросил монах и укусил палку. Все передние зубы монаха сломались.
— Нефиг всё пробовать, чтобы знать! — сказал второй монах и ударил первого ногой в паховую область.
© Дао-Какао
Воу, воу, аргументация вида «сперва добейся», серьезно?
Поведай же, какие в C++ стандарты на написание архитектуры ынтерпрайз приложений. Запасся чипсами!
> Стоит таких «узкоспециализированных» специалистов
Поискал по слову «узкоспециализированных», нашел только твой комментарий. Плохо ли я искал?