Есть вообще возможность насильно заставить в Python сделать "11"+5?

Через перегрузку арифметических операторов разве что

Нет, чтобы было именно "11"+5. Без изменения типов данных.

Не понял, а как ты вообще собираешься это сделать?

В памяти это должно лежать как 0x3131, неужели в Python всё настолько плохо, что я не могу добавить к этому значению памяти 5?

Ну почему же? Конечно это сделать можно, но не просто "11"+5

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

Понятное дело, наложить в мозг программиста как можно больше абстракций.

Зато можно наложить много более менее рабочего кода за относительно небольшое время, несравнимо меньшее чем даже с/с++ и уж тем более асм

Это субьективно. Уже доказано, что многие операции в ЯВУ реализуются по итогу длиннее и сложнее, чем в ассемблере.

Длинее и сложнее в человеко-часах программиста или машино-часах компа-исполнителя программы?

В человеко-часах.

Нуууу. Чистый численный или строковой алгоритм - я еще поверю. Но все что сложнее....все что по сути является вызовом многочисленных внешних библиотек....напишите простую веб форму работающую под апаче и сохраняющую данные в SQL базу данных. Рнр, питон или еще чтото такое - буквально 10 минут работы. На асме- 10 дней? Библиотек нет, заголовочные файлы иди найди, порядок вызовов интерфейсов - разберись.....

30 минут.

Хотя, стоп, некорректно сравнивать веб и ассемблер. Нужно сравнивать ассемблер с С, C#, иногда с Python. Я могу также спросить, за сколько ты такую задачу на С сделаешь? Тебе придётся буквально переписать PHP.

С - ассемблер для ленивых, это давно известно.

С - это вообще не ассемблер

И это тоже субьективно. Абстракции могут как упростить, так и жутко усложнить задачи. Зачастую, на С код получается с кучей сложных выражений, когда на ассемблере это реализуется 3-4 инструкциями.

в KolibriOS используется Sphinx C - - . Вот это действительно полноценный ассемблер, но со вкусом Си

Например ряд Фибоначчи

Это образное определение

Странно отождествлять ЯВУ с ассемблером странно

На ассемблере это вообще 1 строка будет. Хотя, нет, 2.

Тело цикла в две строки, да)

3

Вообще, на ассемблере развивается такое особенное мышление представления о памяти. Когда на С чтобы парсить BMP, все бегут за библиотеками, ты просто находишь структуру BMP со смещениями, и делаешь mov eax, dword[bmp+field_offset] Я так в последнем проекте с дизерингом и делал, и получилось тоже намного короче и понятнее, чем в С.

Я и на Турбо Паскале так BMP писал.

и непортируемо)) хотя, может такая задача и не ставилась

Непротируемо на чт?

Ещё пример с парсером PE в ЯВУ и ассемблере. Как выглядит в С: PIMAGE_DOS_HEADER hdos = (PIMAGE_DOS_HEADER)pe_file.data(); PIMAGE_NT_HEADERS hpe = (PIMAGE_NT_HEADERS)((DWORD)hdos + hdos->e_lfanew); Как выглядит в ассемблере: mov eax, dword[pe+0x3c] add eax, pe

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

А потом тебе присылают специальный битый файл и ты исполняешь уже его 😄

Тут ничего не исполняется. И в С тоже нет проверки на правильность структуры.

А не надо исполнять данные.

В с библиотеке для bmp нет проверок?

А там RLE. А там 5 пикселов в строке. А там top-down…

А, я думал ты про PE. Да, есть проверки. И на ассемблере тоже легко их добавить. При этом ты добавляешь только под конкретные данные, когда на С ты тянешь всю библиотеку.

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

Для бинарных структур да, а Попробуйте на асме с парсить xml, json или все эти новомодные форматы, тут-то как раз Яву и проще

Тут будет почти одинаково. А если макросы использовать, то вообще почти один-в-один.

нет не об этом, низкоуровневые манипуляции полезны для многих языков