Если бы у них был интеллектуальный потенциал, то они бы пошли учиться не на программиста, а автомеханика / водопроводчика / слесаря. И имели 150К/год с тремя годами опыта и выплаченными долгами, пока их сверстники только заканчивают вуз с огромным кредитом за образование и туманными перспективами.
Платят то не за интеллектуальный потенциал, а за выполненую работу.
Не важно где он будет, пока ни в одной из сфер, которую он призван изменить, производительность умственного труда не будет сдерживающим фактором. А она нигде им не является. Ну будет в 10 раз больше софта, раньше 90% процентов не было востребовано, а будет 99%. Производительность в сельском хозяйстве за 150 лет выросла в 100 раз. Но человек не стал в 100 раз больше есть. Так же и с ИИ, человек не сможет смотреть рекламу 40 часов в день. Или покупать 20 пар джинс, даже если Сидни Суинни их на голову оденет. А без этого 90% разработчиков не нужно уже сейчас.
В разработке не было спроса на производительность, а причин думать, что вырастет качество разработки от новых поколений сеток Клода или ЧатаГПТ пока нет совсем.
В Java проверка на равенство строковой константе обычно выглядит как
"value".equals(variable)
что тоже выглядит странно для разработчиков на других языках. Равно как тройное сравнение в JS со всем кроме null, и простыня из сравнений с err != nil в Go. Но те кто регулярно пишет на обсуждаемом языке привыкли к этому и им удобно.
Так себе сравнение, инвертор никакой безопасности не добавляет.
И в целом наличие электронного управления двигателей и низкая ремонтопригодность признак консьюмерской техники в целом и китайского говна в особенности.
На нормальную профессиональную техника всегда и запчасти есть, и ремонтопригодность у неё обычно сильно выше, чем у потребительской. И это касается всего от кофемашин и плит до холодильных установок. Так что не Мерседес в ВАЗ, а Черри в Тойоту.
Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние).
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
На него переходили из-за большего числа каналов, которых там много из-за лучшей поддержки их функционала для авторов. То есть дело как раз в функционале, а не скорости.
Специалисты по интерфейсам, дизайну и эргономике видят изъяны везде вокруг — в интерфейсе даже обычной кофемашины.
При том, что большинство нормальных кофемашин собирается на одном из двух заводов одного и того Eughster/Frismag, и за редким исключением используют их же конструкции заварочных блоков.
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.
Если бы у них был интеллектуальный потенциал, то они бы пошли учиться не на программиста, а автомеханика / водопроводчика / слесаря. И имели 150К/год с тремя годами опыта и выплаченными долгами, пока их сверстники только заканчивают вуз с огромным кредитом за образование и туманными перспективами.
Платят то не за интеллектуальный потенциал, а за выполненую работу.
Не важно где он будет, пока ни в одной из сфер, которую он призван изменить, производительность умственного труда не будет сдерживающим фактором. А она нигде им не является. Ну будет в 10 раз больше софта, раньше 90% процентов не было востребовано, а будет 99%. Производительность в сельском хозяйстве за 150 лет выросла в 100 раз. Но человек не стал в 100 раз больше есть. Так же и с ИИ, человек не сможет смотреть рекламу 40 часов в день. Или покупать 20 пар джинс, даже если Сидни Суинни их на голову оденет. А без этого 90% разработчиков не нужно уже сейчас.
В разработке не было спроса на производительность, а причин думать, что вырастет качество разработки от новых поколений сеток Клода или ЧатаГПТ пока нет совсем.
А почему они должны вести себя лучше?
Кому должны? Работадателя должна волновать прибыль предприятия. Сотрудника — зарплата.
В Java проверка на равенство строковой константе обычно выглядит как
что тоже выглядит странно для разработчиков на других языках. Равно как тройное сравнение в JS со всем кроме null, и простыня из сравнений с err != nil в Go. Но те кто регулярно пишет на обсуждаемом языке привыкли к этому и им удобно.
Рентабельность ИИ-разработок Google и Microsoft тоже пока под большим вопросом.
Так себе сравнение, инвертор никакой безопасности не добавляет.
И в целом наличие электронного управления двигателей и низкая ремонтопригодность признак консьюмерской техники в целом и китайского говна в особенности.
На нормальную профессиональную техника всегда и запчасти есть, и ремонтопригодность у неё обычно сильно выше, чем у потребительской. И это касается всего от кофемашин и плит до холодильных установок. Так что не Мерседес в ВАЗ, а Черри в Тойоту.
А вот тогда человечество точно вымрет.
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Вообще у многих операций выживаемость ниже.
Грок, сначала запости мнение хозяина в википедию, а потом ссылайся!
В Танки.Оффлайн
Собирает Jura точно также Eughster/Frismag
На него переходили из-за большего числа каналов, которых там много из-за лучшей поддержки их функционала для авторов. То есть дело как раз в функционале, а не скорости.
Скрытый текст
Я использую такой способ даже с запросами из Курсора:
включаю правила на примение всех изменений и запрещаю Клоду трогать комманды гит (это можно один раз в правила прописать)
добавляю все файлы в staging перед запросом Интерфейс просмотра изменений через гит-лесс мне тупо больше нравится, в сравнение с курсоровским.
Конечно не совпадение! Ведь 60% попрежнему клепают разработчики MS!
У которого то соединенние по несколько секунд не отвечает, то переводы по несколько дней не работают.
При том, что большинство нормальных кофемашин собирается на одном из двух заводов одного и того Eughster/Frismag, и за редким исключением используют их же конструкции заварочных блоков.
Как будто на бэке какая-та среда исполнения понимает Java или C#. Максимум — JVM / CLR Bytecode. Я уж не говорю о разработчиках C++ / Go / Rust, которые как-то с набором инструкций AMD64 обходятся. Поддержка языка на уровне браузера нужна только для дебагера, где она вполне себе есть.