> просто я раньше писал десятки интерпретаторов,

А компилятор писал? А в ядро линукса коммитил?

зачем?

Мне кажется сейчас будут кидания бенчмарками

Зачем?) Мы оба привели какие-то свои аргументы, я сделал свои выводы и решил не продолжать спор)
Есть такое выражение lets agree to disagree )

Та не, я подстрекаю просто))

Люблю читать споры))

Мы вообще не о скорости говорили, скорость будет решаться внутри СУБД через JIT и заранее написаные оптимизированные рутины; речь о языке на котором с базой общаться

Я вообще не спорю нисколько. Я лишь пытаюсь донести мысль что любой код - это зло.

просто если нужно будет написать компилятор - гораздо проще генерировать C++/go код какой нибудь, трудозатраты будут радикально ниже, чем пытаться это самому с нуля реализовать.

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

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

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

А так да, “лучший код это код, который не надо писать”, тут я с тобой согласен

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

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

Ты имел ввиду что питон выбирают из-за батареек?

из-за библиотек

это и есть батарейки

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

1. трудоемкость базовой сборки
2. ну и потом дальнейшие фичи на сколько сложно будет прикрутить и поддерживать

будет это Assembler/Go/Python/JS = по большому счету же - абсолютно пофиг.
Вопрос в том сколько времени ты потратишь в итоге на задачу.

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

Но самая милая история, это например как MySQL / PowerBi / Nifi или в других - когда ты просто тупо указываешь - есть вот это, нужно сделать это и всё - вот так вот галочками.

мы этим принципом активно пользуемся

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

left join в мускуле - это же по большому счету и есть цикл
ты ему говоришь - это и это свяжи по этим полям и всё

Декларативный язык превращается…

не, я наоборот про то, чтобы всё стало декларативным

Тогда надо топить за то чтобы аутер джоинов вообще не нужно было писать

по большому счету - по крайней мере для простых скульников это реально делать
когда есть UML схема - там достаточно:
1. выбрать таблицы
2. поля + модификаторы к ним
3. условия фильтрации

при том этот принцип распространяется не только на мускул, но и на редисы/кафки/апи и т.д.

это в простом случае - как поступать со сложными запросами - тут чуть более сложный вопрос