Если вы хотите сделать удобную запись выражений в виде JSON, то посмотрите на префиксную нотацию, используемую в QueryBuilder фреймворков Yii 1.1 или Yii 2. Вот она и на JSON прекрасно ложится, и специалистами легко читается.
Использование же школьной инфиксной нотации автоматически делает запись неудобной для программной обработки.
Если вы хотите работать с временем, имеет смысл подумать о добавлении операции с семантикой:
x ∈ [y1, y2) → x >= y1 AND x < y2
По моему опыту, это бывает удобнее, чем BETWEEN. Например, если нужны все сутки 13 января 2026 года, а столбец dt имеет формат DATETIME(6) (MySQL), то выражение с BETWEEN будет выглядеть так:
dt BETWEEN '2026-01-13' AND '2026-01-13 23:59:59.999999'
, а выражение с открытым справа диапазоном так:
dt >= '2026-01-13' AND dt < '2026-01-14'
N.B. Да, нейросеть предложила реализовать все 4 варианта, но варианты (] и () встречаются куда реже, чем [] и [).
Странности, которые первыми бросаются в глаза при чтении ваших предложений.
X!=y -> X < y OR X > y
X<=y -> X < y OR X = y
X>=y -> X > y OR X = y
Использовать два сравнения и OR бессмысленно, т.к. операции <=, >=, != (синоним <>) уже есть в SQL.
NOT vendor_id = 23
Данная конструкция в точности равна:
vendor_id <> 23
X=[y1, y2, ..., yN] -> (X = y1 OR X = y2 ... OR X = yN)
X!=[y1, y2, ..., yN] -> (X != y1 AND X != y2 ... AND X != yN)
В SQL эти конструкции записываются без OR и AND, = и !=:
X IN (y1, y2, ..., yN)
X NOT IN (y1, y2, ..., yN)
X>[y1, y2, ..., yN] -> (X > MAX(y1, y2 ... yN))
X<[y1, y2, ..., yN] -> (X < MIN(y1, y2 ... yN))
Ошибка. MIN и MAX в SQL - агрегатные функции по столбцу, имеющие единственный аргумент. Для выбора минимального / максимального из нескольких перечисленных значений в SQL используются функции LEAST и GREATEST. Да и BETWEEN в SQL - совсем не функция.
Затем, что на каждом этапе каждый агент будет не только исправлять ошибки предыдущих агентов, но и добавлять свои собственные ошибки. И сейчас на гитхабе можно наблюдать нашествие тех самых агентов, потоком "исправляющих" абсолютно правильный код.
Да, задача может быть решена множеством разных алгоритмов. Но эффективность каждого из этих алгоритмов зависит от особенностей входных данных и доступных аппаратных ресурсов. Не существует алгоритмов, эффективных для любых входных данных и любого объёма RAM. И задача программиста - выбрать из множества алгоритмов вариант, адекватный техническому заданию.
P.S. Если при реализации простейшего алгоритма BWT нейросеть воспользуется стандартной функцией сортировки, встроенной в язык программирования, производительность этого кода, по сравнению с написанным людьми bzip2, окажется ниже даже не в несколько раз, а на несколько порядков.
В том то и дело, что "под капотом" у них нейросеть. А все нейросети построены на одном и том же принципе: очень сложная алгебраическая функция (или система функций), скомпонованная из множества простейших алгебраических функций (нейронов).
От изменения языковой модели принцип работы нейросети никак не поменяется. И понимать смысл (и задаваемого вопроса, и генерируемого ответа) нейросеть не научится.
Языковые модели отличаются кол-вом параметров, учитываемых при настройке нейросети, что позволяет лучше или хуже приблизить результат выдачи к естественной речи.
Нейросеть - не способ решения задачи, а эвристика, генерирующая примерно правильный ответ. Она никак не анализирует данные, а лишь вычисляет (очень сложной функцией, настроенной в результате "обучения") точку в многомерном пространстве входных-выходных данных. И нет никаких гарантий, что эта точка в данном конкретном случае будет правильным ответом. Ошибки будут всегда - независимо от сложности нейросети и качества её обучения.
А ещё, в интернете говнокода несравнимо больше, чем качественного эффективного кода (и на stackoverflow есть популярные решения, содержащие ошибки), и результатом усреднения по интернету будет большей частью красиво оформленный говнокод. И если для тривиальных задач, валяющихся на каждом углу интернета, этот код хотя бы будет работать, то для чего-то нетривиального нейросеть будет выдавать откровенный бред.
P.S. Теория алгоритмов доказала, что задача сравнения двух алгоритмов является алгоритмически неразрешимой. И это ограничение не объёма обучающей выборки, а тех математических принципов, на которых построены все существующие на Земле цифровые вычислительные системы. Не придумало человечество математику, способную игнорировать теоремы теории алгоритмов.
инвесторы просыпаются и осознают факт: ИИ не просто улучшает программное обеспечение, он может полностью заменить его
Нет. Инвесторов, не знакомых с разделом математики под названием "теория алгоритмов" и, потому, ничего не смыслящих в программировании (не путать с умением писать код), убедили, что "ИИ может". Но всё, что он может - заменить неучей, дрессированных "курсами программирования" ("курсами аналитики данных", "курсами ML" и т.д. - подставляйте по вкусу) бездумно собирать кое-как работающий код из готовых кубиков-библиотек, написанных профессионалами. И никак не может заменить профессионалов, способных эффективно решать задачи IT.
Именно потому, что абсолютно любая программа для цифровых вычислительных систем (в том числе и любой ИИ) - это алгоритм. И никакой алгоритм не способен выйти за ограничительные рамки, доказанные теорией алгоритмов. Независимо от того, что Дарио Амодей рассказывает в своих рекламных сказочках, рассчитанных не неспециалистов.
Стандартная память показывает время доступа около 50 наносекунд.
Здесь "время доступа" к DRAM, которое многократно больше времени переключения ячеек памяти, т.к. включает в себя операции дешифровки переданного по шине адреса и передачи данных.
При переключении за одну наносекунду
А вот здесь время переключения ячеек MRAM.
Сознательное смешивание мух с котлетами.
Достоинства DRAM, перекрывающие её недостатки - цена и объём. Любая из существующих на сегодняшний день технологий более быстрой оперативной памяти многократно дороже. И пока стоимость и объём модуля промышленно выпускаемой MRAM не станут сопоставимы с актуальной на тот момент DRAM, любые рассуждения о достоинствах MRAM будут лишь бессмысленным сотрясением воздуха.
Использовать функции до их объявления можно во множестве языков программирования (лично мне первыми вспомнились PHP и Go). Это не является ни всплытием, ни отличительной особенностью JavaScript.
Переменные объявленные через let и const тоже всплывают, но только до блочной области видимости.
Всплытие - это возможность использования переменной до её объявления. Так что нет, не всплывают. Блокировка имени от начала блока до момента создания этого имени в let или const - да, есть. Но всплытия - нет.
Слишком хрупко: повреждение кода переключения алфавита ломает не единственный символ, как в UTF-8, а весь блок символов до следующего кода переключения алфавита.
Значения типа char и array of char. Да, для пользователя JavaScript или Python проблема может быть неочевидна, т.к. в этих языках есть только тип string. Но в компилируемых языках программирования есть не только строки, но и отдельные символы, и массивы символов, не тождественные строкам. И для них ваши оценки экономии объёма не имеют смысла, т.к. каждый символ, включая ASCII, придётся кодировать минимум 2 значениями (код алфавита и код самого символа в алфавите), что может привести не к сокращению, а к раздуванию объёма данных.
Операции со строками - от сравнения до регулярных выражений. Во многих из них придётся вводить дополнительные накладные расходы. Даже в банальной конкатенации строк придётся либо вводить дополнительные проверки для корректной вставки кодов переключения алфавитов на границах склеиваемых строк, либо смириться с забиванием строк заведомо лишними кодами переключения алфавита, съедающими экономию места и замедляющими сравнение строк. Вы оценивали только кодирование/декодирование, но никак не оценивали усложнение работы с содержимым строк при использовании вашей кодировкой.
Бессмысленность экономии на спичках. Экономия на символах имела смысл во времена PDP-11 c 56 Kb RAM, но при современных объёмах оперативной и внешней памяти - зачем??? Остаётся только передача по сети. Но на малых объёмах данных такая экономия не даст заметного выигрыша (объём служебной информации передаваемого по сети пакета данных никак не уменьшается). А при больших объёмах стандартизированные много лет назад механизмы сжатия трафика (встроенные и в серверы, и в браузеры, и в библиотеки, используемые в языках программирования; и нет - это не zip, так что претензии к скорости работы не принимаются) обеспечат несравнимо лучшее сжатие текстов, чем ваша кодировка.
P.S. Если же вы собираетесь использовать свою кодировку только для чтения/записи данных, а внутри кода использовать другую кодировку, то это тем более лишено смысла, т.к. вы лишь раздуваете объём используемой кодом оперативной памяти.
Так ведь TIOBE - это не про "используется", а про "спрашивается в нескольких поисковиках общего назначения". А большинство запросов в них генерируется не программистами (они ищут ответы на профессиональных ресурсах), а неспециалистами, которые что-то где-то услышали / прочитали.
К использованию языков в реальном программировании TIOBE никакого отношения не имеет. Но может служить индикатором частоты упоминания языков программирования в "неавторитетных источниках".
JetBrains смогла адаптировать свою бизнес-модель, и такие IDE, как IntelliJ IDEA и PyCharm, остались главными инструментами для миллионов разработчиков.
JetBrains подключилась к антипутинским санкциям. Не существует в России легальных способов покупки лицензий и скачивания дистрибутивов/обновлений их продуктов. И все эти "миллионы разработчиков" отрыто нарушают условия лицензий JetBrains.
Произошёл некий ренессанс Linux и рождение новой культуры.
Переход на Linux (даже на якобы "российские" сборки) прямо саботируется Яндексом, демонстративно не выпускающим свой коммуникационный софт для "российских" операционных систем. Но в условиях блокирования государством полноценных мессенджеров для коммуникации внутри компаний остаются практически только Яндекс Мессенджер и Яндекс Телемост. И это вынуждает продолжать использовать Windows.
Российские интеграторы и вендоры начинают предлагать свои услуги и продукты на рынках стран БРИКС и СНГ, где многие компании сталкиваются с похожими вызовами.
Перечислите, пожалуйста, эти страны с "многими компаниями". Белоруссия, как союзник России - понятно. Но какие ещё страны попали под такие международные санкции, что им срочно понадобилась "российская" IT-продукция?
"$request['method'] $request['path']\n" // И внутри итрепретируемых строк индексы тоже в кавычках
Зачем strpos($line, ':')? Какой смысл в этом лишнем просмотре строки, замедляющем код, если по результатам explode мы сразу можем сказать, имеет заголовок формат "ключ: значение" или нет? Тем более, что все корректные заголовки, кроме первого, имеют этот формат.
Basic - это предельно упрощённый Fortran, адаптированный для людей, не являющихся ни профессиональными программистами, ни профессиональными математиками. Собственно, он и был создан для написания кода студентами, не изучающими программирование.
В качестве языка для обучения программированию лучше всего охарактеризовал Basic Дейкстра: "Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации".
Во времена первых 8-битных персональных компьютеров широкому распространению Basic способствовало то, что интерпретатор языка мог работать на компьютерах с предельно малым объёмом ОЗУ. Но сама концепция статически типизированного интерпретируемого языка программирования - эволюционный тупик. И язык начал умирать в 1991 году - с появлением более удобного и рассчитанного на ту же самую аудиторию динамически типизированного Python. Лишь позиция Билла Гейтса, пихающего Basic во все щели, позволила удержать этот язык на плаву ещё несколько десятилетий.
P.S. ИМХО, лучшие диалекты Basic - QuickBasic / QBasic (интерпретатор и компилятор с очень похожими структурными диалектами языка, немного отличающимися семантикой подпрограмм): они прекрасно подходили для прототипирования в задачах, не связанных с обработкой текстов. Но вот VB - это уже деградация.
Единственная причина "популярности" 1C в России - аффилированность с властью. Когда 1С начинала, их бухгалтерская система была лишь одной из многих и далеко не лучшей. А вот дальше началось планомерное убирание конкурентов.
Бизнес-модель, в которой сама 1С ни за что не отвечает, а обслуживанием конечных пользователей занимаются [полу]подвальные фирмочки-посредники - типичный пример сетевого маркетинга в его худшем виде.
Мечты, мечты... С треском разбивающиеся о раздел математики под названием "теория алгоритмов".
Верить вы можете во что угодно, но реальные возможности ИИ определяются не религиозной верой, а математическими правилами, по которым построены все существующие на Земле цифровые компьютеры.
А теперь это всё, внезапно, разработчики языка просто взяли и сломали
Не "внезапно". От объявления того, что какой-то механизм языка будет в будущем удалён, до его фактического удаления проходит более чем достаточно времени. И если правки в любой проект не были внесены вовремя, виноваты в этом не разработчики PHP, а разработчики, занимающиеся развитием проекта и не пожелавшие вовремя внести небольшие изменения в код. Последней же версией, при переходе на которую могла потребоваться радикальная переделка старого кода, была PHP 5.4 (отказ от совместимости с PHP 4).
P.S. Пример JavaScript, в котором "совместимость" возвели в религию, показывает, что это приводит лишь к бессмысленному раздуванию языка и тиражированию низкокачественного кода.
P.P.S. В современном мире несовместимости между версиями языка - не исключение из правил, а норма. С которой приходится сталкиваться даже в предельно стабильном Go.
Строительство дата-центров говорит только о том, что эти дата-центры приносят доход своим владельцам. И не важно, работает технология, или нет. Главное - создать у клиентов иллюзию того, что технология работает. Те, кто несут свои деньги астрологам или гадалкам, тоже уверены, что получат правильный ответ на свой вопрос.
ИМХО, pipe станет более востребован, когда в 8.6 появится частичное применение функций https://wiki.php.net/rfc/partial_function_application_v2. А до тех пор каналы (или трубы?) безусловно упростят код в некоторых случаях, но не станут повсеместно используемым механизмом.
Если в области, площадь которую сократили с помощью ИИ, содержится ответ - ну потратим в несколько раз больше сил и времени на ручную перепроверку тех участков полученной области, в которых ответа нет и быть не может. В конце-концов ответ всё же найдем.
Но ведь регулярно будут возникать ситуации, когда ответ есть, но он находится вне определённой ИИ области. В результате существующий ответ не будет найден.
почему действительно на него не жалеют денег?
Об этом, в том числе, рассказывает статья, которую вы комментируете. И я полностью согласен с её автором.
Если вы хотите сделать удобную запись выражений в виде JSON, то посмотрите на префиксную нотацию, используемую в QueryBuilder фреймворков Yii 1.1 или Yii 2. Вот она и на JSON прекрасно ложится, и специалистами легко читается.
Использование же школьной инфиксной нотации автоматически делает запись неудобной для программной обработки.
Если вы хотите работать с временем, имеет смысл подумать о добавлении операции с семантикой:
По моему опыту, это бывает удобнее, чем BETWEEN. Например, если нужны все сутки 13 января 2026 года, а столбец dt имеет формат DATETIME(6) (MySQL), то выражение с BETWEEN будет выглядеть так:
, а выражение с открытым справа диапазоном так:
N.B. Да, нейросеть предложила реализовать все 4 варианта, но варианты (] и () встречаются куда реже, чем [] и [).
Странности, которые первыми бросаются в глаза при чтении ваших предложений.
Использовать два сравнения и OR бессмысленно, т.к. операции <=, >=, != (синоним <>) уже есть в SQL.
Данная конструкция в точности равна:
В SQL эти конструкции записываются без OR и AND, = и !=:
Ошибка. MIN и MAX в SQL - агрегатные функции по столбцу, имеющие единственный аргумент. Для выбора минимального / максимального из нескольких перечисленных значений в SQL используются функции LEAST и GREATEST. Да и BETWEEN в SQL - совсем не функция.
Затем, что на каждом этапе каждый агент будет не только исправлять ошибки предыдущих агентов, но и добавлять свои собственные ошибки. И сейчас на гитхабе можно наблюдать нашествие тех самых агентов, потоком "исправляющих" абсолютно правильный код.
Да, задача может быть решена множеством разных алгоритмов. Но эффективность каждого из этих алгоритмов зависит от особенностей входных данных и доступных аппаратных ресурсов. Не существует алгоритмов, эффективных для любых входных данных и любого объёма RAM. И задача программиста - выбрать из множества алгоритмов вариант, адекватный техническому заданию.
P.S. Если при реализации простейшего алгоритма BWT нейросеть воспользуется стандартной функцией сортировки, встроенной в язык программирования, производительность этого кода, по сравнению с написанным людьми bzip2, окажется ниже даже не в несколько раз, а на несколько порядков.
В том то и дело, что "под капотом" у них нейросеть. А все нейросети построены на одном и том же принципе: очень сложная алгебраическая функция (или система функций), скомпонованная из множества простейших алгебраических функций (нейронов).
От изменения языковой модели принцип работы нейросети никак не поменяется. И понимать смысл (и задаваемого вопроса, и генерируемого ответа) нейросеть не научится.
Языковые модели отличаются кол-вом параметров, учитываемых при настройке нейросети, что позволяет лучше или хуже приблизить результат выдачи к естественной речи.
Нейросеть - не способ решения задачи, а эвристика, генерирующая примерно правильный ответ. Она никак не анализирует данные, а лишь вычисляет (очень сложной функцией, настроенной в результате "обучения") точку в многомерном пространстве входных-выходных данных. И нет никаких гарантий, что эта точка в данном конкретном случае будет правильным ответом. Ошибки будут всегда - независимо от сложности нейросети и качества её обучения.
А ещё, в интернете говнокода несравнимо больше, чем качественного эффективного кода (и на stackoverflow есть популярные решения, содержащие ошибки), и результатом усреднения по интернету будет большей частью красиво оформленный говнокод. И если для тривиальных задач, валяющихся на каждом углу интернета, этот код хотя бы будет работать, то для чего-то нетривиального нейросеть будет выдавать откровенный бред.
P.S. Теория алгоритмов доказала, что задача сравнения двух алгоритмов является алгоритмически неразрешимой. И это ограничение не объёма обучающей выборки, а тех математических принципов, на которых построены все существующие на Земле цифровые вычислительные системы. Не придумало человечество математику, способную игнорировать теоремы теории алгоритмов.
Нет. Инвесторов, не знакомых с разделом математики под названием "теория алгоритмов" и, потому, ничего не смыслящих в программировании (не путать с умением писать код), убедили, что "ИИ может". Но всё, что он может - заменить неучей, дрессированных "курсами программирования" ("курсами аналитики данных", "курсами ML" и т.д. - подставляйте по вкусу) бездумно собирать кое-как работающий код из готовых кубиков-библиотек, написанных профессионалами. И никак не может заменить профессионалов, способных эффективно решать задачи IT.
Именно потому, что абсолютно любая программа для цифровых вычислительных систем (в том числе и любой ИИ) - это алгоритм. И никакой алгоритм не способен выйти за ограничительные рамки, доказанные теорией алгоритмов. Независимо от того, что Дарио Амодей рассказывает в своих рекламных сказочках, рассчитанных не неспециалистов.
Здесь "время доступа" к DRAM, которое многократно больше времени переключения ячеек памяти, т.к. включает в себя операции дешифровки переданного по шине адреса и передачи данных.
А вот здесь время переключения ячеек MRAM.
Сознательное смешивание мух с котлетами.
Достоинства DRAM, перекрывающие её недостатки - цена и объём. Любая из существующих на сегодняшний день технологий более быстрой оперативной памяти многократно дороже. И пока стоимость и объём модуля промышленно выпускаемой MRAM не станут сопоставимы с актуальной на тот момент DRAM, любые рассуждения о достоинствах MRAM будут лишь бессмысленным сотрясением воздуха.
Использовать функции до их объявления можно во множестве языков программирования (лично мне первыми вспомнились PHP и Go). Это не является ни всплытием, ни отличительной особенностью JavaScript.
Всплытие - это возможность использования переменной до её объявления. Так что нет, не всплывают. Блокировка имени от начала блока до момента создания этого имени в let или const - да, есть. Но всплытия - нет.
Классическое тасование Фишера - Йетса (оно же тасование Кнута) обеспечивает лучшую равномерность:
Смысл в том, что ячейка, в которую записываем выбранное случайное значение, не участвует в дальнейшем тасовании.
Источник: https://ru.wikipedia.org/wiki/Тасование_Фишера_—_Йетса#Современный_алгоритм
Слишком хрупко: повреждение кода переключения алфавита ломает не единственный символ, как в UTF-8, а весь блок символов до следующего кода переключения алфавита.
Значения типа char и array of char. Да, для пользователя JavaScript или Python проблема может быть неочевидна, т.к. в этих языках есть только тип string. Но в компилируемых языках программирования есть не только строки, но и отдельные символы, и массивы символов, не тождественные строкам. И для них ваши оценки экономии объёма не имеют смысла, т.к. каждый символ, включая ASCII, придётся кодировать минимум 2 значениями (код алфавита и код самого символа в алфавите), что может привести не к сокращению, а к раздуванию объёма данных.
Операции со строками - от сравнения до регулярных выражений. Во многих из них придётся вводить дополнительные накладные расходы. Даже в банальной конкатенации строк придётся либо вводить дополнительные проверки для корректной вставки кодов переключения алфавитов на границах склеиваемых строк, либо смириться с забиванием строк заведомо лишними кодами переключения алфавита, съедающими экономию места и замедляющими сравнение строк. Вы оценивали только кодирование/декодирование, но никак не оценивали усложнение работы с содержимым строк при использовании вашей кодировкой.
Бессмысленность экономии на спичках. Экономия на символах имела смысл во времена PDP-11 c 56 Kb RAM, но при современных объёмах оперативной и внешней памяти - зачем??? Остаётся только передача по сети. Но на малых объёмах данных такая экономия не даст заметного выигрыша (объём служебной информации передаваемого по сети пакета данных никак не уменьшается). А при больших объёмах стандартизированные много лет назад механизмы сжатия трафика (встроенные и в серверы, и в браузеры, и в библиотеки, используемые в языках программирования; и нет - это не zip, так что претензии к скорости работы не принимаются) обеспечат несравнимо лучшее сжатие текстов, чем ваша кодировка.
P.S. Если же вы собираетесь использовать свою кодировку только для чтения/записи данных, а внутри кода использовать другую кодировку, то это тем более лишено смысла, т.к. вы лишь раздуваете объём используемой кодом оперативной памяти.
Так ведь TIOBE - это не про "используется", а про "спрашивается в нескольких поисковиках общего назначения". А большинство запросов в них генерируется не программистами (они ищут ответы на профессиональных ресурсах), а неспециалистами, которые что-то где-то услышали / прочитали.
К использованию языков в реальном программировании TIOBE никакого отношения не имеет. Но может служить индикатором частоты упоминания языков программирования в "неавторитетных источниках".
JetBrains подключилась к антипутинским санкциям. Не существует в России легальных способов покупки лицензий и скачивания дистрибутивов/обновлений их продуктов. И все эти "миллионы разработчиков" отрыто нарушают условия лицензий JetBrains.
Переход на Linux (даже на якобы "российские" сборки) прямо саботируется Яндексом, демонстративно не выпускающим свой коммуникационный софт для "российских" операционных систем. Но в условиях блокирования государством полноценных мессенджеров для коммуникации внутри компаний остаются практически только Яндекс Мессенджер и Яндекс Телемост. И это вынуждает продолжать использовать Windows.
Перечислите, пожалуйста, эти страны с "многими компаниями". Белоруссия, как союзник России - понятно. Но какие ещё страны попали под такие международные санкции, что им срочно понадобилась "российская" IT-продукция?
Шизофазия или шизофрения?
В качестве экзерсиса - отлично. Но для практической работы (например, для отладки) лучше использовать встроенный в интерпретатор PHP web-сервер: https://www.php.net/manual/ru/features.commandline.webserver.php
То, что сразу бросилось в глаза в коде:
Зачем
strpos($line, ':')? Какой смысл в этом лишнем просмотре строки, замедляющем код, если по результатам explode мы сразу можем сказать, имеет заголовок формат "ключ: значение" или нет? Тем более, что все корректные заголовки, кроме первого, имеют этот формат.Basic - это предельно упрощённый Fortran, адаптированный для людей, не являющихся ни профессиональными программистами, ни профессиональными математиками. Собственно, он и был создан для написания кода студентами, не изучающими программирование.
В качестве языка для обучения программированию лучше всего охарактеризовал Basic Дейкстра: "Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации".
Во времена первых 8-битных персональных компьютеров широкому распространению Basic способствовало то, что интерпретатор языка мог работать на компьютерах с предельно малым объёмом ОЗУ. Но сама концепция статически типизированного интерпретируемого языка программирования - эволюционный тупик. И язык начал умирать в 1991 году - с появлением более удобного и рассчитанного на ту же самую аудиторию динамически типизированного Python. Лишь позиция Билла Гейтса, пихающего Basic во все щели, позволила удержать этот язык на плаву ещё несколько десятилетий.
P.S. ИМХО, лучшие диалекты Basic - QuickBasic / QBasic (интерпретатор и компилятор с очень похожими структурными диалектами языка, немного отличающимися семантикой подпрограмм): они прекрасно подходили для прототипирования в задачах, не связанных с обработкой текстов. Но вот VB - это уже деградация.
Единственная причина "популярности" 1C в России - аффилированность с властью. Когда 1С начинала, их бухгалтерская система была лишь одной из многих и далеко не лучшей. А вот дальше началось планомерное убирание конкурентов.
Бизнес-модель, в которой сама 1С ни за что не отвечает, а обслуживанием конечных пользователей занимаются [полу]подвальные фирмочки-посредники - типичный пример сетевого маркетинга в его худшем виде.
Мечты, мечты... С треском разбивающиеся о раздел математики под названием "теория алгоритмов".
Верить вы можете во что угодно, но реальные возможности ИИ определяются не религиозной верой, а математическими правилами, по которым построены все существующие на Земле цифровые компьютеры.
Не "внезапно". От объявления того, что какой-то механизм языка будет в будущем удалён, до его фактического удаления проходит более чем достаточно времени. И если правки в любой проект не были внесены вовремя, виноваты в этом не разработчики PHP, а разработчики, занимающиеся развитием проекта и не пожелавшие вовремя внести небольшие изменения в код. Последней же версией, при переходе на которую могла потребоваться радикальная переделка старого кода, была PHP 5.4 (отказ от совместимости с PHP 4).
P.S. Пример JavaScript, в котором "совместимость" возвели в религию, показывает, что это приводит лишь к бессмысленному раздуванию языка и тиражированию низкокачественного кода.
P.P.S. В современном мире несовместимости между версиями языка - не исключение из правил, а норма. С которой приходится сталкиваться даже в предельно стабильном Go.
Строительство дата-центров говорит только о том, что эти дата-центры приносят доход своим владельцам. И не важно, работает технология, или нет. Главное - создать у клиентов иллюзию того, что технология работает. Те, кто несут свои деньги астрологам или гадалкам, тоже уверены, что получат правильный ответ на свой вопрос.
ИМХО, pipe станет более востребован, когда в 8.6 появится частичное применение функций https://wiki.php.net/rfc/partial_function_application_v2. А до тех пор каналы (или трубы?) безусловно упростят код в некоторых случаях, но не станут повсеместно используемым механизмом.
Если в области, площадь которую сократили с помощью ИИ, содержится ответ - ну потратим в несколько раз больше сил и времени на ручную перепроверку тех участков полученной области, в которых ответа нет и быть не может. В конце-концов ответ всё же найдем.
Но ведь регулярно будут возникать ситуации, когда ответ есть, но он находится вне определённой ИИ области. В результате существующий ответ не будет найден.
Об этом, в том числе, рассказывает статья, которую вы комментируете. И я полностью согласен с её автором.