И да, и нет. Пока программисты нарасхват, программировать будут дети, домохозяйки и сумасшедшие. Поэтому фреймворки, облегчающие программирование, по-прежнему будут нарасхват. Стало быть, особой оптимизации кода ждать не приходится, приходится ждать аппаратной поддержки фреймворков в процессорах. Разумеется, в критически важных задачах, где денег на программистов не жалеют, код будет улучшаться и оптимизироваться.

физические ограничения могут заставить нас

А могут и не заставить, делов-то.

Пока программисты нарасхват, программировать будут дети, домохозяйки и сумасшедшие.

Причина имхо не в этом, а в том сколько проектов по написанию спроса обеспечены платёжеспособным спросом достаточным для выплаты зарплаты высококвалифицированному программисту?

Да, это тоже важный аспект. Низкоуровневые вещи в процессорах сейчас очень сложные, комплексные, и квалифицированный программист, умеющий всё это, стоит очень дорого

Комментарий от evocatus

Я разработчик для ПЛИС. Практически в каждом достаточно сложном проекте в состав конфигурации FPGA входит ARM-ядро (Microblaze). А сейчас Intel и Xilinx выпускаются гибриды — ARM + FPGA на одном кристалле.

Потому что делать на конечных автоматах то, что можно написать на Си — нерационально. Быстрее разработка, легче отладка, меньше ошибок, кушает меньше ресурсов. Потому что у FPGA конечное число логических вентилей и ЛЮБОЙ кусок логики или необходимость помнить что-то (если только не используется внешняя память — а DDR3 на платах с FPGA часто встречается) расходует эти ресурсы. Более того — с приближением к этому лимиту сильно возрастает сложность задачи по разводке схемы, она может даже не развестись с нужными скоростными характеристиками. Дешёвые FPGA стоят совсем недорого, каждый купить может какой-нибудь Microzed, а быстрые стоят тысячи долларов. А для серьёзных задач нужны быстрые. Реализовать процессор на FPGA можно, только вы получите 32-битный медленный аналог CPU 20-летней давности за сумасшедшие деньги. FPGA адекватны только для особого спектра задач, например для высокоскоростной потоковой обработки данных, когда вы пишете несколько конечных автоматов, на выходе будет стоять, скажем IP-ядро контроллер Ethernet MAC-уровня, а если есть несколько тысяч долларов и лишние ресурсы, то можно даже сделать TCP/IP. Но для такой задачи нужно разработать свою печатную плату (а иногда не одну), произвести её (это очень дорого по сравнению с любыми Xeon)

А ещё область разработки для FPGA — это заповедник проприетарщины. Честно, тут нечему завидовать. Тут ситуация как в разработке ПО до появления Open Source — платные «компиляторы» и пр.

И чтобы 2 раза не вставать: нет, квантовые компьютеры никогда не заменят обычные. Они работают по совершенно другому принципу, для них известно всего пара десятков очень узконаправленных алгоритмов и максимум, что их ждёт — роль сопроцессоров для спец. вычислений (криптография, некоторые области математики и пр.). Если удастся создать квантовый компьютер с достаточным числом кубитов (а вероятность этого экспоненциально уменьшается с каждым новым кубитом)

Надо вбухивать деньги в разработку оптических транзисторов!

Надо платить деньги за сокращение кода, библиотек и проч.

Действительно надо?

В каких именно программах и при каких условиях неоптимальный код доставляет даже не существенные, а хоть какие-то неудобства?

не заставят, просто все начнут как в гноме3 - резать ф-л. в итоге нужен будет мегакластер чтобы plain text заметку сделать в однобайтовой кодировке, хотя когда то для этого сраного 8bit CPU с килобайтами RAM хватало. Зато пока ты будешь писать заметку, ее прочитают все - от спецслужб, до местнячкового рекламного агенства ооо «шайтан эдвертисмент литиды». а с каждой новой версией интерфейс будет становится более плоским и «правильным» и использовать все возможности хардварного рендеринга твоей GPU с over512 ядрами.

сумасшедшие

Поскорей бы свихнуться и начать программировать :(

физические ограничения могут заставить нас вернуться к более скромному варианту кода, которым мы пользовались в прошлом

Иншаллах!

проектов по написанию спроса

Написанию чего?

В каких именно программах и при каких условиях неоптимальный код доставляет даже не существенные, а хоть какие-то неудобства?

Долго занимался тестированием одного проприертарного пакета. По причине низкой скорости не было возможности нормально проверять все распространённые комбинации входных данных. В результате у клиентов программы часто падали. Когда скорость импорта повысили в 10-50 раз, код удалось покрыть тестами, которые есть возможность прогонять каждые сутки. И падений стало меньше.

Фреймворки тоже можно оптимизировать.

Фреймворки тоже можно оптимизировать.

Да, но они не домохозяйками писаны. Т.е. уже достаточно оптимальны (я надеюсь).

Да, но они не домохозяйками писаны. Т.е. уже достаточно оптимальны (я надеюсь).

ты не поверишь … но это не так.

это опечатка, правильно

проектов по написанию кода

Так это неудобство тестировщика, а не пользователя.

Вопрос в том, что невозможно оптимизировать под всё сразу, поэтому будет больше разных фреймворков, оптимизированных под конкретный пользовательский опыт.

Например, мобильные телефоны сейчас имеют колоссальные объёмы RAM (гигабайты, в самсунг с20 будет до 16gb ram), но слабый процессор (потому что батарейку нужно экономить). При этом пользователь ждёт моментального отклика. Если время реакции веб-страницы может быть пару секунд и к этому все привыкли, то в мобильном устройстве отклик 500ms – это уже «лагает».

Поэтому мобильные фрейморки затачиваются на возможность работать максимально плавно с 60-120fps, сокращая время любых задержек. В свою очередь, оптимизировать потребление RAM бессмысленно.

ИМХО, нужны не новые программисты. Нужны новые программисты умеющие писать нераздутый код на нераздутых языках и фреймворках, а старых - занимающихся «формошлёпством» на всяком хипстерском говне меняющимся раз в год - надо выкидывать из профессии. Только так.

Ну, да, оптимизация в эту сторону пойдёт, безусловно. С другой стороны, и ядро будут пилить в эту же степь, и производителей прижмут, чтобы драйвера нормальные писали, а не левой пяткой правой ноги.

Настолько-ли там слабый процессор ? Я где-то точно точно видел недавно статьи с вычислительными тестами смартфонных ARM и ноутбучных (вроде) X86 процессоров. И ARM были не хуже, а где-то уже и лучше.

Нужны новые программисты

Это не при нашей жизни. Это как с настройщиками пианино: их мало, они высокооплачиваемы, и делают свою работу хорошо. Потому что пианино мало, и они на фиг не нужны среднему пользователю. Вот когда ПО будет не нужно среднему пользователю, тогда программисты начнут писать нераздутый код на нераздутых языках.

Ага ((( Полностью согласен. Так что лучше не будет, увы.

В дополнение к скорости мобильных процессоров:

После недавней статьи на хабре о LineageOS, и в преддверии эпичной феерии с установкой российских зондов программ на смартфоны, решил я тут прикупить на днях себе Motorola G7 на замену старого вендафона с которым проходил уже 7 лет.

И внезапно я обнаружил, что не топовое устройство первой половины 2019 года, которое сейчас стоит всего 10 тысяч рублей (и это у нас, со всеми поборами), выдаёт отличнейшие циферки в вычислительных бенчмарках. Добавить-бы в такой чип хорошую аппаратную виртуализацию (и её поддержку в софте), много быстрой памяти, интерфейсы типа PCIe 3.0 - и можно вполне использовать на десктопе даже. Производительности хватит.

Даже если процессор сильный, то никто тебе не даст его использовать долго на полную мощность, потому что иначе батарейка ёк.

Это понятно. Но так-ли много на мобилках задач в которых проц используется на полную катушку долго ? И которые при этом именно «мобильные», а не вроде навигатора который всегда используется с внешним питанием.

Неудобство пользователя в том, что в медленной программе не успевают выловить регрессии. Поэтому новые версии работают всё хуже и хуже.

Нужны новые программисты умеющие писать нераздутый код на нераздутых языках

Кому нужны? Где? Сколько платить будут?

Неудобство пользователя в том, что в медленной программе не успевают выловить регрессии.

Это если программа бурно развивается, а если нужный функционал уже наработан?

ой прям вижу как все плюсовые библиотеки обрастут лямбдами, а затем для пущей экономии кода их обернут под питон, в общем заживём….

Пора призывать программистов на Си ?

Это если программа бурно развивается, а если нужный функционал уже наработан?

«Нет предела совершенству», как говорит начальник QA каждый раз, когда волевым решением завершает этап к дэдлайну. Сложный многофункциональный комбайн с тысячами пользователей не может сразу включать всё, что нужно любому. У пользователей появляются новые запросы, приходят новые пользователи с новыми запросами, старые выявляют баги. Даже все некритические баги сразу исправить времени нет. Конечно, можно оставить старых пользователей без новых фич, с одними багфиксами. Но это выходит более трудоёмко для изготовителя, и большинство пользователей готовы платить за обновление версий.

Поэтому старые пользователи получают багфиксы, все новые фичи и весь новый геморрой.

Нужны новые программисты умеющие писать нераздутый код на нераздутых языках

Кому нужны? Где?

Автору статьи.

Сколько платить будут?

Автор подразумевает, что с какого-то момента платить будут только им.

Мы приближаемся к пределу вычислительных мощностей – нам нужны новые программисты

На самом деле новые программисты нам не нужны, нужны новые и интересные задачи, опирающиеся на новые математические модели.
(Очень может быть, что убогость игровых ботов есть только следствие убогости философского содержания математической модели игр. )

А что там в этих фрейморках? На экране телефона нужна страница текста и фотка, куда эти гигабайты уходят? Сайт, сцуку, МФТИ, загрузить два десятка фоток, он 1.5 гига свопа делает.

У меня обратное впечатление от индустрии и половины компаний где я работал. Вместо того, чтобы сделать софт, который просто исполняют свою задачу и является простым и эффективным, нанятые толпы бездельников начинают воротить сложные и запутанные архитектуры, лишь бы оправдать свое существование.

нанятые толпы бездельников начинают воротить сложные и запутанные архитектуры, лишь бы оправдать свое существование.

Причём не только для проектов, но даже для сборки этих проектов. Размеры tar.gz с исходниками:

* make    4.3       2,2 МБ
* cmake   3.16.3    8,7 МБ
* ant     1.10.7    5,0 МБ
* gradle  6.1      21,8 МБ
* sbt     1.3.7    54,9 МБ
* bazel   2.0.0    67,0 МБ

make 4.3, cmake 3.16.3, ant 1.10.7, gradle 6.1, sbt 1.3.7, bazel 2.0.0

Maven:

Maven full source code is dispatched in more than 100 Git repos …

no comment

> Maven full source code is dispatched in more than 100 Git repos …
no comment

Да уж. Это уже совсем печаль.

Нет, не приближаемся. Кластеры и многопоток спасут от всех лимитов на ближайшую тысячу лет.

Оффтоп: нафига оформлять цитату как код? Чтобы читать неудобнее было?

Это как с настройщиками пианино: их мало, они высокооплачиваемы, и делают свою работу хорошо.

Только надо понимать, что в современном мультиметре есть частометр которого более чем хватает для идеальной настройки фортепьяно.

Так что настройщики ценны не столько настройкой, сколько тем что делают полное ТО и замену изношенных деталей.

Ну что поделать, если цитату оформлял домохозяин…

П.С. ладно, в будущем отнесусь аккуратнее, а не тяп ляп как проще.

Пустое сообщение.

в современном мультиметре есть частометр которого более чем хватает для идеальной настройки фортепьяно.

Пробовал? Или теоретически рассуждаешь?

Насколько я знаю, настройка струнных инструментов требует тонкого согласования частот большого числа струн. По этой причине задача настройки рояля считается неавтоматизируемой. Профессиональные настройщики исчезнут только когда синтезаторы вытеснят акустические фортепиано.

Пробовал, настраивается нота(в сумме частометром настраивается одна октава), а потом от неё строятся другие через взятие аккордов, диссонанс услышать проще чем определить абсолютную высоту ноты.

Maven full source code is dispatched in more than 100 Git repos …

Cargo - ~130. И это хорошо.

Скоро программисты станут не нужны, т.к. программы будут генерировать боты.

И как, профессионал на этом инструменте после настройки играл? Заметил разницу?

Поэтому мобильные фрейморки

оптимизировать потребление RAM бессмысленно

Большое кол-во рамы -> большие энергозатраты на удержание информации в ней. По крайне-мере на текущий момент энергонезависимой DRAM не предвидится.