C# не только отгрыз у явы рынок — он ещё и саму яву заставил быстрее шевелиться, и в результате обновления и улучшения становятся заметны уже не только программистам, но и конечным пользователям. Вон уже и паттерн-матчинг где-то в обозримом будущем появился, и немного меньше причин всё выбросить и переписать на C++.
Это как Java — огромный рынок, на котором всё хорошо, но ничего нового нет. Как с этой проблемой справиться — не знаю.
В чём, собственно, проблема-то? Если на рынке нет новинок — значит, имеющийся спрос удовлетворён. В данном конкретном случае (так как речь идёт о языке — инструменте для решения неких задач бизнеса), это значит, что это не платформа стагнирует — это принципиально новых проблем у бизнеса не появляется, а существующих инструментов с лихвой хватает на good-enough решение. Проблемы конкретно в Java сконцентрированы на самой передовой, где действительно есть запросы бизнеса, например, обработать запросов ещё на миллион (но лучше — десять) в секунду больше, чем сейчас. Вот на этой целине сейчас действительно бурления, от новых фреймворков до языков или кастомных сборок виртуальных машин. Даже хорошо забытые парадигмы программирования прикручивают.
Новинки ради новинок действительно просто из принципа не будут пользоваться широким спросом, ну просто из соображений абзацем выше. Меня вот, наоборот, настораживает такая бешеная гонка во фронте — если у бизнеса особо нет принципиально новых проблем на бекенде, то их, вероятно, примерно столько же и на фронтэнде. Но тогда получается, что всё это бурление происходит уже не по запросу бизнеса. А если принять во внимание, что с моей бекендовой колокольни видно, главным образом, прогресс инструментов сборки, то просто получается, что там одни программисты решают проблемы других программистов, параллельно создавая десятки слоёв протекающих абстракций, чем обеспечивают новый цикл решения уже новых проблем с протеканием, которые затыкаются ещё парой слоёв абстракций и goto 10.
все клиенты, которые реально платят за GraalVM, сидят на 8, поэтому чинить косяки на 12 не имеет смысла
Тогда получается проблема стандартная, типоразмера "яйцо и курица": если не чинить косяки в новых версиях (хотя бы в 11, раз уж на то пошло, LTS всё-таки) — то все клиенты так и будут сидеть на 8, и никто их оттуда не сгонит. Не то чтоб это что-то плохое, но вроде в противодействие такому сидению Java и начала проводить такую агрессивную политику EOL в релизах — а значит какие-то причины были.
Если для нас естественна мысль о том, что сливки снимают умнейшие и что одна более развитая нация может колонизировать другую, мы вполне естественно боимся потенциального порабощения со стороны сверхумных машин. Искусственный интеллект представляет для нас экзистенциальную угрозу.
Для нас — это для белых европейских мужчин. Миллиарды других людей прошли через века подчинения, а многие продолжают сражаться с агрессорами и по сей день, поэтому для них угроза порабощения искусственным интеллектом остается фантастическим сюжетом.
Здесь имеем:
"Мы" боимся потенциального порабощения со стороны сверхумных машин
"Мы" — это белые европейские мужчины
"Другие" (видимо, не белые европейские мужчины) — порабощения не боятся
"Другие" не поятся порабощения потому, что:
либо прошли через века подчинения (видимо, привыкли и уже не боятся?)
либо считают угрозу порабощения машинами фантастическим сюжетом, так как у них есть дела поважнее — а именно, сражения с агрессорами. Хотя тут неявно и не говорится про личности агрессоров, но так как агрессоры не машины, то это либо другие «другие» (например, порабощение африканцев какими-нибудь арабами), либо «мы» — то есть, белые европейские мужчины.
Упрощая пассаж из списков наверху мы и придём к фразе:
белые рабовладельцы боятся порабощения ИИ. Остальные не боятся ИИ, потому что они в рабстве у белых рабовладельцев
Для этого нам всего лишь потребуется проигнорировать фазу борьбы одних "других" против других "других", и сосредоточиться только на сражении "других" против "мы". Основания для игнорирования нам даёт в целом позиция различных расовых активистов, согласно которой расизмом называют только расизм со стороны "белых" по отношению к "цветным" — а "цветные" по отношению к "белым" расистами быть не могут, так как "белые" это всё "заслужили веками колониализма".
Именно поэтому будущие археологи, вероятно, смогут сказать о наших поколениях не намного больше, чем о древних римлянах, несмотря даже на то, что мы оставляем на порядки более широкий след «логов» — но этот след почти на те же порядки менее долговечен.
Умение именно писать код — это, думаю, во многом именно навык вроде тех, что вы пишете.
Но также нужно помнить, что большинство программистов не столько пишет новый код, сколько читает старый и ищет в нём баги, а тут без причинно-следственных связей никак — ведь, как правило, у клиента что-то посчиталось неверно не просто потому, что именно в расчёте что-то неправильно (там как раз всё может быть идеально), а из-за условной гонки с какой-то другой частью системы, да ещё и сравнительно давно (по меркам компьютера), в результате чего данные записались в базу фрагментированными. И т.д., и т.п.
Даже написание кода требует в некотором смысле навыков выстроения цепей причинно-следственных связей — это нужно для понимания, какие API мне следует дёрнуть и в каком порядке, чтобы у клиента стало всё хорошо.
Для самого нижнего уровня квалификации в профессии эти навыки куда менее актуальны, но вроде бы в ветке и разговор шёл про «хороших программистов».
Согласен. Сработало искажение на базе моего опыта — я не припомню Builder'ов, которые не позволяли бы вызывать методы в цепочке, особенно те, что должны быть «одноразовые», потому я почти перестал различать эти два паттерна.
String::equals уже по умолчанию использует сравнение по указателю для производительности, как в Oracle JDK, так и в Open JDK и «даже» в Android JDK. Если сорить такими сравнениями ещё и за пределами equals, в собственном коде, то статистически максимальный выигрыш будет стремиться к стоимости вызова единственного метода. Стоит ли овчинка выделки с учётом всей машинерии внутри — вопрос более чем открытый.
Тогда уж ещё лучше — «Джарвис, вот тебе эскиз, обязательные характеристики перечислены в файле рядом, остальное на твоё усмотрение. Бюджет производства экземпляра там же».
человеческий язык слишком несовершенен, и из-за этого приходиться использовать дополнительные слои в виде тех же примеров и аналогий, чтобы передать изначальную мысль с минимумом искажений внутренними фильтрами наших черепушек. Вот бы где нам действительно «языки низкого уровня» пригодились бы. Когда там уже мыслеречь допилят и общение образами?
Если попытаться передавать сразу вашу изначальную мысль, то общий процесс будет аналогичен описанному вами же процессу написания софта под конкретный экземпляр компьютера. Ваша "сырая" мысль для любого другого человека будет бессмысленным набором импульсов, потому что у вас и у кого угодно ещё набор трансформаций от мысли к сообщению в терминах общего языка будет разным. Это как два сервера, где у одного — приложение на Ruby, а у второго — на C++, и по меньшей мере странно ожидать, что произвольный объект с первого сервера можно скопировать на второй и при этом не придётся прикладывать усилия чтобы этот второй сервер смог вытащить из объекта какие-то данные.
У нас и понимание одних и тех же слов одного и того же языка подчастую отличается между людьми, что уж говорить про "мыслеформы".
За деньги-то можно хоть десяток дипломов одновременно приобрести.
Путём настоящего обучения, в теории, тоже можно получать одновременно больше одного образования, но это будет занимать очень много времени, негативно будет влиять на качество каждого образования (если области не смежные), и оттого почти никто на слуху так не делает.
масса людей, принявших участие в тамошней дискуссии считают багом
Ок, миллионы людей несогласны. Но вы опять забыли про бульонстандарт языка, в котором это описывается как неопределённое поведение. Неопределённое поведение — это баг стандарта, а не компилятора. В Конституции, кстати, — тоже.
Продолжают изобретать какие-то сайты ...[хотя]… уже давно вынесено окончательное решение и «баг закрыт» с пометкой WontFix
Ну так это типичное поведение несогласных, кстати. Вплоть до попытки эскалации и даже соответствующего изменения стандарта, если будет нужно. Здесь главное — показывать, что проблема всё ещё существует, ведь на "другой" стороне тоже люди. Даже количество WontFix в трекере — повод для кого-то рано или поздно заняться решением этой проблемы.
Правда с WontFix не закрыли
В таком случае я отвергаю уже вторую и третью Вашу ссылку — ведь постоянные напоминания про этот статус делаете Вы, но примеров пока что так и не привели. Раз они приняты, то это не игнорирование стандарта, это, на секундочку, два признанных бага. А время решения говорит только о том, что есть и более срочные дела, либо что решение очень нетривиальное, и может сломать много прежде работавшего кода. Ну, или что оба бага могут на самом деле быть следствием бага в стандарте, как предполагается в комментариях под одной из Ваших ссылок.
Если стандарт языка говорит, что программа валидная, а компилятору она не нравится — придётся переписывать. И никакими истериками тут делу не поможешь.
А вот моя ссылка (и вообще весь тот сайт) говорит об обратном. Итого, Ваши слова против моих почти-вещественных доказательств. Не в Вашу пользу.
Вы можете себе — создавать какие угодно задачи
Нет, в конкретном случае основную задачу я создам не себе, а разработчикам компилятора (я тоже умею полужирным писать, видите?). А моя задача — не более чем напоминание самому себе периодически контролировать выполнение задачи основной.
Во первых компилятор — это, скорее обычный суд
Нет, в контексте текущей ветки, обычный суд — это рантайм для законов, где законы — код программы, написанный в соответствии со стандартом языка — Конституцией.
Но если ваш багрепорт завернут и скажут, что так и надо — то всё.
По ссылке UB, а не баг, потому ссылка не является аргументом. Компилятор (и суд) вправе самостоятельно решать, как работать с UB, потому что корректный сценарий в стандарте не описан. Несоответствие стандарту при этом является багом как компилятора, так и суда. Если Вы хотели возразить — возражайте по существу. Например, найдите ссылку с багом компилятора, не соответствующего стандарту, и статусом Won't Fix.
если он вынес резолюцию WontFix — то всё, можете дальше о багах не сообщать. Будут закрыты как дупликаты.
Ну, в этом случае у меня уже не останется другого выбора, кроме как заменить компилятор — настолько наплевательского отношения к понятию стандарта я терпеть не намерен. Надеюсь, Вы — тоже.
Вы не правы. Кроме компилятора есть ещё и стандарт языка, обладающий во всех спорных вопросах интерпретации кода более высоким авторитетом, чем компилятор.
Если что-то, что я написал, соответствует стандарту языка, но не компилируется, я имею полное право, как вы выразились, «встать в позу» — сообщить о баге в компиляторе (вот пример, из того, что быстро нашлось), а затем, если и компилятора другого нет, и сроки поджимают, то так и быть, временно переделать код, чтобы не вызывал проблем в ближнесрочной перспективе. Но с созданием себе задачи отслеживания починки багов в компиляторе и исправлением костылей после починки.
Раз уж вы сравниваете конституционный суд с компилятором, почему вы постулируете его как идеальный компилятор, с нулевым количеством багов?
Главное в авторитете Имярека то, что он — консультант. И компания его крупная, что (как бы) означает, что там некомпетентных консультантов не держат. А вот какая именно это компания — неважно (на самом деле важно, но именно тут имеет второстепенное значение).
Имярека вне компании не вставляют потому, что такой имеет авторитета. Ибо на заборе тоже написано.
Касаемо споров, конкретно про интерфейсы в Spring:
Spring рекомендует интерфейсы потому, что очень любит реализовывать работу AOP pointcut'ов через прокси. И сами аспекты в Spring — это тоже компоненты, в общем-то, и у аспектов могут быть зависимости от других компонентов Spring из вашего контейнера. Но это если есть интерфейс, который можно проксировать.
Если же интерфейса нет, то AOP необходимо настраивать через compile-time weaving, а в таком режиме декларирование аспектов компонентами Spring работает через одноместо.
Уверен, что по остальным спорным вопросам тоже можно что-то такое нарыть, чтобы подсветить во вкусовщине не только то, что этот подход рекомендуется теми-то, но и конкретные минусы и плюсы. Я замечаю за собой некое поведение и идеи, присутствующие антигерою статьи, и против меня такой подход довольно часто срабатывал.
Зачем чемоданы с аккумуляторами? Одного аккумулятора в самом устройстве разве не хватит? А что если это будет только средство отображения, а основное устройство будет плюс/минус современным смартфоном?
В чём, собственно, проблема-то? Если на рынке нет новинок — значит, имеющийся спрос удовлетворён. В данном конкретном случае (так как речь идёт о языке — инструменте для решения неких задач бизнеса), это значит, что это не платформа стагнирует — это принципиально новых проблем у бизнеса не появляется, а существующих инструментов с лихвой хватает на good-enough решение. Проблемы конкретно в Java сконцентрированы на самой передовой, где действительно есть запросы бизнеса, например, обработать запросов ещё на миллион (но лучше — десять) в секунду больше, чем сейчас. Вот на этой целине сейчас действительно бурления, от новых фреймворков до языков или кастомных сборок виртуальных машин. Даже хорошо забытые парадигмы программирования прикручивают.
Новинки ради новинок действительно просто из принципа не будут пользоваться широким спросом, ну просто из соображений абзацем выше. Меня вот, наоборот, настораживает такая бешеная гонка во фронте — если у бизнеса особо нет принципиально новых проблем на бекенде, то их, вероятно, примерно столько же и на фронтэнде. Но тогда получается, что всё это бурление происходит уже не по запросу бизнеса. А если принять во внимание, что с моей бекендовой колокольни видно, главным образом, прогресс инструментов сборки, то просто получается, что там одни программисты решают проблемы других программистов, параллельно создавая десятки слоёв протекающих абстракций, чем обеспечивают новый цикл решения уже новых проблем с протеканием, которые затыкаются ещё парой слоёв абстракций и
goto 10.Тогда получается проблема стандартная, типоразмера "яйцо и курица": если не чинить косяки в новых версиях (хотя бы в 11, раз уж на то пошло, LTS всё-таки) — то все клиенты так и будут сидеть на 8, и никто их оттуда не сгонит. Не то чтоб это что-то плохое, но вроде в противодействие такому сидению Java и начала проводить такую агрессивную политику EOL в релизах — а значит какие-то причины были.
Давайте я вам цитатой из статьи отвечу:
Здесь имеем:
Упрощая пассаж из списков наверху мы и придём к фразе:
Для этого нам всего лишь потребуется проигнорировать фазу борьбы одних "других" против других "других", и сосредоточиться только на сражении "других" против "мы". Основания для игнорирования нам даёт в целом позиция различных расовых активистов, согласно которой расизмом называют только расизм со стороны "белых" по отношению к "цветным" — а "цветные" по отношению к "белым" расистами быть не могут, так как "белые" это всё "заслужили веками колониализма".
С деревом шансы куда выше.
Но также нужно помнить, что большинство программистов не столько пишет новый код, сколько читает старый и ищет в нём баги, а тут без причинно-следственных связей никак — ведь, как правило, у клиента что-то посчиталось неверно не просто потому, что именно в расчёте что-то неправильно (там как раз всё может быть идеально), а из-за условной гонки с какой-то другой частью системы, да ещё и сравнительно давно (по меркам компьютера), в результате чего данные записались в базу фрагментированными. И т.д., и т.п.
Даже написание кода требует в некотором смысле навыков выстроения цепей причинно-следственных связей — это нужно для понимания, какие API мне следует дёрнуть и в каком порядке, чтобы у клиента стало всё хорошо.
Для самого нижнего уровня квалификации в профессии эти навыки куда менее актуальны, но вроде бы в ветке и разговор шёл про «хороших программистов».
String::equalsуже по умолчанию использует сравнение по указателю для производительности, как в Oracle JDK, так и в Open JDK и «даже» в Android JDK. Если сорить такими сравнениями ещё и за пределамиequals, в собственном коде, то статистически максимальный выигрыш будет стремиться к стоимости вызова единственного метода. Стоит ли овчинка выделки с учётом всей машинерии внутри — вопрос более чем открытый.Если попытаться передавать сразу вашу изначальную мысль, то общий процесс будет аналогичен описанному вами же процессу написания софта под конкретный экземпляр компьютера. Ваша "сырая" мысль для любого другого человека будет бессмысленным набором импульсов, потому что у вас и у кого угодно ещё набор трансформаций от мысли к сообщению в терминах общего языка будет разным. Это как два сервера, где у одного — приложение на Ruby, а у второго — на C++, и по меньшей мере странно ожидать, что произвольный объект с первого сервера можно скопировать на второй и при этом не придётся прикладывать усилия чтобы этот второй сервер смог вытащить из объекта какие-то данные.
У нас и понимание одних и тех же слов одного и того же языка подчастую отличается между людьми, что уж говорить про "мыслеформы".
За деньги-то можно хоть десяток дипломов одновременно приобрести.
Путём настоящего обучения, в теории, тоже можно получать одновременно больше одного образования, но это будет занимать очень много времени, негативно будет влиять на качество каждого образования (если области не смежные), и оттого почти никто на слуху так не делает.
Ок, миллионы людей несогласны. Но вы опять забыли про
бульонстандарт языка, в котором это описывается как неопределённое поведение. Неопределённое поведение — это баг стандарта, а не компилятора. В Конституции, кстати, — тоже.К слову, как раз в комментариях под статьёй мнения разделились.
Ну так это типичное поведение несогласных, кстати. Вплоть до попытки эскалации и даже соответствующего изменения стандарта, если будет нужно. Здесь главное — показывать, что проблема всё ещё существует, ведь на "другой" стороне тоже люди. Даже количество WontFix в трекере — повод для кого-то рано или поздно заняться решением этой проблемы.
В таком случае я отвергаю уже вторую и третью Вашу ссылку — ведь постоянные напоминания про этот статус делаете Вы, но примеров пока что так и не привели. Раз они приняты, то это не игнорирование стандарта, это, на секундочку, два признанных бага. А время решения говорит только о том, что есть и более срочные дела, либо что решение очень нетривиальное, и может сломать много прежде работавшего кода. Ну, или что оба бага могут на самом деле быть следствием бага в стандарте, как предполагается в комментариях под одной из Ваших ссылок.
А вот моя ссылка (и вообще весь тот сайт) говорит об обратном. Итого, Ваши слова против моих почти-вещественных доказательств. Не в Вашу пользу.
Нет, в конкретном случае основную задачу я создам не себе, а разработчикам компилятора (я тоже умею полужирным писать, видите?). А моя задача — не более чем напоминание самому себе периодически контролировать выполнение задачи основной.
Нет, в контексте текущей ветки, обычный суд — это рантайм для законов, где законы — код программы, написанный в соответствии со стандартом языка — Конституцией.
По ссылке UB, а не баг, потому ссылка не является аргументом. Компилятор (и суд) вправе самостоятельно решать, как работать с UB, потому что корректный сценарий в стандарте не описан. Несоответствие стандарту при этом является багом как компилятора, так и суда. Если Вы хотели возразить — возражайте по существу. Например, найдите ссылку с багом компилятора, не соответствующего стандарту, и статусом Won't Fix.
Ну, в этом случае у меня уже не останется другого выбора, кроме как заменить компилятор — настолько наплевательского отношения к понятию стандарта я терпеть не намерен. Надеюсь, Вы — тоже.
Если что-то, что я написал, соответствует стандарту языка, но не компилируется, я имею полное право, как вы выразились, «встать в позу» — сообщить о баге в компиляторе (вот пример, из того, что быстро нашлось), а затем, если и компилятора другого нет, и сроки поджимают, то так и быть, временно переделать код, чтобы не вызывал проблем в ближнесрочной перспективе. Но с созданием себе задачи отслеживания починки багов в компиляторе и исправлением костылей после починки.
Раз уж вы сравниваете конституционный суд с компилятором, почему вы постулируете его как идеальный компилятор, с нулевым количеством багов?
Имярека вне компании не вставляют потому, что такой имеет авторитета. Ибо на заборе тоже написано.
Spring рекомендует интерфейсы потому, что очень любит реализовывать работу AOP pointcut'ов через прокси. И сами аспекты в Spring — это тоже компоненты, в общем-то, и у аспектов могут быть зависимости от других компонентов Spring из вашего контейнера. Но это если есть интерфейс, который можно проксировать.
Если же интерфейса нет, то AOP необходимо настраивать через compile-time weaving, а в таком режиме декларирование аспектов компонентами Spring работает через одно место.
Уверен, что по остальным спорным вопросам тоже можно что-то такое нарыть, чтобы подсветить во вкусовщине не только то, что этот подход рекомендуется теми-то, но и конкретные минусы и плюсы. Я замечаю за собой некое поведение и идеи, присутствующие антигерою статьи, и против меня такой подход довольно часто срабатывал.