Нет такой вещи как “скомпилированный язык” или “интерпретируемый язык”

Приведенное выше утверждение верно.

С другой стороны, кто-то может возразить, что это не совсем так в реальном мире. Если все существующие реализации языка полагаются на компиляцию, язык с полным правом можно назвать скомпилированным языком.

Вроде того. Как правило, и интерпретаторы, и компиляторы сначала должны разобрать исходный код и преобразовать его в представление, называемое AST (абстрактное синтаксическое дерево). Затем компилятор превращает AST в исполняемый код (путем различных преобразований), в то время как интерпретатор может просто напрямую "интерпретировать" AST или иногда компилировать и исполнять его (компиляция "точно в срок").

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

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

Дизайн языка имеет отношение к грамматике для входной части верхнего уровня и выходного кода нижнего уровня, который выполняется на целевом объекте.

Между ними есть абстрактное синтаксическое дерево.

Традиционно, если вы пишете код вывода нижнего уровня для выполнения на определенной аппаратной платформе и ее конкретном наборе инструкций, вывод «компилируется».

Если кто-то решает написать интерпретатор, который будет действовать как цель, выходной код - это набор инструкций или байт-код, который ожидает интерпретатор. Дополнительный уровень косвенности означает, что интерпретируемый код может работать на любой аппаратной платформе, имеющей реализацию интерпретатора.

Таким образом, утверждение является правильным, если мы называем «языковым дизайном» грамматику и часть лексера / синтаксического анализатора.

Это не совсем правильно, если мы говорим о генераторе кода.

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

Так что, возможно, поэтому различие стирается. Но я думаю, что он все еще там.

Это верно только в том смысле, что в конечном итоге и скомпилированные, и интерпретируемые языки должны генерировать машинный код. Это действительно влияет на язык, поскольку традиционно одни парадигмы проще в использовании, чем в других. Например, в общем случае замыкания или блоки легче реализовать на интерпретируемых языках, чем на компилируемых языках. Это верно, поскольку фактически нет разницы между областью видимости времени компиляции и времени выполнения в интерпретируемых языках. Таким образом, TENDS с динамической областью видимости будет проще реализовать в интерпретируемых языках.

Определенная реализация языка будет либо "чистым" компилятором (чей результат выполняется процессором как код), либо "чистым" интерпретатором (каждый оператор рассматривается впервые, в виде исходного текста, по мере его выполнения, и ничего об интерпретации не кэшируется), либо гибридом между ними. Довольно легко отличить "чистые" случаи от гибридов, но некоторые гибриды "ближе" к компиляции, чем другие; границы между "компилированным" гибридом и "интерпретированным" могут быть довольно нечеткими.

Я не думаю, что существует какой-либо язык, кроме ассемблера (для которого обычно используется термин "ассемблер", а не "компилятор"), который не мог бы быть реализован хотя бы в некоторой степени практически в гибридном интерпретаторе (производительность "чистого" интерпретатора будет ужасной при использовании любых, кроме самых тривиальных конструкций циклов). Однако есть некоторые языки, которые позволяют динамически генерировать код таким образом, что он не поддается компиляции.

Кстати, когда я говорю "исходный текст", я не всегда имею в виду текстовый формат. Мой первый программируемый калькулятор имел 99 шагов программы, каждый из которых мог быть настроен нажатием клавиши или одной из нескольких специальных инструкций последовательности. Программа никогда не существовала в человекочитаемой текстовой форме как таковой, а скорее как последовательность номеров клавиш. Тем не менее, я бы описал это как чисто интерпретируемый "язык", поскольку каждый шаг программы оценивался совершенно независимо.

Вся эта история с компилятором/интерпретатором зависит от того, каковы ваши намерения относительно программы. Скомпилированная программа - это программа, преобразованная в машинный код. Интерпретатор используется для чтения промежуточного языка и выполнения его на машине. Например, когда вы компилируете Java, программа превращается в Java Bytecode, который читается и выполняется интерпретатором (что также объясняет недостаток скорости по сравнению с C++).

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

Стоит отметить, что для (некоторых?) Языков, которые включают оператор типа "eval" (особенно если до времени выполнения невозможно определить, является ли данный блок кодом или данными), даже наиболее скомпилированная версия данной программы должна быть частично интерпретирована. Для таких языков невозможно полностью скомпилировать их (скомпилированный код должен содержать интерпретатор для языка).

В качестве примера рассмотрим следующий код:

set s [eval {sum $a $b $c}]

Для вышеприведенного кода Tcl до времени выполнения невозможно определить, является ли блок (внутри {}) кодом или нет.