Сколько зарабатывает Pascal программист?

Ну хорошо, тогда Java.

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

И живёт-процветает.

Haskell и Erlang тоже вполне живые. Не хуже, чем лисп или паскаль.

java как раз таки прямой наследник паскаля. Даже во внутреннем устройстве, p-code и пи-машины были изобретены гораздо раньше явы. В яве оформлены до спецификаций и с привнесением ОО

но паскаль проще и яснее для обучения :-)

но паскаль проще и яснее для обучения :-)

Не сказал бы. Строки в Delphi Pascal вообще не объекты и приводят к удивительным открытиям после работы с Java.

конкенакативный ассемблер

накативный? чего накатывать? куда? а что об этом думает психиатр логопед? ))))

шо сказать-то хотел, мне аж интересно! гугл выдает 0 (ноль) результатов!

p.s.: эти люди любой языковой срач сведут к лиспу! ))))

concatenative любезный. Согласен, что термин не с первой попытки можно напечатать или выговорить :-)

PS/ чтобы проще было искать : https://concatenative.org; рекомендовано для общего развития

PPS/ ещё из обще-небезинтересного, надысь почти опубликовали исторический код PostScript ( тоже из этих со страшным названием) https://computerhistory.org/blog/postscript-a-digital-printing-press/ (почти потому как по факту Adobe всё-равно спрашивает почту-креды)

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

вот ещё прибыло:

alpha = [0] * 5 ; # охереть - это на самом деле объявление слабо-типизированного массива
                  # чтобы поменьше ошибок далее с приведением типов
                  # без такой лабуды половина примеров из школьных методичек НЕ РАБОТАЮТ

alpha = input().split();    # ога, и это не то что вы подумали, это иное и иначе работает (зависит от предыстории alpha)

прихожу к окончательному выводу, что за преподавание Пиона как первого языка, «надо казнить нельзя помиловать»;

Не понял. А где они были быстрые? Или какой процессор оптимизирван не под них?

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

Там ещё register был. volatile можно рассматривать как его антоним. Иначе из памяти в регистр данные загрузятся, а обратно выгрузятся только после полного окончания работы с ней

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

Это в случае доступа к методу или полю объекта null

А null — это что, если не указатель? То, что в жаве строгая проверка корректности доступа к указателям, нет UB, и в том числе нет арифметики над указателями, не значит, что ее указатели перестали быть указателями.

Я и привёл в пример Лисп. В нём было также. А в Паскале и Аде есть UB

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

Сейчас есть эффективные компиляторы с SML и Ocaml. Как-то популярностью всё равно не пользуются

Rust популярностью тоже не пользуется. D — вообще маргинальщина. Flutter где-то в жопино, несмотря на поддержку огромной корпорации. Напоминаю, что в коммерческом IT технические аспекты никогда не берутся в рассмотрение — только маркетинг, только популярность и готовые решения, только краткосрочная выгода.

Так питон их сожрал тем, что лучше. Или почему выбирают его?

Вот как по-твоему происходит? Приходит ньюфаг в кодинг, садится, и начинает думать «вот есть CL, вот окамль, вот хаскель, скала, F#, ада. луа, перл, питон.... хм-м-м, что бы мне выбрать? Пойду как я посмотрю, какие есть позитивные и негативные стороны у этих языков». Я ТАК И СДЕЛАЛ! Потому оказался непотяно где. Питон выбирают потому что «ну это же питон» — это ультимативный аргумент для выбора питона, который нечем крыть. Давай, ты будешь мне предъявлять аргументы, почему питон плох и что есть лучше, а я тебе буду отвечать «но это же питон, а где твой $lang_name?».

Совсем чуть-чуть. И странно, что тогдашний компилятор Си не мог вывести такой код из исходников

Там написано, что это не весь асм, а только часть. Си в принципе проектировался именно для написаняи в стиле «асм плюс Си», все его позитивные стороны вызваны именно хорошим взаимодействием с асмом, что в том числе дало возможность склеивать код на разных ЯП.

сишные строки бывают либо медленные, либо очень медленные

Неправильно спросил. В каком языке они быстрые?

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

Да ладно. Хочешь сказать, что в старом Си

for(i = 0; i < 10; i++) ...

Всегда разворачивалось в

        записать 0, по адресу i
метка1: прочитать i в r0
        если не r0 < 10, перейти на метка2
        ...
        прочитать i в r0
        увеличить r0
        записать r0 в i
        перейти на метка1
метка2  ...

? Это убило бы всю производительность.

А null — это что, если не указатель?

Семантически, это специальный объект.

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

Нет арифметики. Невозможен указатель на несуществующий объект.

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

Почитал. Не нашёл описания поведения, если сделать dispose, а потом записать в этот адрес данные. Или в каком пункте?

Rust популярностью тоже не пользуется. D — вообще маргинальщина. Flutter где-то в жопино, несмотря на поддержку огромной корпорации.

Так Си++ удобнее. Я про это и пишу.

Питон выбирают потому что «ну это же питон»

Это где так? Выбирают либо потому что на нём есть готовое решение и его надо дорабатывать, либо потому что надо написать небольшой скрипт и разумно выбрать язык без UB и удобный для чтения.

что в том числе дало возможность склеивать код на разных ЯП

Код на разных языках можно склеивать, если есть стандарт на ABI. А у нас вместо стандарта перевод всего в ABI от Си. К слову, взаимодействие с асмом требует от Си прямой поддержки от компилятора. Из языка нельзя указать ни порядок передачи параметров ни даже где их передавать (регистры, память, …).

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

Противоречивое утверждение. Как раз volatile ввели чтобы избегать оптимизаций в виде этих «перемещений».

Приходит ньюфаг в кодинг, садится, и начинает думать «вот есть CL, вот окамль, вот хаскель, скала, F#, ада. луа, перл, питон…. хм-м-м, что бы мне выбрать? Пойду как я посмотрю, какие есть позитивные и негативные стороны у этих языков

Смотря зачем приходит. Если программировать для себя, то именно так. И я для себя пишу на лиспах и хаскеле. На Си++, если очень важна производительность. Мне так удобно.

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

сишные строки бывают либо медленные, либо очень медленные

Неправильно спросил. В каком языке они быстрые?

В любом, кроме Си и производных. Даже в питоне конкатенирование строк (это примерно половина всех операций над строками) быстрое — медленное там совсем другое. Это уже не говоря про кусочные строки с ценой конкатенирования и взятия подстроки O(1).

Хочешь сказать, что в старом Си
for(i = 0; i < 10; i++) ...
Всегда разворачивалось в

Здесь у «i» размещение, которое в стандарте называется «auto» — компилятор может разместить ее где хочет, и не обязательно в памяти.

В любом, кроме Си и производных.

Паскаль? ML? Haskell? Lisp?

Здесь у «i» размещение, которое в стандарте называется «auto» — компилятор может разместить ее где хочет, и не обязательно в памяти.

Так я про это и пишу. До volatile было или auto или register. И для auto было допустимо «из памяти в регистр данные загрузятся, а обратно выгрузятся только после полного окончания работы с ней». Потом поняли, что нужен явный запрет, ввели volatile.

Даже в питоне конкатенирование строк (это примерно половина всех операций над строками) быстрое

Оно каждый раз создаёт новую строку.

результат = ""
for строка in строки:
    результат += строка

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

А null — это что, если не указатель?

Семантически, это специальный объект.

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

Нет арифметики. Невозможен указатель на несуществующий объект.

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

Почитал. Не нашёл описания поведения, если сделать dispose, а потом записать в этот адрес данные. Или в каком пункте?
ISO 7185:1990

Это не оригинальная спека, паскаль написан в 1970-1971 годах:
https://oberoncore.ru/_media/library/wirth_the_programming_language_pascal.pdf
Тут вообще new/dispose нет. Поздний стандарт паскаля по сути описывал Turbo Pascal.

Так Си++ удобнее. Я про это и пишу

И я про это в растосрачах пишу. Но не потому, что C++ так хорош, а потому что раст еще хуже.

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

Это если ты уже работаешь кодером на JS или каким-то манагером, и вот тебе нужно написать что-то по шурику, и при этом ты не никсовый утенок для которого существует только баш и Си. Люди, которые только входят в кодинг, открывают TIOBE и смотрят, какой ЯП на первом месте — вот тебе и весь объективный анализ.

Код на разных языках можно склеивать, если есть стандарт на ABI

И это неправильный ответ. А также причина того, почему в той же Sun/Oracle JVM невозможен эффективный вызов внешних функций. Потому что ABI — это далеко не универсальное решение всех проблем. Например, вставки на асме стали нынче нормой, но мало кто помнит, что не так давно лисповые вставки в асме были нормальным явлением. Сишный ABI используется только для агностичной интеграции, то есть, «я вызываю функцию, не имея не малейшего понятия, на каком языке ее реализовали». Что, на самом деле, далеко не везде применимо, включая упомянутую жаву. Например, если сишная функция захватит себе управление на пару минут (например, выдав окошко), то она может завалить всё приложение.

Противоречивое утверждение. Как раз volatile ввели чтобы избегать оптимизаций в виде этих «перемещений»

Да. А откуда эти «оптимизации» появлились? В исходном K&R их не было. Эти оптимизации превращали корректные программы в некорректные — аналогичным образом недавно случилось со strict aliasing.

Если программировать для себя, то именно так. И я для себя пишу на лиспах и хаскеле

Ну и нафига ты пишешь на хаскеле? Я примерно две недели потратил на изучение хаскеля, и пришел к однозначному выводу, что язык создан математиком, который совершенно не понимает потребностей прикладного программирования. А именно, речь идет про ленивые вычисления по умолчанию и дикие монады вместо простого примитива последовательного выполнения. В итоге ради 1% сложных задач хаскель выносит мозги в 99% простых задач. На самом деле это очень частая ошибка манагеров-вахтереов, мол «добавим фичу — вдруг пригодится», но они не понимают, что самая-самая-самая главная фича ЯП — это ПРОСТОТА, именно потому хаскель — очень плохой язык. Как и C++, и Rust, и Ada, и, внезапно, Python (в данном случае речь идет про семантику, которая больше относится к сложности стандартной либы).

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

Вот и я об этом. Техническая сторона вопроса в IT никого не волнует.

Оно каждый раз создаёт новую строку.

результат = «»
for строка in строки:
результат += строка
имеет явную квадратичную зависимость от длины результата.

Не надо так делать, делай вот так:

результат = "".join(строки)

Паскаль? ML? Haskell? Lisp?

Да, паскаль. В CL, если я не ошибаюсь, применяются сишные строки. В хаскеле есть более одной реализации.

И для auto было допустимо «из памяти в регистр данные загрузятся, а обратно выгрузятся только после полного окончания работы с ней». Потом поняли, что нужен явный запрет, ввели volatile

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

Какого хера вообще возможность взять указатель на несуществующий объект должно быть фичой языка?

Какой объект? Есть только адреса, всё остальное в воображении программиста. Вы хотите вместо сишки высокоуровневый ЯП. Она просто обманчива похожа на такой, но им не является ни разу. Проблема в том, что на сишке продолжают писать всё подряд. В том числе прикладное ПО. Лучше ничего так и не придумали.

Да во всех высокоуровневых языках, кроме Си-производных, ссылки-указатели были в той иоли иной степени безопасны.

Фортран, Паскаль, Ада — это Си-производные? Вообще говоря, это неустранимая проблема при ручном управлении памятью.

Какого хера вообще возможность взять указатель на несуществующий объект должно быть фичой языка?

Потому что память освобождается вручную. И как только она освобождена, все указатели на неё становятся указателями на несуществующий объект. А при доле невезения, указателями на другой объект возможно другого типа.

Тут вообще new/dispose нет.

Тоже вариант. Нет динамической памяти, нет UB. Так и на Си можно.

Но не потому, что C++ так хорош, а потому что раст еще хуже.

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

Люди, которые только входят в кодинг, открывают TIOBE и смотрят, какой ЯП на первом месте — вот тебе и весь объективный анализ.

Так эти люди и не выбирают. Выбирают те, которые этих людей, входящих в кодинг, нанимают. И основной критерий — наличие черновика решения требуемой задачи. То есть под бухгалтерию РФ, например, выберут 1С, а под написание 3D игры — C++.

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

JVM не может чужие функции запускать не в основном потоке?

Сишный ABI используется только для агностичной интеграции, то есть, «я вызываю функцию, не имея не малейшего понятия, на каком языке ее реализовали»

Приведи пример другой интеграции. Почему PyQt сделан через Сишные структуры, хотя достоверно известно, что на одном конце Си++, а на другом питон?

Да. А откуда эти «оптимизации» появлились? В исходном K&R их не было.

Ещё раз спрашиваю, в исходном K&R цикл for на каждой итерации дважды читал и раз записывал память?

Ну и нафига ты пишешь на хаскеле?

Мне удобно.

В итоге ради 1% сложных задач хаскель выносит мозги в 99% простых задач.

Простые задачи решаются также просто. Зато имеем почти автоматические тесты, лаконичные программы и лёгкость описания алгоритмов в стиле конвейера.

самая-самая-самая главная фича ЯП — это ПРОСТОТА, именно потому хаскель — очень плохой язык

Хаскель — очень простой язык. Просто не надо из него пытаться сделать паскаль.

JVM не может чужие функции запускать не в основном потоке?

См. Future API.

В старом Си тут register i.

В старом Си тут register i.

То есть, по сути, поменялось умолчание. Было register/auto, стало auto/volatile. Потому что переменных, которые надо всегда писать в память, намного меньше, чем нормальных.

Ну вот. То есть сишная функция заблокировать всё приложение целиком может, только если программист ей это позволит.

Ещё один эффект register

int main()
{
	register a[42];
	auto b[42];
	b;
	a; // не Си!
}

Любая функция в Java - блокирующая (синхронная), если не обёрнута в специальный (асинхронный) API.

Какой объект? Есть только адреса, всё остальное в воображении программиста. Вы хотите вместо сишки высокоуровневый ЯП

Разговор был не про сишку, а про другие языки, который по какой-то причине должны все поголовно иметь ту же арифметику на указателях и UB-driven behavior.

Фортран, Паскаль, Ада — это Си-производные? Вообще говоря, это неустранимая проблема при ручном управлении памятью

Нет. И там не было таких проблем с UB.

Какого хера вообще возможность взять указатель на несуществующий объект должно быть фичой языка?

Потому что память освобождается вручную.

Ну, а почему она высвобождается вручную? Даже банальный refcount (из Swift) — это ручное высвобождение по-твоему или нет?

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

95% кода выполняется 5% времени. Причина заключается в сочетаемости, а не в том, что обработчик нажатия на кнопку нужно оптимизировать до последних процентов. Ну и в 90-х был бум однозадачных GUI софтин, для которых выжимание последних каплей производительности значило большую разницу в плавности работы программы, но даже это уже неактально где-то после 2010.\

Так эти люди и не выбирают. Выбирают те, которые этих людей, входящих в кодинг, нанимают. И основной критерий — наличие черновика решения требуемой задачи. То есть под бухгалтерию РФ, например, выберут 1С, а под написание 3D игры — C++

В девяностые игры писались с полного нуля. Сейчас игры уже на C++ и не пишут почти — вместо этого всякие C#, JS, или даже в гуе блоки рисовать в UE.

JVM не может чужие функции запускать не в основном потоке?

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

Приведи пример другой интеграции. Почему PyQt сделан через Сишные структуры, хотя достоверно известно, что на одном конце Си++, а на другом питон?

Приведу. PyPy. Половина проекта — это переписывание сишных реализаций либ на RPython.

Почему PyQt сделан через Сишные структуры, хотя достоверно известно, что на одном конце Си++, а на другом питон?

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

Ещё раз спрашиваю, в исходном K&R цикл for на каждой итерации дважды читал и раз записывал память?

Да.

Зато имеем почти автоматические тесты, лаконичные программы и лёгкость описания алгоритмов в стиле конвейера

Лаконичная != простая в чтении. Программу на хаскеле крайне тяжело читать, даже легко описанные алгоритмы в стиле конвееров. Обманчивая лаконичность поворачивается задом, как только ты делаешь один шаг в сторону и созерцаешь целый экран невнятных сообщений об ошибок, причем, чтение исходного кода не дает понимания причины ошибки, потому что ошибка может быть вызвана банальным пробелом — это уже почти на грани эзотерического языка.

Хаскель — очень простой язык. Просто не надо из него пытаться сделать паскаль

А ассемблер еще проще. Только почему-то сделать работающую программу на нем намного сложнее.

А ассемблер еще проще.

Ассемблер конвейерный на хаскеле?

Нет. И там не было таких проблем с UB.

При записи в указатель после dispose наблюдается UB во всех трёх.

Ну, а почему она высвобождается вручную?

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

Даже банальный refcount (из Swift) — это ручное высвобождение по-твоему или нет?

Нет.

значило большую разницу в плавности работы программы

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

Сейчас игры уже на C++ и не пишут почти — вместо этого всякие C#, JS, или даже в гуе блоки рисовать в UE.

Любой язык, где есть готовая библиотека для написания данного класса игр.

Приведу. PyPy. Половина проекта — это переписывание сишных реализаций либ на RPython.

И? Какой язык с каким интегрировался и через какое ABI?

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

Если у тебя сишный код на макросах, то ты сможешь его дернуть только из C. Это не помешало сделать сишный ABI стандартом. Шаблоны — это не код, а макросы.

Программу на хаскеле крайне тяжело читать

Там обычная алгебраическая запись, куда уж проще?

process context templateFile outFile =
    readFile templateFile
        >>= foldM (processLine processTemplate) context . lines
        >>= writeFile outFile . unlines . reverse . result

прочитать templateFile
разбить на строки
обработать каждую построчным алгоритмом из processTemplate с 
           сохранением состояния в структуре context 
взять результат из context
развернуть, собрать из строк в текст, записать в outFile

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

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

...и ни один математик так делать не будет. Список это всего лишь свободный моноид над каким-то множеством.
Да, и математики на самом деле не думают одними лишь множествами: https://arxiv.org/pdf/1212.6543.pdf

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

Отнюдь, всё необходимое уже есть в этом определении.
Единственное но: следует различать математические объекты и структуры данных, которые им как-то соответствуют. Чтобы рассуждать о структурах данных может также потребоваться модель вычисления.

Pascal (delphy) программист у нас получает столько же денег сколько и остальные. Просто им становятся некоторые из нас, когда надо что-то добавить в старые проекты на делфи, которые ещё не перевели на qt

Я не нашёл в этом списке С. Значит у дельфийцев с работой все отлично.

А если серьёзно - жалко фортран. Удобный современный и игнорируемый язык.

Вакансии программиста на Фортран искать бесполезно, так как навыки программирования для связанных с ним вакансий вторичны и прежде всего требуются знания предметной области и численных методов как таковых. Исключением, наверное, могут быть позиции для реализации чего-нибудь для HPC на распределённых системах и то в случае крупных организаций.

Что интересно- у нас такие задачи решают на плис и соответственно в матлабе или на dsp на c/c++. И фортран оказался не у дел. Ну может на метеорологоческих кластерах используется.

А если серьёзно - жалко фортран.

Неудавшийся Бейсик жалко?

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

вакансии с Фортраном начинаются от 3000$/mo. И не то чтобы их сложно найти.

При записи в указатель после dispose наблюдается UB во всех трёх

В Фортране в норме применяется автоматическое управление памятью и нет свободных указателей, потому нужно специально постараться, чтобы написать некорректный код. В Аде есть и автоматически высобождаемые стэковые массивы, но есть и с ручным управлением, которые после Deallocate становятся null, и потому никакого UB не происходит, если не постараться специально. Именно бесконтрольное оперирование указателем как числом является причиной всехз проблем Си — и потому этих проблем нет в Fortran и Ada.

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

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

Даже банальный refcount (из Swift) — это ручное высвобождение по-твоему или нет?

Нет

То есть, вся проблема от того, что в языке Си 50 лет дедушки, сидящие за vt100 в 2004 году, не могли родить

__attribute__ cleanup

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

Для большинства прикладных задач пофигу вообще. Между прочим, индустрия по факту выбрала решать систему уравнений за 5 минут (это я про питон). Вот для GUI разница между 50 мс и 5 секунд — это действительно пропасть.

И? Какой язык с каким интегрировался и через какое ABI?

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

Если у тебя сишный код на макросах, то ты сможешь его дернуть только из C. Это не помешало сделать сишный ABI стандартом. Шаблоны — это не код, а макросы

Макросы макросам рознь. Стандартный сишный ABI применяет крайне ограниченное подмножество макросов, и именно потому становится стандартом ABI. В принципе, если из C++ выкинуть половину фич (прежде всего шаблоны и исключения), то у него тоже появится норм ABI, правда, при этом исчезнет почти вся крестовая стандартная библиотека.