В чем преимущество интерпретируемых языков перед компилируемыми?

Википедия говорит например что преимущества это

  1. кроссплатформенность
  2. пошаговое отслеживание (отладка)
  3. динамическая типизация

Вроде бы все абсолютно логично но можно предположить что мы можем перед выполнением компилируемой программы просто собирать ее т.е. грубо говоря вместо команды выполнения будет команды сборки+выполнения из этого предположения следую вопросы к этим пунктам

  1. Если мы однажды должны установить интерпретатор по нашу ос+архитектуру и т.п. почему мы не можем установить компилятор так же под нашу ос и собирать каждый раз проект из исходников например с++
  2. На данный момент мы же можем отлаживать код С++ пошагово? не совсем понимаю этот пункт
  3. Вроде бы динамическая типизация жестко не привязана к интерпретируемым языкам т.е. может быть реализована и в компилируемых?

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


Ответы (1 шт):

Автор решения: Stanislav Volodarskiy

В чем преимущество интерпретируемых языков перед компилируемыми?

Википедия говорит например что преимущества это

кроссплатформенность

Java - кроссплатформенный компилируемый язык со строгой типизацией.

пошаговое отслеживание (отладка)

Компиляция препятствует отладке и в интерпретируемых языках. Сложные вложенные list comprehensions с генераторами сложно отлаживать пошагово потому что это сложные конструкции со сложными правилами (хотя они хотят выглядеть легкими и приятными).

динамическая типизация

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

Вроде бы все абсолютно логично но можно предположить что мы можем перед выполнением компилируемой программы просто собирать ее т.е. грубо говоря вместо команды выполнения будет команды сборки+выполнения из этого предположения следую вопросы к этим пунктам

Если мы однажды должны установить интерпретатор по нашу ос+архитектуру и т.п. почему мы не можем установить компилятор так же под нашу ос и собирать каждый раз проект из исходников например с++

Всё так и есть, разницы почти нет. Существенная разница такая: Python имеет встроенный компилятор (можно исполнить код из текста), C++ не имеет. Но есть компилируемые языки со встроенными компиляторами - Lisp.

На данный момент мы же можем отлаживать код С++ пошагово? не совсем понимаю этот пункт

Можете, если не применяли агрессивные оптимизации. Чем сильнее оптимизируется код, тем слабее соответствие между исходным кодом и машинными инструкциями. Замечу что для C есть чистые интерпретаторы, хотя они мало полезны в отладке из-за недостаточной переносимости языка.

Вроде бы динамическая типизация жестко не привязана к интерпретируемым языкам т.е. может быть реализована и в компилируемых?

Да, примеры были выше.

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

Обычно интерпретаторы стартуют быстрее потому что у них простые компиляторы без глубоких оптимизаций. Но Pascal компилировался в машинный код (Turbo Pascal). Исходный код Паскаля рассчитан на однопроходную компиляцию. IDE работала быстрее чем QBasic.

Разделение интерпретатор/компилятор имеет исторические корни. Первые интерпретируемые языки не проводили компиляцию (BASIC). Сам язык BASIC со строчно-ориентированным синтаксисом разработан для построчной интерпретации.

Компилятор ТурбоПаскаля порождал машинный код в один проход, без введения промежуточного представления чтобы расходовать меньше памяти (он вообще весь работал в памяти без обращения к диску - диском была медленная дискета).

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

Предлагаю другую классификацию: динамическая/статическая типизация и возможность исполнения произвольного кода во время исполнения программы.

→ Ссылка