Изначально верный ответ дал Аноним84701 :D
> Девочки, не ссорьтесь!
> Cуществует "и то и это".===============================
> если "результирующую" понимать как конечный этап (машинные коды операций), то да это и есть по моему мнению процесс компиляции
В программировании конечный этап компиляции так же не обязательно является машинным кодом, он так же может быть исходным кодом на ЯВУ, или любом другом (см. ниже).
> Хочу отметить, что я делаю именно акцент на "конечный этап трансляции" - это и есть компиляция.
Ну, это тоже не обязательно так, потому что компиляторы бывают разные и могут включать в процесс компиляции и трансляцию, и сборку, если нужно. В компиляторах процесс часто начинается с компиляции, и ей же заканчивается, при этом на выходе получается отранслированный, собранный, оптимизированный и даже исполняемый код. А линковка, компоновка и окончательная сборка может быть включена в процессе компилятора, а может и не включаться. Для их выполнения могут использоваться вызовы внешних утилит, как отдельно от компилятора (в каком нибудь скрипте сборки), так и самим компилятором.
> Сырбор всей дисскуссии начался с того, что "трансляция" (перевод) с одного исходного текста ЯП на другой исходный текст был назван как процесс компиляции. (Что по моему мнению - ложно. И попытаюсь это доказать в итоге.)
Да не ложно это.
В компиляторе есть две вещи - обработка данных (процессинг) и организация данных (компиляция - организация данных собранных из разных источников). Организационный процесс передаёт управление процессам связанным с обработкой данных - транслятору, оптимизатору, сборщику и пр. Берёт код в одной форме, передаёт другому процессу, получает код в новой форме, передаёт следующему.
Компиляция как глобальный процесс без трансляции не имеет смысла. (Но она возможна на уровне какого-нибудь интеллектуального оптимизатора. К примеру, разворачивание циклов без изменения языка исходного кода.). Поэтому часто пишут, что компилятор выполнил перевод из одного языка в другой. Я ниже в сообщениях приводил пример, как это выглядит в отношении пакета vala:
vala-0.40.11,1 Programming language and compiler that converts Vala code into C code
Никаких проблем с переводом из языка в язык при компиляции нет. Просто вы с товарищем пох смотрите на проблему с разных уровней. И хотя есть разница между процессами, правы вы оба. Действительно, процессом перевода занимается трансляция и действительно, она выполняется в процессе компиляции.
> Если бы каждый шаг L1 -> L2 -> L3 ... -> LN и весь процесс трансляций в целом называть компиляцией, то зачем мы еще порождаем всякие понятия L1 -> L1` (штрих) как "обфускация", "рефакторинг", "оптимизация"?
Потому что приходится различать дополнительные процессы внутри компиляции, которые обрабатывают разные промежуточные результаты по разным алгоритмам.
> Почему мы принимаем Java как "компилируемый язык"?
Потому что он компилируется в байт-код для виртуальной машины.
Но понятие "компилируемый язык" лично я не люблю. Потому что это зависит от реализации.
Например, для бейсика выпускались как компиляторы, так и интерпретаторы.
Или вот строчка из вики про Python: "В отличие от компилируемых языков программирования, в Python...".
То есть Python, фактически, объявляется некомпилируемым языком. И при этом "Файлы .pyc содержат скомпилированный байт-код исходных файлов Python". Но как же так? Ведь Python объявили интерпретируемым языком, а оказывается это не мешает его скомпилировать. Причём делает это лично интерпретатор Python, потому что в нём есть модуль компиляции.
Мне больше нравится такое утверждение:
"a language is not "interpreted" or "compiled" as such. A specific implementation can be an interpreter or a compiler (or a hybrid or a JIT compiler or a vm etc)".
Написать интерпретатор java помешает лицензия и огромный объём работы, но возможность этого никто не отменял. :)
Будет своя тормозная реализация интерпретатора джавы без виртуальной машины.
Можешь даже сам попробовать реализовать интерпретатор хотя бы для небольшого подмножества джавы (хотя бы операторы c++) и всё будет работать. Компилируемый, интерпретируемый - это просто ярлыки, применимые для конкретных реализаций.
> компиляция тут заключается только лишь в процессе трансляции Java -> Java-bytecode, но не Python -> Java
Именно тут ошибка.
Твоё недопонимание в том, что ты воспринимаешь процесс компиляции как отдельный процесс обработки данных. А он занимается организацией и передачей/приёмом обрабатываемых данных далее по цепочке. А проблема в том, что в основном компиляция использовалась для перевода исходного кода в машинный. Вот и привыкли так считать.
К dragonbook, и раз тебе нравится вики, можно добавить ссылку:
https://en.wikipedia.org/wiki/Source-to-source_compiler
> пс: всем спасибо за участие в дискуссии
Взаимно! :)
-------------------------------------------------------
Резюме:
1) компиляция != трансляция - процессы разные, трансляция выполняется внутри компиляции
2) компилятор == транслятор - компилятор выполняет трансляцию в процессе компиляции
3) "конечный этап" не обязательно равен "машинные коды операций". это частный случай. можно скомпилировать исходный код одного языка в исходный код другого
Пожелание:
Смотрим рисунок 1.4 в книге драконов, думаем, почему вся схема называется схемой гибридного компилятора, и почему в ней есть прямоугольник с надписью транслятор.
На этом я завершаю свой флуд.
