>А для того чтобы код что-то делал, он должен быть интегрирован с уже существующим, в самом максимально сном случае хотя бы начиная с системы команд процессора которую не ты придумал.
Интеграция кода и написание кода - разные стадии, нет?
А то так нам конечно надо скомпилировать код (по факту, сказать машине переписать его в другой вид), слинковать код (уложить его в определенные структуры данных в условно файле), далее, возможно, включить код в какие-то иные объектные файлы (скажем, пресловутый shared object), для которых нам надо составить целую инфраструктуру динамического загрущщика, которую уж подавно не мы придумали и шатать не будем без особой необходимости, ибо мы какбе хотим переносимость, чтобы "код что-то делал", лол.
Но все же это не относится к написанию кода. Можно отнести это к "программированию" в целом, конечно.
>придется через чрезмерно сложный HTTP/2
Не придется, лол. Кстати, я так и не понял, в чем выигрыш, а Poul-Henning Kamp так вообще говорит, что это провал.
https://queue.acm.org/detail.cfm?id=2716278
>с написанного с использованием системы контроля версий и слинкованным с libc/bionic/winapi браузером
Меня не устраивают качество кода, архитектура и набор фичей ни одного из известных мне браузеров, и я ищу еще. Если не найду, придется написать еще один никому не нужный.
>с ядром разрабатываемом в гите или svn
Количество регрессий в коде линукса перевалило для меня комфортный порог. В смысле, лично меня беспокоят баги, над которыми чешут репу девы уже не первый год. Конечно, наивно связывать это с наличием/отсутствием git, оно скорее помогает найти коммит, вносящий регрессию. Но то, что в линуксе за 10кк строк кода (или сколько там уже) явно не помогает ситуации.
>TUI зародился не от религиозного аскетизма, а из прагматичной экономии
Аскетизм не религиозен и не "тру", это вполне себе "прагматичная экономия".
Технологии призваны сделать жизнь проще, а если они что-то усложняют, то за это кто-то заплатит. Бессонными ночами отладки, ненадежными, медленными системами с непонятными проблемами или как-то еще.
>Почему средства разработки не должны эволюционировать вслед за решаемыми ими задачами?
Потому что задача "написания кода" не особо поменялась, например.
Но вообще, речь скорее о целесообразности того или иного нововведения, чем о том, интегрировать ли индексацию поиска в ide или нет.
Скажем, удобный поиск для греп можно зделать, внося определенные требования к структуре проекта (например, оформлять каждую функцию в отдельном файле). Конечно, ide будет более универсальной, но это просто как пример того, как можно подходить к вопросу.
Можно возразить, что кому-то, мол, надо работать, и работать с тем, что уже есть, и, ну, примерно это я имел в виду, говоря о "смене профессии". Не то, чтобы деятельность по поиску в 500 Мб кода была прям настолько кошмарной, но на мой взгляд, сама необходимость сего понижает продуктивность каждого вовлеченного в процэсс. А еще бывает, что один программист уходит с работы, где он годами поддерживал кодовую базу, и на его место приходит другой, совершенно с ней незнакомый, а база большая, багованная, криво написана, да и вообще для работы с ней ее по-любому надо знать. Развлечение на месяцы, если не на пару лет. Продуктивно? Нет. Инструменты помогут? Да, но минимально. Пример надуманный? Нет, и можно накидать еще большИх кодовых баз, в которых проблемы чинятся месяцами, попутно внося новые (mozilla firefox, лол). Скажешь, ошибаться нормально? Соглашусь, но когда цена ошибки становится настолько высокой, у миня прям стресс.
