>>Ты пишешь на низкоуровневых языках, и не думаешь о том, в какой машинный код скомпилируется?
> Нет, конечно. Это бесполезно и даже вредно, потому что мешает писать переносимый
> и прозрачный код. Особенно некоторым умникам, которые своими кривыми "оптимизациями" плодят
> уязвимости.

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

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

>>на расте
>>C++
>>не думая о машинном коде
> Сейчас бы гадать, во что скомпилируются языки без ABI, лол.

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

>>Что помешает работать с кодом "бинарного html'а", как с текстом?
> Зачем вообще перегонять текст туда-обратно? Форматы изобретают, чтобы решить проблему,
> а не создать пачку новых.

Эээ... Да ты, я вижу, не разделяешь данные и формат данных. Ты не писал никогда на лиспе? Попробуй. Это очень развивающе тебе будет. Там есть текстовое представление для любого объекта, а если представление в памяти. Для некоторых объектов, скажем для функций, может быть аж целых три разных представления в памяти, в одной лисп-машине -- в виде лисповского списка, в виде байткода, в виде нейтив-кода. Поначалу, когда сталкиваешься с лиспом, это иногда даже сбивает с толку, но потом привыкаешь думать о данных как о данных, а о форме хранения этих данных как о преходящем их свойстве. (upd. а, да, забыл сказать главное, у каждого объекта ещё есть текстовое представление, в котором его всегда можно вывести на экран, и, скажем, скопипастить в сорец)

И это очень полезно о таких вещах думать. В том же C, например, твои int'ы постоянно меняют своё бинарное представление, потому что ты не следишь за всеми случайными преобразованиями, которые возникают. То у тебя char стал int'ом, потом вдруг опять char'ом... Бинарное представление меняется, а значение остаётся тем же. Из этого, кстати, вполне могут вылезать баги, потому что нечаянно можно отрезать несколько бит от инта.

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