Зачем придумывают всё новые языки-велосипеды?

В перспективе, идеальный язык - это сильный AI, способный за час написать ПО лучшего качества, чем аналогичное, написанное толпой «нормальных людей» за год.

Ах, мечты-мечты. Знаешь, они за 50 лет не изменились.

Качество языка определяется минимизацией стоимости разработки на нём продукта соответствующего ТЗ, т.е. времязатратами на получение продукта с требуемыми свойствами.

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

Если так неаккуратно говорить, то можно плавно прийти к более общему вопросу, вроде «зачем писать в коболе?» - и он будет справедлив.

На коболе удобно и наглядно (для англоязычного читателя) пишутся алгоритмы. А также скорость выполнения на уровне Си.

https://www.npmjs.com/package/js-big-decimal - просто это никому не нужно в JS.

Это жалкое подобие. То есть мне COBOL'овское

COMPUTE I=(A+B*C)^3*100/SUM ON SIZE ERROR DOEXCEPT

Я сомневаюсь, что много коммерсов выкладывают 5 лямов рублей на создание свой системы на 1С.

Какие 5 лямов? Отдел АСУ и так есть и штаны просиживает. Хотелки у пользователей тоже регулярно. То отчёт сделать, то выгрузку в файл или загрузку из файла, то какую-нибудь схему согласования прикрутить. И всё это код. За несколько лет нарастает те самые 100 тысяч. С точки зрения коммерса — бесплатно.

Думаю, если посчитать общее количество строк всех макросов офиса, то тоже будет где-то такая же величина.

Примерно такая ситуация, например, с COM, которым много человек владеет, но никто не хочет на нем писать.

Но никто при этом не утверждает, что писать на нём легко. А ты пишешь «Кобол очень прост».

Собсна, с 1С тоже много людей бежит - приходится компенсировать через ЗП.

С 1С другая проблема. Там от программиста ожидается знание предметной области. То есть задание он получает в стиле: «Сделать выгрузку на ККТ АТОЛ зачёта аванса» или «Сделать формирование проводок закрытия месяца по счёту 29 на счёт 20 пропорционально прямым затратам». И когда надоедает быть бухгалтеро-расчётчико-юристо-программистом, то уходят туда, где можно быть кем-то одним из четверых.

руби это уродливый опаскаленный них-питон

Опаскален словом end? Лол. Вообще не похоже ни на питон, ни на тем более паскаль. Если конечно видеть что-то кроме синтаксиса.

уроень абстракций и выразительная способность даже Си находится значительно выше кобола

Да ну. Что можно выразить в СИ и нельзя в Коболе? Обратный пример про арифметику я уже приводил. Ещё могу привести CORRESPONDING (аналог в Си невозможен), SELECT (аналог fopen, но в SELECT есть блокировки, индексы, сортировка, режим доступа), WORKING-STORAGE, LOCAL-STORAGE, OCCURS DEPENDING ON, ...

JS не рисует страницу, JS не грузит данные и не разбирает JSON, JS отвечает только за логику

Ну вот. А Кобол отвечает за финансы. И есть разница, операционный день у тебя закроется за 3 часа или за 9 часов. И эта скорость упирается на в СУБД, а в финансовые расчёты (которые на JS будут жутко тормозить через bigDecimal).

А как насчет уязвимостей и произвольного выполнения кода?

Так для этого и JS не надо. Если не повезёт, то и на текстовом файле можно словить произвольное выполнение. База-то вся на C/C++.

Чрезмерная оптимизация приводит к повышению возможностей для уязвимостей - это неизбежно, и это случилось с браузерами. Также, например, это случилось с теми же процессорами (Spectre/Meltdown).

Все переходим на Lisp/Java/C#/Oberon/...? То есть на Mezzano/JavaOS/Singularity/A2.

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

Ну почему же? Например, SQL сократил написание алгоритмов выборок и добавления данных на несколько порядков. Язык регулярных выражений PERL также очень уплотнил описание алгоритма. Shell дал компактный язык межпроцессного взаимодействия.

Рецепт хорошего языка — тот, который позволяет компактно записать большое семейство алгоритмов. Да, в перспективе какой-нибудь AI сможет в качестве задания на отчёт из БД принимать электронную таблицу с примером. А в качестве задания на сайт его картинку.

Знаешь, они за 50 лет не изменились.

век назад о таких вещах, как смартфон и интернет даже фантасты не писали, ещё как изменились

по второму пункту согласен на все 100%

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

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

То есть AI-андроид должен прожить лет 20-30 в человеческом обществе так, чтобы все думали, что он человек.

20-30 лет - ничто по историческим меркам

Вообще не похоже ни на питон

Вообще похоже на питон примрено всем кроме семантических извращений.

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

Странно, в моём мире она используется на каждом андроид смартфоне. А в вашем как, коммунизм наступил?

В моем мире в 2019 гугл уже перешел на котлин, и готовит Flutter с полным отказом от жавы.

но вот глядишь на вакансии и там: требуется знания языка X123 (от 5 лет), опыт работы с фреймворком Y456, и ещё тулзы Z789, Z798 и Z897.

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

То есть мне COBOL'овское
COMPUTE I=(A+B*C)^3*100/SUM ON SIZE ERROR DOEXCEPT
придётся разбивать на add, subtract, divide, multiply и не забыть после каждой операции поставить round или floor. И проверку на переполнение тоже не забыть.

context.a = 1
context.b = 2
context.c = 3
context.sum = 6
context.compute('i=(a+b*c)^3*100/sum')

Просто это никому не нужно. JS тоже довольно неплохо умеет в метаязыки. Посмотри на тот же vue.js, где путем перехвата методов изменения объектов происходит автоматическое отслеживание измененных сущностей и перерисовка - всё это без лишних действий со стороны программиста.

Я даже не беру Spring/Java EE, вот полегче - https://github.com/google/guice/wiki/AOP#example-forbidding-method-calls-on-weekends

О, Гусь! Я работал с ним однажды. До сих пор иногда по ночам просыпаюсь, когда приснится.

Отдел АСУ и так есть и штаны просиживает.

У мелкого и части среднего бизнеса есть только отдел САСУ, который состоит из одного человека и работает на полставки. Много кто вообще не держит постоянных кодеров, а только сдельно заказывают доработки по необходимости. А слить 100k$, пусть из на несколько лет, остается непозволительной роскошью для многих. Лучше уж дачу построить начальнику.

Примерно такая ситуация, например, с COM, которым много человек владеет, но никто не хочет на нем писать.

Но никто при этом не утверждает, что писать на нём легко. А ты пишешь «Кобол очень прост».

Ассемблер прост, но писать на нем тяжело. Логика ясна? Аналогичную систему на ассемблере написать сложнее, чем на JS. Поэтому средняя поделка на JS выполняет намного более сложные алгоритмы, чем средняя поделка на асме.

Что можно выразить в СИ и нельзя в Коболе?

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

CORRESPONDING (аналог в Си невозможен)

Такой функции нет ни в одном современном языке, потому что ее поведение неявно.

SELECT (аналог fopen, но в SELECT есть блокировки, индексы, сортировка, режим доступа)

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

WORKING-STORAGE, LOCAL-STORAGE

И зачем оно?

OCCURS DEPENDING ON

Си, опять же, позволяет делать намного больше структур данных, чем это OCCURS ... DEPENDING ON.

Да, у вас точно другой мир - в нём для андроида приложения пишет только гугл и он в 2019 УЖЕ переписал всё на котлин

И эта скорость упирается на в СУБД, а в финансовые расчёты (которые на JS будут жутко тормозить через bigDecimal).

Я бы не пытался обсуждать вопросы производительности вычислений в языке, принципиально не умеющем в потоки. И JS тоже плохо умеет в потоке, потому Java в этой сфере более востребована.

Да, у вас точно другой мир - в нём для андроида приложения пишет только гугл и он в 2019 УЖЕ переписал всё на котлин

Конечно, они старый работающий код не будут переписывать «для фен шуя». Но все новые проекты - только на Kotlin.

А как насчет уязвимостей и произвольного выполнения кода?

Так для этого и JS не надо. Если не повезёт, то и на текстовом файле можно словить произвольное выполнение. База-то вся на C/C++.

Прикинь, нынче анимация в браузере делается на CSS. Я сам был в шоке, но это так. JS, все-таки, язык браузерной странички, и никуда ты от этого не денешься, даже в ноде. В этом плане он подобен коболу, который так же завязан на бизнес, как JS на браузеры. Я писал:

захудалый проектик на JS по функционалу таки будет пожирнее многих COBOL-проектов. Почему? Потому что большая часть функционала реализована в самом браузере.

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

SQL сократил написание алгоритмов выборок и добавления данных на несколько порядков

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

Знаешь, они за 50 лет не изменились.

век назад о таких вещах, как смартфон и интернет даже фантасты не писали, ещё как изменились

Не изменились мечты о том, что комп будет пахать вместо человека. Эта же идея витала в воздухе аж 50 лет назад, пока всем эти обещания не надоели и разрабов AI не отправили мести двор и разгружать уголь.

Увидел бы Spring - заснуть бы не с мог в этим образом перед глазами

context.compute('i=(a+b*c)^3*100/sum')

Это есть или как у лисперов «если очень надо, можно написать»? Потому что если «можно написать», то можно на JS сразу написать компилятор кобола и этим «доказать», что на JS можно сделать всё то же, что и на коболе. Полные по Тьюрингу языки ведь.

Кстати, и на коболе можно написать интерпретатор JS.

Ассемблер прост, но писать на нем тяжело.

Выучить ассемблер намного сложнее, чем выучить JS. Или что, по-твоему, значит «прост»? То что проще написать компилятор ассемблера, чем компилятор JS?

свободная работа с указателями

Свободная там UB в момент разыменования указателя. А разумная работа с указателями (указатель на переменную или на элемент массива) и в Коболе есть:

PERFORM VARYING I FROM 1 BY 1 UNTIL Table-Size < I
               CALL Func-Id USING BY REFERENCE Table-Values (I)

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

Поэтому на Си и нельзя писать программное обеспечение, где цена ошибки велика.

В коболе у тебя есть набор жестко ограниченных функций, и ты не можешь никуда дернуться.

Вообще-то Кобол позволяет выполнять любую системную функцию, так что двинуться можно в тех же пределах, что и на Си.

И зачем оно?

LOCAL-STORAGE — данные локальные для текущего потока при многопоточном выполнении. Компилятор Кобола умеет сам делать многопоточную программу без явных вызовов pthread.

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

Только небезопасных и неудобных в использовании.

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

Буду.

Выбрать из большого файла строки, содержащие «bash», отсортировать результат, вывести первые 10 строк.

На bash будет: «fgrep bash bigfile | sort | head». На любом другом языке куча возни с промежуточными файлами, выделением памяти под буфер и всё такое.

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

??? Человек пишет десяток строк на SQL, а компилятор SQL строит алгоритм выборки.

Баш, как и SQL - это язык-запускалка алгоритмов. В баше параметры, в SQL параметры.

Не параметры, а произвольные блоки алгоритмов. Так можно и про JS сказать, что у него параметры (имя функции, имя метода, литерал, ...).

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

??? JavaScript разве не умеет?

Или ты считаешь, что Кобол не умеет? Там вообще-то поддержка на уровне языка/компилятора: https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.2.0/com.ibm.ent.cbl....

У мелкого и части среднего бизнеса есть только отдел САСУ, который состоит из одного человека и работает на полставки.

Ну не знаю. Во всех организациях, где есть хотя бы сотня сотрудников, есть и отдел АСУ из 2-3 человек, которые обеспечивают работу вычтехники и оргтехники (чинят, пылесосят, обновляют, программируют, ...). А там, где отдел АСУ из пол-человека, там, как правило, и бухгалтерия из одного главбуха на полставки и никакие доработки 1С ему в принципе не нужны (чтобы сдать отчётность типовой хватает).

пока всем эти обещания не надоели и разрабов AI не отправили мести двор и разгружать уголь.

Замечу, что 90% того, с чем те разрабы не справились, на сегодняшний день уже реализовано: распознавание образов (классификация), отслеживание объектов, перевод между человеческими языками и даже тест Тьюринга пройден.

ну то есть, сейчас у гугла на котлин, в общем-то, ничего и нет

Язык регулярных выражений PERL

это не язык, это библиотека, которая есть в любом языке

SQL

ORM тоже есть в любом языке, это тоже библиотека, да и вообще в каноничном SQL есть только update|insert|delete - слишком мало, чтобы называться языком

Shell дал компактный язык межпроцессного взаимодействия.

не дал, всё что > 10 строк удобнее писать на любом другом языке

это не язык, это библиотека, которая есть в любом языке

От этого он не перестаёт быть языком. А если брать по признаку «это библиотека, которая есть в любом языке», то и lua не язык и лисп и даже Си (ведь сишный компилятор тоже можно подключить библиотекой).

вообще в каноничном SQL есть только update|insert|delete - слишком мало, чтобы называться языком

Ещё там есть CREATE/DROP TABLE/INDEX/DATABASE. Вполне язык и даже полный по Тюрингу.

не дал, всё что > 10 строк удобнее писать на любом другом языке

Межпроцессное конвейерное взаимодействие на любое количество процессов удобнее писать на шелле. Кстати, именно поэтому всякие IPython и прочие не смогли его заменить.

Это есть или как у лисперов «если очень надо, можно написать»? Потому что если «можно написать», то можно на JS сразу написать компилятор кобола и этим «доказать», что на JS можно сделать всё то же, что и на коболе. Полные по Тьюрингу языки ведь

Есть большая разница: на JS действительно пишут трансляторы и виртуальные машины, а сколько компиляторов написано на коболе? Уровень абстракций и бедность выразительных средств делает подвигом написание даже компилятора кобола на коболе - вместо этого обычно они пишут компилятор на Си, причем, сам компилятор транслирует код кобола в Си, а потом код на Си компилируется в исполняемый.

Кстати, и на коболе можно написать интерпретатор JS

Да, толкьо его никут не написал. И не напишет. Зато уже написали компилятор кобола в JS:
https://github.com/ajlopez/CobolScript

Выучить ассемблер намного сложнее, чем выучить JS. Или что, по-твоему, значит «прост»? То что проще написать компилятор ассемблера, чем компилятор JS?

Формальное определение ассемблера проще, чем определение JS. Писать на нем сложнее намного. Как велосипед с одним колесом проще, но ездить на нем сложнее.

вместо этого обычно они пишут компилятор на Си, причем, сам компилятор транслирует код кобола в Си, а потом код на Си компилируется в исполняемый.

С учётом того, что Си для zOS появился существенно позже, чем Кобол, очень сильно сомневаюсь.

Да, толкьо его никут не написал. И не напишет.

Будет нужен, напишут. JSON PARSE и JSON GENERATE в COBOL'е уже есть. А проблем написать интерпретатор на COBOL'е нет. Вот пример: http://rosettacode.org/wiki/RCSNUSP/COBOL

На JS виртуальные машины и трансляторы пишут только потому, что в браузере другого языка нету. JS выполняет роль ассемблера. А в z/OS есть системный PL/I, в UNIX — C. Зачем использовать COBOL для несвойственной функции.

Формальное определение ассемблера проще, чем определение JS.

Да ну? В JS около 40 ключевых слов + полдюжины грамматических конструкций. В ассемблере даже примитивного 8086 было 116 ключевых слов + пара грамматических конструкций. В ассемблере современного Core i7 количество ключевых слов уже несколько сотен.

Свободная там UB в момент разыменования указателя. А разумная работа с указателями (указатель на переменную или на элемент массива) и в Коболе есть

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

Поэтому на Си и нельзя писать программное обеспечение, где цена ошибки велика.

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

LOCAL-STORAGE — данные локальные для текущего потока при многопоточном выполнении. Компилятор Кобола умеет сам делать многопоточную программу без явных вызовов pthread.

Компилятор кобола не умеет делать многопоточную программу, он умеет только компилировать код кобола в специальные конструкции сериализации действий. Потоки создаются извне, и эти потоки могут запускать в себе программу на коболе. Естественно, такое костыльное построение многопоточности приводит к тому, что даже жава обгонит по производительности программу на коболе. Это при то, что на жаве писать-то будет поприятнее.

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

Только небезопасных и неудобных в использовании.

Что значит «неудобных»? Если человек за фиксированный промежуток времени этой структурой может сделать намного больше, чем с коболом - это «неудобный»?

Выбрать из большого файла строки, содержащие «bash», отсортировать результат, вывести первые 10 строк.
На bash будет: «fgrep bash bigfile | sort | head»

Можно сделать ОС, которая будет по нажатию кнопки на системном блоке выполнять выбирать строку, сортировать результат, и выводить 10 строк - значит ли, что кнопка на системном блоке облегчила написание алгоритмов? Нет, кнопка ничего не делала. Как баш ничего не делал. Все действия выполняли fgrep, sort, и head - они составляют основную сложность реализации.

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

??? Человек пишет десяток строк на SQL, а компилятор SQL строит алгоритм выборки.

Я вот так совсем недавно написал «десяток строк на SQL», и выяснилось, что работать они будут несколько дней. Тогда мне пришлось самому бить операцию на мелкие и выполнять вручную. И чем больше ты отклоняешься от того, что уже написано и запускается нажатием одной кнопки, тем больше тебе приходится писать. Вплоть до того, что ты полностью перепишешь СУБД.

??? JavaScript разве не умеет?
Или ты считаешь, что Кобол не умеет? Там вообще-то поддержка на уровне языка/компилятора: https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_14.2.0/com.ibm.ent.cbl....

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

Есть вот такая замечательная табличка: https://www.marketologi.ru/img/public/articles/midbiz1.gif
Да законодательное определение среднего бизнеса весьма странное, когда для нефтянки средний размер - это 5000 человек, а для розничной торговли - 150 человек. У меня есть просто знакомый, который руководит фирмой, занимающейся ремонтом и обслуживанием компов и разной техники для коммерсов - они и занимаются тем самым, что у тебя должно заниматься АСУ. Нужно переустановить винду? Звонят, приезжает человек, ставит винду. Принтер заправить? Везут сами или, опять таки, приезжает человек. Сотни сотрудников нет, но десяток-другой есть. Да, их 1С имеет минимальные доработки, но все-таки имеет. И таких фирм много, намного больше фирм из нескольких сот сотрудников, которые могут выделять много чего на свои IT.

Замечу, что 90% того, с чем те разрабы не справились, на сегодняшний день уже реализовано: распознавание образов (классификация), отслеживание объектов, перевод между человеческими языками и даже тест Тьюринга пройден.

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

перевод между человеческими языками и даже тест Тьюринга пройден.

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

ну то есть, сейчас у гугла на котлин, в общем-то, ничего и нет

https://developer.android.com/jetpack

С учётом того, что Си для zOS появился существенно позже, чем Кобол, очень сильно сомневаюсь.

А это хороший вопрос. Если у кого-то есть этот компилятор, то можно узнать, на чем он написан. Вполне возможно, что на PL/I.

Будет нужен, напишут. JSON PARSE и JSON GENERATE в COBOL'е уже есть.

Да, только эти JSON PARSE и JSON GENERATE написаны опять не на коболе.

А проблем написать интерпретатор на COBOL'е нет. Вот пример: http://rosettacode.org/wiki/RCSNUSP/COBOL
SNUSP is an esoteric programming language based on Brainfuck

Отличные истории.

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

Это справедливый аргумент, если говорить о том, что кто-то пишет трансляторы в Javascript. Но проблема в том, что эти трансляторы пишут на JS, и они выполняются не в браузере, а в ноде, которая могла была быть заменена любым языком.

Формальное определение ассемблера проще, чем определение JS.

Да ну? В JS около 40 ключевых слов + полдюжины грамматических конструкций. В ассемблере даже примитивного 8086 было 116 ключевых слов + пара грамматических конструкций. В ассемблере современного Core i7 количество ключевых слов уже несколько сотен.

Вот именно, «пара грамматических конструкций» - это и есть ассемблер. А инструкции - это его стандартная библиотека, которая изменяется в зависимости от требований.

От этого он не перестаёт быть языком. А если брать по признаку «это библиотека, которая есть в любом языке», то и lua не язык и лисп и даже Си (ведь сишный компилятор тоже можно подключить библиотекой).

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

напоминаю, что регулярные выражения - это математическая абстракция и в ООП виде она записывается гораздо проще. например

regexp().every_char().then().str("имя:").then().space().repeat(1, regexp::inf).then().every_char(regexp::rus).repeat(1, regexp::inf)

пишется дольше, зато читается гораздо лучше, чем это ваше

regexp(".имя\\s+[абвгдеёжзийклмнопрстуфхцчщыъьэюяъАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЫЬЪЭЮЯ"]+)

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

Ещё там есть CREATE/DROP TABLE/INDEX/DATABASE.

это просто все те же update/insert/delete, только в системные таблицы

Р.S. ещё select, конечно

Вполне язык и даже полный по Тюрингу.

Ну допустим. Но вы опять не разграничиваете синтаксис и библиотеку. РСУБД - действительно, значительный прорыв в индустрии, но SQL - просто очередной язычок и не более. Без использования SQL, доступ к РСУБД, как правило, проще и удобнее. Помнится в своё время писал код на шарпе, встраиваемый в БД. Результат вышел гораздо читабельнее и быстрее, а благодаря bulk insert ещё и быстрее, чем если бы я писал на SQL. Кстати, код (ЕМНИП), в итоге, не использовал SQL вообще, даже как промежуточное звено исполнения.

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

вообще-то, есть webassembly