> нет не стоит, и он от ЯП других ничем не отличается,То что не отличается, я даже не спорил, а вот то что все же стоИт, пусть в основном и по историческим причинам "так принято" - с этим как раз сталкиваешься достаточно часто (см. man gcc опция -S или -c)
> И я именно эту стадию считаю как понятие "компиляции", в других случаях это все трансляция (перевод).
*пожимая плечами* а авторы библиотеки похоже придерживаются другой классификации и наверное стоит принимать во внимание в первую очередь ее.
>>Если брать ту же Книгу Драконов, то assembly там одна из возможных конечных целей компилятора.
> что есть конечная цель? представить код "понятный" процессору (машине).
Это очередная неточность перевода:
Конечная цель - в смысле результата работы самого компилятора: в оригинале "compiler target".
Ну и не припоминается ни одного современного компилятора, генерирующего сразу машинный код.
В качестве еще одного примера приходит на ум тот же (g)as, как "классический" бэкэнд для gcc.
Кстати, там (как и в clang, других компиляторов чтобы проверить, у меня сейчас нет), как раз различают этот нюанс:
man gcc
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
[...]
Unrecognized input files, not requiring compilation or assembly,
are ignored. -S Stop after the stage of compilation proper; do not assemble.
man clang
-c Run all of the above, plus the assembler, generating a target
".o" object file.
> так проблема в строгом определении любого понятия, ибо если его нет, то
> все ведет к таким дискуссиям (холиварам). Можем еще и похоливарить на тему JIT компиляции.
Вообще-то я считаю, что намного важнее ввести отдельный термин смузилятор для обзначения трансляции кода старых ЯП в относительно новые с помощью нейронных сетей, работающих на смузи :)
