> ну эта же "коротизна" она на уровне формального языка, не машинной инструкции, Угу, она на уровне инструкций к моим пальцам. Которые совсем не рады этому.
> где как не крути есть допустимый минимум кодирования той или иной
> операции. a+b или add(a,b) одинаково будет представленно (закодировано) в виде КОП
> (код операции) в зависимости от архитектуры.
Зато моим пальцам сильно предпочтительнее первый вариант. По тем же причинам {} лучше чем begin/end.
> Отсюда не вижу принципиальной разницы "коротизны" для формального языка.
Зато видят мои пальцы, на которые нагрузка утроилась. RSI никогда не ощущали? :)
> сторонник всех этих формальных языков, допускаю только один формальный язык, мнемонический
> язык машины. Такой язык лучше с точки зрения понимания машины (архитектуры),
> ибо зная как работает машина, можно оптимально писать под нее программы.
Как бы это сказать? У ассемблера есть одна маленькая проблемка: он вообще паршиво поддается структурированию. Процессору оно похрен, он железный, а вот человеку длинный однообразный неструктурированный список - в сколь нибудь большом проекте не дает отстроить глобальную картину происходяшего.
Локальное понимание работает в пределах единиц килобайтов кода. Потом сущностей для трекинга становится слишком много и ничего хорошего на асме вот так - уже не получается. Я видел большие проекты на асме, и это пожалуй самый жуткий код который вообще можно придумать. Поддерживать, менять и расширять такой проект становится невозможно вообще.
В этом месте мы начниаем догадываться почему программы делят на логические части, желательно независимые и реюзабельные (e.g. либы), делают некие абстракции чтобы вот тут только имплементация, а вооон там ее многочисленные детали, в которые можно и не смотреть если это не меняем, и так далее. Это конечно несколько нагибает локальное понимание происходящего, зато позволяет вертеть сильно более масштабным проектом, более-менее удерживая его в голове. В случае неструктурированного списка команд это, конечно, было бы совершенно без шансов.
