> > Си и Си++, ага.
> C, C++ - это языки высокого уровня, а не ассемблеры

Вы не одиноки в этом маркетоидном заблуждении.

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

> в остальном ни хуя не понял
> где утверждение в твоем тексте?
Я понял, главные мысли надо будет выделять болдом, а то многа букав. «Только вся беда как раз в том, что... низкого уровня описания алгоритма, предоставляемого этими "платформонезависимыми ассемблерами", уже не хватает.»

В век P2P-систем, многоядерных процессоров и видеоускорителей, более мощных, чем компьютеры в ЦУПах первых космических полётов, народ с помощью компьютеров начал решать всё более и более сложные задачи. (Примеры: поиск внеземной жизни. Ну, или игра в управление автомобилем, "совсем как настоящим").
Которые только для того, чтобы быть решёнными, требуют всё более и более сложных инструментов для их решения. (Примеры: статистический анализ, лет 20 назад бывший доступным только серьёзным компьютерным центрам. Ну, или автосимуляторы с достойной современного уровня физикой автомобиля и детальностью трасс. Опять же, лет 20 назад доступные только серьёзным компьютерным центрам. Если вообще доступные.)
Которые, только для того, чтобы быть написанными, требуют всё более и более высокоуровневых языков программирования.
Потому что с помощью ассемблера Оракл не напишешь.
Не, вообще не напишешь.
Даже если сто тысяч программистов посадить. "Мифический человеко-месяц" Брукса.
Даже если одного программиста на двадцать лет посадить решать - всё равно не напишешь. Потому что сложность программы с её ростом растёт не линейно по отношению к её росту, а линейно по отношению к количеству связей в ней. Ну, для простоты, можно считать, что экспоненциально по отношению к росту.

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

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

Ассемблер - это совочек. Платформонезависимый ассемблер - это универсальный совочек.

> я так понимаю, языков высокого уровня ещё нету в природе?
Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе. Надо ещё Perl и Python попробовать, но думаю, проблем не будет.

> я нигде не мог спиздеть, что нужно программить на ассемблере
Что ж, это уже лучше. Только...

> я лишь объяснял, почему платформонезависимый ассемблер - шаг вперёд
> он занимает свою ступень в качестве прослойки в иерархии средств программирования
> на него сверху водружаются платформонезависимые языки
Я так понял, что имелось в виду скорее что-то "платформонезависимого машинного кода". Ибо ассемблер - это всё-таки human-readable представление машинного кода, а человеку на этот уровень спускаться вовсе и не надо. Меня слово "ассемблер" в данном случае смутило.

Впрочем, это не лучше. Платформонезависимый машинный код, будь то IL, Java bytecode или ещё что-то подобное, как самоцель тоже смысла не имеет. Проинлайнить вызов функции современный компилятор и так способен догадаться, а дополнительный код, собирающий статистику вызова методов, будет жрать весьма немало ресурсов. При таки достаточно сомнительной от него пользе.
Но при этом на этапе компиляции компилятору ЯВУ доступно гораздо больше информации, чем интерпретатору промежуточного кода. И больше времени, ага - компилятор во времени особо не ограничен, а интерпретаторокомпилятор промужеточного кода должен работать в какие-нибудь конечные разумные сроки.

> что касается прогресса в отношении новых ставящихся задач,
> нету усложнения алгоритмической сложности, и не было особо за последние 30 лет,

Ну смотря какого усложнения вы ищете. Вы примерно внутренности последних СУБД Oracle-а представить можете? А как вам рендереры фотореалистичных картинок, работающие нынче чуть ли не в реальном времени в компьютерных игрушках, а 30 лет назад... кхм, вообще только начинавшиеся (http://en.wikipedia.org/wiki/Timeline_of_CGI_in_films#1970s)? А в современных "властелинах колец" не просто векторную картинку скриптуют, а создают модели бегущих толп...

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

> > Ну почему же. Шелл-скрипты вполне одинаково работают на 32-битном и 64-битном линуксе.
> ещё на Виндозе, угу охуенная переносимость
А что, ничего переносимость. На линуксах под пару десятков нехило различающихся платформ, да на десятке проприетарных юниксов, на которые портированы интерпретаторы шелла. Ну, и ещё на Windows. Куда уж больше...

> > СУБД Oracle-а представить можете? А как вам рендереры фотореалистичных картинок, работающие нынче чуть ли не в реальном времени в компьютерных игрушках

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