Да нынче это опасно. Раньше розетки были без заземления и домашние электроприборы шли без третьего провода, хотя в древних системах был нулевой провод и 2 фазы с углом 0 и 180, между ними было как раз 220 (в американской проводке до сих пор 120/240 так с понижающего трансформатора 10 кВ) и можно было подключать всякие радиолы на 127/110В.
А батарея была идеальной землёй для детекторного приёмника, достаточно было LC-контур, германиевый диод Д18, наушники или телефонный капсюль (карболитовый такой) и вполне ловились местные ДВ/СВ станции на кусок провода длиной метров 10 из окна, нынче они все молчат за ненадобностью.
Также можно отметить, что транзисторы с изолированным затвором, например, серии КП305 поставлялись с трубочкой, которая охватывала все 4 вывода и действительно, рекомендовалось сначала обмотать выводы проволочкой перед монтажом. Главное, не забыть потом её снять.
У меня первой книгой была Рудольф Сворень Электроника шаг за шагом, отличное издание для начинающих. И потом конечно журналы Радио, Массовая радиобиблиотека МРБ
Вот, это ключевой момент который в принципе тормозит весь прогресс из разряда "данные это код" Since 1958 by LISP. ИИ-помощник не меньшая дыра если не следить, туда же внешние макросы и прочие make, куда можно прилинковать напрямую любой код, качнув его по wget. Это что касается этапа построения. Что же до рантайма то должны быть способы для создания подобия песочниц-контейнеров прямо в коде. Начиная от специальных областей памяти для ввода паролей с солью и заканчивая VM содержащей только окружение и область для временных объектов, вообщем malloc, но для кода. В принципе, формально, функция есть нечто иное как изменение области видимости с сохранением окружения (call), если нет стека - то это процедура (jmp) и в качестве аргумента также может быть исполняемый код как указатель на функцию или адрес перехода. На С можно сделать аналог функции не применяя саму функцию. Например a - это аргумент и локальная переменная (как правило, размещаемая в стеке или регистре {} - область видимости)
/*"Лямбда"*/
{
int a=0;
goto sub;
ret:
goto bypass;
{
sub:
int a=1;
goto ret;
}
bypass:
}
Потенциально валидацию можно сделать через сертификаты и взаимные печеньки (чтобы исключить ддос-ы) условных доверенных центров (юзер всё равно где-то проходит двойную аутентификацию в крупных структурах а-ля гуглы и прочие Госуслуги), когда фронтенд или бэкенд может выполнить нечто вроде "whois email" на сервер а тот ответит валиден этот юзер или нет как настоящее физлицо. Тогда проблема парсинга отпадает сама собой.
Всё верно, просто если стандарт имеет, как было любезно указано выше участником Krypt, строки "due to a long history of problems", это означает что он частично является костылём к го́ре или горе́ легаси. Поэтому, будет соблазн однозначно идентифицировать пользователя, инкапсулировав адрес в промежуточное представление, например UUID_имя@домен или даже Base64_имя@домен. А имя может содержать хоть байткод/анекдот. То есть появятся некие сервисы которые завернут SMTP в более высокоуровневые конструкции актуальные в настоящее время. В эту же копилку номер телефона == мейл.
Вы абсолютно правы с точки зрения формального подхода 1 поле = 1 данное без разночтения. С другой стороны есть приверженцы обрядов. Вообщем вывод напрашивается сам собой и носит по всей видимости чисто административный характер - писать свои предложения в Спортлото RFC. "Подать жалобу. Коллективную (С)" Чтобы уже привели всё в нормативы 21 века.
В принципе так и делается если существует некая точка которая мешает ввиду того что когда-то она была принята с аргументом нам жалко 2 байта на дату, а потом все бегают с проблемой 2000-го года. Хотя грядёт ещё 2^32 в 2038 году.
Это должна быть совместная работа W3C, IEEE, RFC итд итп, но там по всей видимости... Линус прав. Основным мейнтейнерам этого дела уже почти за 70. Поэтому новые разработчики вынуждены будут учиться по тем шаблонам которые закреплены и забетонированы как стандарт пока сами не предложат новое.
PS Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Вообще говоря, это уже задача фронтенда и, по-хорошему, должно появляться всплывающее второе поле при наличии любых суффиксов и галочка для пользователя "считать имя составным" если это критически важно для механизма взаимодействия сайта на основе почты (рассылка, уведомления итд). То есть поддержка стандарта уже реализуется на уровне интерфейса, так как иными методами указать явно это не получится. В этом случае сайт для аутентификации использует каноническое представление. Эта боль - неотъемлемый атрибут всех спецификаций с поведением. Даже ASCII с его перевод строки и возврат каретки, звонок Bell или управляющие последовательности для телетайпа-принтера. По аналогии можно заставить обычным текстом условного имени пользователя пропищать динамик или выплюнуть бумагу при печати заголовка.
Всё верно, просто с точки зрения пользователя, у которого есть суффиксы, может возникнуть неопределённое поведение, он ждёт от сервера обработку запроса на основании имени. Другой вопрос зачем он этот суффикс использует для юзернейма, регистрации итд вне почтового клиента. То есть вне рамок SMTP канонического вида нет и все адреса хоть с + хоть с - являются уникальными и независимыми. Но если сайт предполагает взаимодействие с именем почты как с объектом и обработкой тегов то он уже должен хранить его в приведённом виде. Это скорее вопрос соглашений и на него однозначного ответа нет.
Проблема возникла ввиду того, что адрес почты это объект и практически имеет поведение, то есть имя содержит дополнительные элементы-теги, влияющие на поведение сервера. Исторически получилось так что Username == Email, поэтому конечный пользователь а-ля тётя Юля (для многотысячной посещаемости там 99 таких, включая ботов) не будет утруждать себя чтением RFC. Это скорее нужно администраторам и разработчикам. Особенно там где сложилось так что почта используется в режиме мессенджера и автоматизации рассылки как mailing lists, снабжая адресата суффиксами +- итд. По сути сейчас идёт трансформация почты в чат, поэтому, скорее всего, автоматизацию из имён скорее всего уберут или оставят как unsupported.
Вообще говоря подобного рода стандарты появились, когда что-то из курилок Bell Labs в 70-е было уже де-факто, а потом оформилось де-юре, это же касается и тех самых языков программирования. Поэтому простое следование означает, что потенциально останется аудитория, которая знает как сделать тонкий клиент Радио-86РК программатором ЭПСН-25. Не сегодня так завтра появится Undecillion co. которая скажет что в духе нашей команды теперь в почте и домене могут быть пробелы-смайлики и полный набор Unicode. А наше дополнение позволяет резольвить любое поле аутентификации в наш SunnyFlare с бонусной годовой подпиской как API с функционалом почты, поэтому обходитесь без назойливой @. Браузер WaterDog наконец-то поддерживает сплит-поля в одном теге где отдельно вводится идентификатор, субидентификатор и домен, равно как нормально парсятся даты, время и часовые пояса. Поэтому, лучше следовать самым современным и актуальным нововведениям и сосредоточиться на разделении потоков потенциальных ошибок и ущерба от них на классы по времени восстановления с точки зрения безопасности.
Есть ещё отдельное направление List-Request со знаком минус и прочая автоматизация по образу Git
Можно ещё добавить магическую команду exec как шаблон кодогенерации. Например, в начале скрипта проинициализировать некие статические счётчики для отладки
A, N = "", 40
for i in range(N):
if i < (N - 1): #неявный else
A = A + ("CTR"+str(i)+"=1"+';') + ("DBGL"+str(i)+"=0"+';')
exec(A)
Так собственно расчёты в полной мере оправдались. Тактовая частота вычислителя и атомарных операций не растёт с начала нулевых и остаётся на полке 2-3 ГГц. Транзисторы GAA и прочие FinFet в экспериментальном варианте с субмикронными нормами это конец 90-х. Тогда собственно и было предсказано насыщение. Всё остальное - тонкая доводка. Как были редакторы образца Turbo C так и остались, как вводили программы перфолентой так и сейчас построчно набивать экран шрифтами. Концептуально мало что изменилось за эти 20 лет, проблема выросла вширь за счёт бо́льшего количества элементарных операций на кристалле. Параллелизм это уже финишняя черта развития. Вверх пластины не пойдут даже с интерпозерами, так как тепло отвести невозможно с плотностью под сотню Вт на кв. см., это преимущество только накопители-флешки. То есть всё что можно выжать уже практически выжато на классической технологии. Остаются квантовые и потенциально криогенные многослойные системы а также аналоговые предварительно обученные нейропроцессоры, но это уже отдельная не перфокартовая история.
Вы описали в некоторой мере метод формирования кода по данным, некий аналог синтеза по таблице истинности или конечного автомата по его диаграмме переходов. Если ИИ научится по индукции проверять код на заданные ограничения (исключение глюков), проводить локальное тестирование, выбирать между производительностью и объёмом памяти (ресурс-ориентированный подход), синтезировать алгоритм по промптам из разряда n, n log n, n^2, то тогда уже "проще самому" отойдёт на второй план. В этом случае почти не важна база на которой он это пишет, будь хоть Лисп, Бейсик или Верилог. Главным будет результат теста, бенчмарки и соответствия выходным данным (по сути ТЗ) в виде формального описания и того что обычно кладут в assertion или debug-обёртки, включая различные исключения.
Всё верно, зависит конечно от количества пользователей и на них можно переложить бремя затрат на электричество. И пока что пользователь готов за это платить, даже если будет миллион юзеров и с каждого по 100 руб месячной подписки получается 1e8 ₽, берём 5 руб/квтч получается 2e7 квтч или 2e10 втч или 2 ГВтч. Вообщем такой сбор покроет выпуск новой модели (только по электричеству без учёта серверных затрат, подготовку датасетов и команды). Но тут другой момент более существенный. Относительная скорость обучения падает с разрастанием серверной, так как длинный провод между стойками вносит свою задержку в десятки и сотни нс (это к тому что быстро и качественно обучать "распределённо" не получается). Плюс датацентр на 100 МВт это уже капитальное сооружение которое должно на 100% нагрузку отработать 20 часов только под задачу ИИ. Датацентр на 1 ГВт это уже что-то из разряда планов (кластер Prometheus, Lancium) с градирнями, ЛЭП под 500 кВ и кабельным хозяйством от Земли до Луны. И вот получается что потенциально имеется теоретическая предельная точка по объёму модели, потребляемой мощности и производительности, которая, как может оказаться, не привнесёт покрывающий эти затраты эффект. То есть просто хороший справочник и поисковик уже не актуален и требуется от сети качественно новый эффект синтеза нового нежели "понимания" имеющегося.
Всё гораздо проще - произошло смещение вектора задач для IT из области "сделай это" к "что бы сделать ещё". Когда был экспоненциальный рост первый принцип работал. Как появилась полка, началось растекание в плоскости, выбрать скруглённый прямоугольник или обточенный круг. Как ни парадоксально, "масштабирование Мура пятилетку за 2 года" застряло в начале нулевых для алгоритмов, требующих сортировку и поиск, с характерным не последовательным доступом в память. На то есть 2 причины - вместо прямоугольников уже кусочки синусов, определяющие частоту вычислителя порядка 3 ГГц и связанные с тем что под затвором уже несколько атомов примесей и CMOS-структуру уже крайне сложно сделать со стабильным параметром (плюс туннель через диэлектрик и сопротивление канала) а также скорость света, ограничивающая алгоритмы выбора указателя на указатель на указатель, то есть получить следующее значение из памяти можно только на основе предыдущего. В этом случае свет летит от процессора до плашки, например, 10 см туда-обратно, это 3 ГГц, но ещё надо поделить на корень из диэлектрической проницаемости текстолита, итого эффективно 1,5 в лучшем теоретическом случае, на практике это меньше 1 ГГц на уровне параллельной выборки конца 90-х. Таким образом, как бы вы не гоняли программистов, алгоритмистов, многостаночников-многопроцессорщиков, они могут только теперь заполнять последнюю нишу - многозадачные решения и параллелизм. Но и это уже сейчас также упирается в планку скорости света витой пары между серверными стойками на зависимым по данным доступе. Поэтому всё что наблюдается - прямое следствие этого застоя вот уже на протяжении 20 лет, добавить сюда легаси, практически неизменные среды и инструменты, древние стандарты, неповоротливость корпораций, то и получается что переливание из пустого в порожнее - это лучший бизнес-план.
Если смотреть на структуру ИИ то всё в основном определяется датасетами как основой для реализации, а она выражена на человеческом языке с возможностью вариаций. Поэтому, скорее всего, то что имеется сейчас будет крайне сложно масштабировать без изменения подхода к обучению ИИ и внутреннему представлению того что человек называет алгоритмом. Если посмотреть на техотчёт Дипсик [arXiv:2412.19437] - на обучение потрачено 3 млн машино-часов карточки H800, потребляющей, скажем 1 кВт (с учётом инфраструктуры) Итого имеем 3 ГВт*ч электричества для обучения только одной версии. Это конечно не сравнится с битком, но тенденция будет явная и скоро начнут все торговать некий токен-койн как монета для обучения ввиду ограничения ресурсов. Соответственно для более продвинутой потребуются уже сотни гигаватт-часов и сложность скорее всего растёт экспоненциально. Представьте главного админа, нажатие кнопки "learn" которого приведёт к годовой выработке условной Калининской АЭС.
Очень хороший и всесторонний тест для языка общего назначения - это self-hosted language, то есть который может скомпилировать сам себя. Там и работа с деревьями, текстом, числами , оптимизация. Конечно скриптовые делать такими бессмысленно, если это не библейский LISP, а вот новые компилирующие вполне могут поставить для себя такую задачу, включая общий анализ проекта и устранение сборки всего при изменении буквы в /*abc*/ . С и С++ сильны как раз этим, что обросли всевозможными приёмами и костылями проектного уровня а не конкретной программы, включая гиты, докеры, мейкеры, кодогенераторы-матлабы. В этом их уникальная гибкость.
Язык ещё более низкого уровня - это машинные коды непосредственно с переключателями или HEX-редактором и справочником команд. (Панелька для микросхемы - условная)
Да нынче это опасно. Раньше розетки были без заземления и домашние электроприборы шли без третьего провода, хотя в древних системах был нулевой провод и 2 фазы с углом 0 и 180, между ними было как раз 220 (в американской проводке до сих пор 120/240 так с понижающего трансформатора 10 кВ) и можно было подключать всякие радиолы на 127/110В.
А батарея была идеальной землёй для детекторного приёмника, достаточно было LC-контур, германиевый диод Д18, наушники или телефонный капсюль (карболитовый такой) и вполне ловились местные ДВ/СВ станции на кусок провода длиной метров 10 из окна, нынче они все молчат за ненадобностью.
Также можно отметить, что транзисторы с изолированным затвором, например, серии КП305 поставлялись с трубочкой, которая охватывала все 4 вывода и действительно, рекомендовалось сначала обмотать выводы проволочкой перед монтажом. Главное, не забыть потом её снять.
У меня первой книгой была Рудольф Сворень Электроника шаг за шагом, отличное издание для начинающих. И потом конечно журналы Радио, Массовая радиобиблиотека МРБ
Вот, это ключевой момент который в принципе тормозит весь прогресс из разряда "данные это код" Since 1958 by LISP. ИИ-помощник не меньшая дыра если не следить, туда же внешние макросы и прочие make, куда можно прилинковать напрямую любой код, качнув его по wget. Это что касается этапа построения. Что же до рантайма то должны быть способы для создания подобия песочниц-контейнеров прямо в коде. Начиная от специальных областей памяти для ввода паролей с солью и заканчивая VM содержащей только окружение и область для временных объектов, вообщем malloc, но для кода.
В принципе, формально, функция есть нечто иное как изменение области видимости с сохранением окружения (call), если нет стека - то это процедура (jmp) и в качестве аргумента также может быть исполняемый код как указатель на функцию или адрес перехода. На С можно сделать аналог функции не применяя саму функцию. Например a - это аргумент и локальная переменная (как правило, размещаемая в стеке или регистре {} - область видимости)
Потенциально валидацию можно сделать через сертификаты и взаимные печеньки (чтобы исключить ддос-ы) условных доверенных центров (юзер всё равно где-то проходит двойную аутентификацию в крупных структурах а-ля гуглы и прочие Госуслуги), когда фронтенд или бэкенд может выполнить нечто вроде "whois email" на сервер а тот ответит валиден этот юзер или нет как настоящее физлицо. Тогда проблема парсинга отпадает сама собой.
Всё верно, просто если стандарт имеет, как было любезно указано выше участником Krypt, строки "due to a long history of problems", это означает что он частично является костылём к го́ре или горе́ легаси. Поэтому, будет соблазн однозначно идентифицировать пользователя, инкапсулировав адрес в промежуточное представление, например UUID_имя@домен или даже Base64_имя@домен. А имя может содержать хоть байткод/анекдот. То есть появятся некие сервисы которые завернут SMTP в более высокоуровневые конструкции актуальные в настоящее время. В эту же копилку номер телефона == мейл.
Вы абсолютно правы с точки зрения формального подхода 1 поле = 1 данное без разночтения. С другой стороны есть приверженцы обрядов. Вообщем вывод напрашивается сам собой и носит по всей видимости чисто административный характер - писать свои предложения в
СпортлотоRFC. "Подать жалобу. Коллективную (С)" Чтобы уже привели всё в нормативы 21 века.В принципе так и делается если существует некая точка которая мешает ввиду того что когда-то она была принята с аргументом нам жалко 2 байта на дату, а потом все бегают с проблемой 2000-го года. Хотя грядёт ещё 2^32 в 2038 году.
Это должна быть совместная работа W3C, IEEE, RFC итд итп, но там по всей видимости... Линус прав. Основным мейнтейнерам этого дела уже почти за 70. Поэтому новые разработчики вынуждены будут учиться по тем шаблонам которые закреплены и забетонированы как стандарт пока сами не предложат новое.
PS Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Вообще говоря, это уже задача фронтенда и, по-хорошему, должно появляться всплывающее второе поле при наличии любых суффиксов и галочка для пользователя "считать имя составным" если это критически важно для механизма взаимодействия сайта на основе почты (рассылка, уведомления итд). То есть поддержка стандарта уже реализуется на уровне интерфейса, так как иными методами указать явно это не получится. В этом случае сайт для аутентификации использует каноническое представление.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением. Даже ASCII с его перевод строки и возврат каретки, звонок Bell или управляющие последовательности для телетайпа-принтера. По аналогии можно заставить обычным текстом условного имени пользователя пропищать динамик или выплюнуть бумагу при печати заголовка.
Всё верно, просто с точки зрения пользователя, у которого есть суффиксы, может возникнуть неопределённое поведение, он ждёт от сервера обработку запроса на основании имени. Другой вопрос зачем он этот суффикс использует для юзернейма, регистрации итд вне почтового клиента. То есть вне рамок SMTP канонического вида нет и все адреса хоть с + хоть с - являются уникальными и независимыми. Но если сайт предполагает взаимодействие с именем почты как с объектом и обработкой тегов то он уже должен хранить его в приведённом виде. Это скорее вопрос соглашений и на него однозначного ответа нет.
Проблема возникла ввиду того, что адрес почты это объект и практически имеет поведение, то есть имя содержит дополнительные элементы-теги, влияющие на поведение сервера. Исторически получилось так что Username == Email, поэтому конечный пользователь а-ля тётя Юля (для многотысячной посещаемости там 99 таких, включая ботов) не будет утруждать себя чтением RFC. Это скорее нужно администраторам и разработчикам. Особенно там где сложилось так что почта используется в режиме мессенджера и автоматизации рассылки как mailing lists, снабжая адресата суффиксами +- итд. По сути сейчас идёт трансформация почты в чат, поэтому, скорее всего, автоматизацию из имён скорее всего уберут или оставят как unsupported.
Вообще говоря подобного рода стандарты появились, когда что-то из курилок Bell Labs в 70-е было уже де-факто, а потом оформилось де-юре, это же касается и тех самых языков программирования. Поэтому простое следование означает, что потенциально останется аудитория, которая знает как сделать тонкий клиент Радио-86РК программатором ЭПСН-25.
Не сегодня так завтра появится Undecillion co. которая скажет что в духе нашей команды теперь в почте и домене могут быть пробелы-смайлики и полный набор Unicode. А наше дополнение позволяет резольвить любое поле аутентификации в наш SunnyFlare с бонусной годовой подпиской как API с функционалом почты, поэтому обходитесь без назойливой @. Браузер WaterDog наконец-то поддерживает сплит-поля в одном теге где отдельно вводится идентификатор, субидентификатор и домен, равно как нормально парсятся даты, время и часовые пояса. Поэтому, лучше следовать самым современным и актуальным нововведениям и сосредоточиться на разделении потоков потенциальных ошибок и ущерба от них на классы по времени восстановления с точки зрения безопасности.
Есть ещё отдельное направление List-Request со знаком минус и прочая автоматизация по образу Git
Можно ещё добавить магическую команду exec как шаблон кодогенерации. Например, в начале скрипта проинициализировать некие статические счётчики для отладки
Так собственно расчёты в полной мере оправдались. Тактовая частота вычислителя и атомарных операций не растёт с начала нулевых и остаётся на полке 2-3 ГГц. Транзисторы GAA и прочие FinFet в экспериментальном варианте с субмикронными нормами это конец 90-х. Тогда собственно и было предсказано насыщение. Всё остальное - тонкая доводка. Как были редакторы образца Turbo C так и остались, как вводили программы перфолентой так и сейчас построчно набивать экран шрифтами. Концептуально мало что изменилось за эти 20 лет, проблема выросла вширь за счёт бо́льшего количества элементарных операций на кристалле. Параллелизм это уже финишняя черта развития. Вверх пластины не пойдут даже с интерпозерами, так как тепло отвести невозможно с плотностью под сотню Вт на кв. см., это преимущество только накопители-флешки. То есть всё что можно выжать уже практически выжато на классической технологии. Остаются квантовые и потенциально криогенные многослойные системы а также аналоговые предварительно обученные нейропроцессоры, но это уже отдельная не перфокартовая история.
Вы описали в некоторой мере метод формирования кода по данным, некий аналог синтеза по таблице истинности или конечного автомата по его диаграмме переходов. Если ИИ научится по индукции проверять код на заданные ограничения (исключение глюков), проводить локальное тестирование, выбирать между производительностью и объёмом памяти (ресурс-ориентированный подход), синтезировать алгоритм по промптам из разряда n, n log n, n^2, то тогда уже "проще самому" отойдёт на второй план. В этом случае почти не важна база на которой он это пишет, будь хоть Лисп, Бейсик или Верилог. Главным будет результат теста, бенчмарки и соответствия выходным данным (по сути ТЗ) в виде формального описания и того что обычно кладут в assertion или debug-обёртки, включая различные исключения.
Всё верно, зависит конечно от количества пользователей и на них можно переложить бремя затрат на электричество. И пока что пользователь готов за это платить, даже если будет миллион юзеров и с каждого по 100 руб месячной подписки получается 1e8 ₽, берём 5 руб/квтч получается 2e7 квтч или 2e10 втч или 2 ГВтч. Вообщем такой сбор покроет выпуск новой модели (только по электричеству без учёта серверных затрат, подготовку датасетов и команды). Но тут другой момент более существенный. Относительная скорость обучения падает с разрастанием серверной, так как длинный провод между стойками вносит свою задержку в десятки и сотни нс (это к тому что быстро и качественно обучать "распределённо" не получается). Плюс датацентр на 100 МВт это уже капитальное сооружение которое должно на 100% нагрузку отработать 20 часов только под задачу ИИ. Датацентр на 1 ГВт это уже что-то из разряда планов (кластер Prometheus, Lancium) с градирнями, ЛЭП под 500 кВ и кабельным хозяйством от Земли до Луны. И вот получается что потенциально имеется теоретическая предельная точка по объёму модели, потребляемой мощности и производительности, которая, как может оказаться, не привнесёт покрывающий эти затраты эффект. То есть просто хороший справочник и поисковик уже не актуален и требуется от сети качественно новый эффект синтеза нового нежели "понимания" имеющегося.
Спасибо за совет, иногда лень искать полезные мелочи ). Конечно же есть переменная среды Maxima, которая отвечает за количество выводимых знаков:
Всё гораздо проще - произошло смещение вектора задач для IT из области "сделай это" к "что бы сделать ещё". Когда был экспоненциальный рост первый принцип работал. Как появилась полка, началось растекание в плоскости, выбрать скруглённый прямоугольник или обточенный круг. Как ни парадоксально, "масштабирование Мура
пятилеткуза 2 года" застряло в начале нулевых для алгоритмов, требующих сортировку и поиск, с характерным не последовательным доступом в память. На то есть 2 причины - вместо прямоугольников уже кусочки синусов, определяющие частоту вычислителя порядка 3 ГГц и связанные с тем что под затвором уже несколько атомов примесей и CMOS-структуру уже крайне сложно сделать со стабильным параметром (плюс туннель через диэлектрик и сопротивление канала) а также скорость света, ограничивающая алгоритмы выбора указателя на указатель на указатель, то есть получить следующее значение из памяти можно только на основе предыдущего. В этом случае свет летит от процессора до плашки, например, 10 см туда-обратно, это 3 ГГц, но ещё надо поделить на корень из диэлектрической проницаемости текстолита, итого эффективно 1,5 в лучшем теоретическом случае, на практике это меньше 1 ГГц на уровне параллельной выборки конца 90-х. Таким образом, как бы вы не гоняли программистов, алгоритмистов, многостаночников-многопроцессорщиков, они могут только теперь заполнять последнюю нишу - многозадачные решения и параллелизм. Но и это уже сейчас также упирается в планку скорости света витой пары между серверными стойками на зависимым по данным доступе. Поэтому всё что наблюдается - прямое следствие этого застоя вот уже на протяжении 20 лет, добавить сюда легаси, практически неизменные среды и инструменты, древние стандарты, неповоротливость корпораций, то и получается что переливание из пустого в порожнее - это лучший бизнес-план.Если смотреть на структуру ИИ то всё в основном определяется датасетами как основой для реализации, а она выражена на человеческом языке с возможностью вариаций. Поэтому, скорее всего, то что имеется сейчас будет крайне сложно масштабировать без изменения подхода к обучению ИИ и внутреннему представлению того что человек называет алгоритмом. Если посмотреть на техотчёт Дипсик [arXiv:2412.19437] - на обучение потрачено 3 млн машино-часов карточки H800, потребляющей, скажем 1 кВт (с учётом инфраструктуры) Итого имеем 3 ГВт*ч электричества для обучения только одной версии. Это конечно не сравнится с битком, но тенденция будет явная и скоро начнут все торговать некий токен-койн как монета для обучения ввиду ограничения ресурсов. Соответственно для более продвинутой потребуются уже сотни гигаватт-часов и сложность скорее всего растёт экспоненциально. Представьте главного админа, нажатие кнопки "learn" которого приведёт к годовой выработке условной Калининской АЭС.
Очень хороший и всесторонний тест для языка общего назначения - это self-hosted language, то есть который может скомпилировать сам себя. Там и работа с деревьями, текстом, числами , оптимизация. Конечно скриптовые делать такими бессмысленно, если это не библейский LISP, а вот новые компилирующие вполне могут поставить для себя такую задачу, включая общий анализ проекта и устранение сборки всего при изменении буквы в /*abc*/ . С и С++ сильны как раз этим, что обросли всевозможными приёмами и костылями проектного уровня а не конкретной программы, включая гиты, докеры, мейкеры, кодогенераторы-матлабы. В этом их уникальная гибкость.
Язык ещё более низкого уровня - это машинные коды непосредственно с переключателями или HEX-редактором и справочником команд. (Панелька для микросхемы - условная)