другие говорят, что код — это то, что написано руками
придумали глупость и приписали другим, отличный реторический прием. Код можно писать хоть задницей, важно кто модель этого кода создает - разработчик у себя в голове, или LLM. Если бы был способ быстро перегрузить созданную в голове разработчика модель в LLM, то и спора бы не было - никто же не спорит о полезности, например, зоны Брока. В таком случае это действительно был бы просто новый, очень полезный инструмент.
Скорость развития детёнышей многих видов обезьян также превышает скорость развития человека, примерно до 3 лет. Взрослые особи на этом уровне развития в итоге и остаются.
Кажется вы путаете "кандидаты особо не нужны" с "какие попало кандидаты не нужны" - то что рынок завален кандидатами пишущими хелловорд и идущими собеседоваться на позиции миддл+ (ещё и пытающимися в процессе собеседования использоваться нейронки/друга на телефоне) увы но правда.
Проблема ли это для кандидатов которые нормально оценивают свой уровень? увы но да - их искать тяжело т.к. неадекватные кандидаты создают нагрузку на собеседующих
У вас ошибка в сравнении - если вы хотите сравнивать то что было и то что сейчас, то надо сравнивать близкое/идентичное по функционалу. Большая хрупкость современных телефонов по сравнению со старыми в их несопастовимо более высокой сложности, а сложность продиктована принципиально изменившимися требованиями к функциональности. Вы же берете не коррелирующую со сложностью (однозначно одной из важных причин большей хрупкости) метрику - стоимость, и назначаете ее эталоном тождественности старого и нового устройства, по законам логики в такой ситуации получаете неизвестно что - из лжи может следовать и истина и ложь.
Кажется я вам привел пример не относящийся к перечисленным вами и в котором "потолок" такой что не многие дотягиваются - это первое что вспомнилось, такого реально много, сильно больше чем описываемые вами отрасли. Для того чтобы ваш посыл звучал сколько-нибудь истинно нужно его трансформировать в "Не на каждом производстве нужен высококласный инженер" - с таким было бы трудно спорить.
Попытка поднять "потолок" в задаче уже оптимизированной под конкретные условия, диктуемые обстоятельствами в которых задача выполняется, почти всегда обречена на провал - понятно что никто не хочет своими деньгами рисковать. Если хотите высокий "потолок" в производстве мебели то вам в космос, на Луну/Марс, возможно на Северный Полюс или под воду - там условия решения задачи иные, большой простор для изобретения новых способов производства мебели.
Так потому и не делают - это дополнительная работа, малейшая ошибка в которой приведет к провалу - не встанет шкаф на 2мм и привет. Мебель все равно приедет разобранной, иначе в квартиру нормально не внесешь. Вот и выбирайте что вам - риск переделывать и возить по 10 раз, при точных размерах прямо со станка, или допуски и 5 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.
Страшная тайна про кухни - их собирают с применением доработки лобзиком потому что помещения в которые их ставят неидеальны - углы не 90 градусов, стены не идеально ровные, и т.д. Чтобы сделать кухню точно под место нужно делать точную 3d модель помещения - в этот момент разговоры про то что нынешний процесс трудоемок идут в утиль.
Кроме того у вас ошибка в терминологии: кустарное производство - это если бы вам при привозили на объект лист ДСП, оргалит, и дальше вы бы из него все выпиливали, когда у вас приезжает набор деталей некоторые из которых нужно подогнать по-месту это НЕ кустарное производство
Вцелом насчет статьи - посыл даже не лежит в направлении истины. Простой пример - телеком-оборудование вы не упомянули в списке, а задачи разработки базовых станций требуют весьма высоких инженерных навыков. Это далеко не единственное что можно вспомнить, но с учётом вашей жесткой риторики, возведения местечкового наблюдения уровня "не везде серьезные инженеры нужны" в абсолют данного примера достаточно чтобы показать ложность вашего утверждения.
Я понятия не имею что у автора решения в программе, я только о том говорю, что сам по себе факт наличия какого-то подхода к решению не должен и не может служить доводом в пользу того, что новые подходы невозможны, или априори хуже (при условии что подходы действительно новые, конечно).
Любое решение - велосипед, просто некоторые постарше
Ваше предложение сейчас выглядит "делай так потому что как деды, а раз не как деды - значит велосипед", наличие некоторого проверенного подхода к решению никак не говорит о том что этот подход лучший, надо сравнивать результаты.
Если речь об этом то это не у Postgres что-то аппаратно отработано, а Postgres может использовать платформозависимые команды для ускорения определенных операций.
Отдельно хочется сказать про то что "оптимально" это вроде как превосходная степень, поэтому "очень оптимально" не бывает.
Мне кажется в постановке задачи ошибка - квадрат должен иметь равные стороны, а в условии речь про прямоугольник, судя по описанию размера N*M и отсутствию ремарки что N=M.
Я вот все еще не понял, почему выброс исключения это кишки наружу? потому что вы изначально о требовании "температура не более 273.15" не написали? ну какбы проблема тогда ищется не там.
Не нравится вам исключение - напишите обертку над double, которая будет представлять собой число double гарантированно укладывающееся в требуемый диапазон, и принимайте в сеттере ее.
Вам в любом случае нужно предоставлять какие-то рамки использования для потребителей вашей библиотеки - если любые рамки это "кишки наружу" то кажется вы ситх.
т.е. вы на полном серьезе считаете, что делать функцию принимающую разные типы аргументов, и разгребающую вопросы "чтоже мне дали" и "а не null ли там" это лучше и удобнее чем всегда по контексту знать тип и быть уверенным что это не null?
А можно чуть подробнее физическую составляющую процесса передачи тепла? Раз вы говорите что у вас 60 градусов в котле, то получается на вход (после теплообменника) ваши устройства майнинга получают воду с температурой 60 градусов? Им так нормально работается?
лучше чем считать чужие возможности что-то развивать для всех обычно получается только считать чужие возможности что-то развивать для себя
придумали глупость и приписали другим, отличный реторический прием. Код можно писать хоть задницей, важно кто модель этого кода создает - разработчик у себя в голове, или LLM. Если бы был способ быстро перегрузить созданную в голове разработчика модель в LLM, то и спора бы не было - никто же не спорит о полезности, например, зоны Брока. В таком случае это действительно был бы просто новый, очень полезный инструмент.
плохой перевод, как будто остальные типы незначимые - по приколу делаются и значимости не несут
правильнее по-русски этот тип называть "объект-значение", нет лишних смыслов от прилагательного "значимый"
Скорость развития детёнышей многих видов обезьян также превышает скорость развития человека, примерно до 3 лет. Взрослые особи на этом уровне развития в итоге и остаются.
Так проблемы и нет, при условии что вы хотите именно за требуемое эти деньги получать, проблема возникает когда эти деньги хотят получать за хелловорд
Кажется вы путаете "кандидаты особо не нужны" с "какие попало кандидаты не нужны" - то что рынок завален кандидатами пишущими хелловорд и идущими собеседоваться на позиции миддл+ (ещё и пытающимися в процессе собеседования использоваться нейронки/друга на телефоне) увы но правда.
Проблема ли это для кандидатов которые нормально оценивают свой уровень? увы но да - их искать тяжело т.к. неадекватные кандидаты создают нагрузку на собеседующих
У вас ошибка в сравнении - если вы хотите сравнивать то что было и то что сейчас, то надо сравнивать близкое/идентичное по функционалу. Большая хрупкость современных телефонов по сравнению со старыми в их несопастовимо более высокой сложности, а сложность продиктована принципиально изменившимися требованиями к функциональности. Вы же берете не коррелирующую со сложностью (однозначно одной из важных причин большей хрупкости) метрику - стоимость, и назначаете ее эталоном тождественности старого и нового устройства, по законам логики в такой ситуации получаете неизвестно что - из лжи может следовать и истина и ложь.
Кажется я вам привел пример не относящийся к перечисленным вами и в котором "потолок" такой что не многие дотягиваются - это первое что вспомнилось, такого реально много, сильно больше чем описываемые вами отрасли. Для того чтобы ваш посыл звучал сколько-нибудь истинно нужно его трансформировать в "Не на каждом производстве нужен высококласный инженер" - с таким было бы трудно спорить.
Попытка поднять "потолок" в задаче уже оптимизированной под конкретные условия, диктуемые обстоятельствами в которых задача выполняется, почти всегда обречена на провал - понятно что никто не хочет своими деньгами рисковать. Если хотите высокий "потолок" в производстве мебели то вам в космос, на Луну/Марс, возможно на Северный Полюс или под воду - там условия решения задачи иные, большой простор для изобретения новых способов производства мебели.
Так потому и не делают - это дополнительная работа, малейшая ошибка в которой приведет к провалу - не встанет шкаф на 2мм и привет. Мебель все равно приедет разобранной, иначе в квартиру нормально не внесешь. Вот и выбирайте что вам - риск переделывать и возить по 10 раз, при точных размерах прямо со станка, или допуски и 5 минут ручной работы на месте.
Вы похоже не инженер а математик - инженерия она прикладная, с реалиям физического мира жестко связана, а у вас идет игнорирование окружающего.
Страшная тайна про кухни - их собирают с применением доработки лобзиком потому что помещения в которые их ставят неидеальны - углы не 90 градусов, стены не идеально ровные, и т.д. Чтобы сделать кухню точно под место нужно делать точную 3d модель помещения - в этот момент разговоры про то что нынешний процесс трудоемок идут в утиль.
Кроме того у вас ошибка в терминологии: кустарное производство - это если бы вам при привозили на объект лист ДСП, оргалит, и дальше вы бы из него все выпиливали, когда у вас приезжает набор деталей некоторые из которых нужно подогнать по-месту это НЕ кустарное производство
Вцелом насчет статьи - посыл даже не лежит в направлении истины. Простой пример - телеком-оборудование вы не упомянули в списке, а задачи разработки базовых станций требуют весьма высоких инженерных навыков. Это далеко не единственное что можно вспомнить, но с учётом вашей жесткой риторики, возведения местечкового наблюдения уровня "не везде серьезные инженеры нужны" в абсолют данного примера достаточно чтобы показать ложность вашего утверждения.
Я понятия не имею что у автора решения в программе, я только о том говорю, что сам по себе факт наличия какого-то подхода к решению не должен и не может служить доводом в пользу того, что новые подходы невозможны, или априори хуже (при условии что подходы действительно новые, конечно).
Любое решение - велосипед, просто некоторые постарше
Ваше предложение сейчас выглядит "делай так потому что как деды, а раз не как деды - значит велосипед", наличие некоторого проверенного подхода к решению никак не говорит о том что этот подход лучший, надо сравнивать результаты.
Если речь об этом то это не у Postgres что-то аппаратно отработано, а Postgres может использовать платформозависимые команды для ускорения определенных операций.
Отдельно хочется сказать про то что "оптимально" это вроде как превосходная степень, поэтому "очень оптимально" не бывает.
Вроде было уже очень похожее: https://habr.com/ru/articles/880392/
Мне кажется в постановке задачи ошибка - квадрат должен иметь равные стороны, а в условии речь про прямоугольник, судя по описанию размера N*M и отсутствию ремарки что N=M.Понятно, я просто плохо прочитал условие :)
Я вот все еще не понял, почему выброс исключения это кишки наружу? потому что вы изначально о требовании "температура не более 273.15" не написали? ну какбы проблема тогда ищется не там.
Не нравится вам исключение - напишите обертку над double, которая будет представлять собой число double гарантированно укладывающееся в требуемый диапазон, и принимайте в сеттере ее.
Вам в любом случае нужно предоставлять какие-то рамки использования для потребителей вашей библиотеки - если любые рамки это "кишки наружу" то кажется вы ситх.
Ту самую известную, которая "самая большая в мире"?
т.е. вы на полном серьезе считаете, что делать функцию принимающую разные типы аргументов, и разгребающую вопросы "чтоже мне дали" и "а не null ли там" это лучше и удобнее чем всегда по контексту знать тип и быть уверенным что это не null?
А можно чуть подробнее физическую составляющую процесса передачи тепла? Раз вы говорите что у вас 60 градусов в котле, то получается на вход (после теплообменника) ваши устройства майнинга получают воду с температурой 60 градусов? Им так нормально работается?
Это вроде как обеспечил GraalVM уже несколько лет назад