Інтерпретоване проти складеного: Корисна відмінність?

Тут задають багато питань щодо інтерпретованих та компільованих мовних програм. Мені цікаво, чи відрізняння насправді має сенс. (Насправді питання зазвичай стосуються мов, але вони дійсно замислюються над найпопулярнішими реалізаціями цих мов).

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

Насправді більшість впроваджень сходяться на одній і тій же базовій стратегії. Компілятор виробляє байтовий код, який інтерпретується або компілюється в нативний код через JIT. Це дійсно поєднання традиційних ідей складання та інтерпретації.

Отже, я запитую: Чи корисна відмінність між інтерпретованими реалізаціями та складеною реалізацією в ці дні?

Важливо пам’ятати, що інтерпретація та складання не є лише альтернативою один одному. Зрештою, будь-яка програма, яку ви пишете (включаючи одну, складену до машинного коду), буде інтерпретована. Інтерпретувати код просто означає взяти набір інструкцій і повернути відповідь.

З іншого боку, компілювання означає перетворення програми з однієї мови на іншу. Зазвичай передбачається, що коли відбувається компіляція, код компілюється на мову "нижчого рівня" (наприклад, машинний код, якийсь байт-код VM тощо). Цей скомпільований код все ще інтерпретується згодом.

Що стосується вашого питання про те, чи є корисна відмінність між інтерпретованими та складеними мовами, моя особиста думка полягає в тому, що кожен повинен мати базове розуміння того, що відбувається з кодом, який вони пишуть під час тлумачення. Отже, якщо їх код збирається JIT або кешується байт-кодом тощо, програміст повинен хоча б мати базове розуміння того, що це означає.

Відмінність має глибоке значення, оскільки складені мови обмежують семантику способами, що інтерпретовані мови не обов'язково. Деякі методи інтерпретації складно (практично неможливо) скласти.

Інтерпретований код може робити такі речі, як генерування коду під час виконання, і надавати видимість цього коду в лексичні прив'язки існуючої області застосування. Це один приклад. Інша полягає в тому, що перекладачів можна розширити інтерпретованим кодом, який може керувати тим, як оцінюється код. Це є основою для стародавніх Lisp "fexprs": функції, які викликаються з неоціненими аргументами і вирішують, що з ними робити (маючи повний доступ до необхідного середовища для проходження коду та оцінки змінних тощо). У складених мовах ви не можете реально використовувати цю техніку; ви замість цього використовуєте макроси: функції, які викликаються під час компіляції з неоціненими аргументами, і перекладаєте код, а не інтерпретуючи.

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

Інтерпретація завжди буде корисна як техніка завантаження компілятора. Для конкретного прикладу подивіться CLISP (популярна реалізація Common Lisp). У CLISP є компілятор, написаний сам по собі. Коли ви створюєте CLISP, цей компілятор інтерпретується під час початкових етапів створення. Він використовується для компіляції, а потім, як тільки він складається, компіляція виконується за допомогою компільованого компілятора.

Без ядра інтерпретатора вам потрібно буде завантажитися з деякими існуючими Lisp, як це робить SBCL.

За допомогою інтерпретації ви можете розробити мову з абсолютного нуля, починаючи з асемблерної мови. Розробіть основні підпрограми вводу / виводу та основної програми, а потім напишіть мову, яка ще не є машиною. Після того, як ви отримаєте eval, пишіть мовою високого рівня; машинне кодове ядро ​​виконує оцінку. Скористайтеся цим засобом, щоб розширити бібліотеку ще багатьма процедурами та написати компілятор. Використовуйте компілятор для компіляції цих підпрограм та самого компілятора.

Інтерпретація: важливий трамплін на шляху, що веде до складання!

Насправді багато мов реалізації все ще строго трактуються, ви просто можете їх не знати. Щоб назвати декілька: мови оболонки UNIX, оболонки Windows cmd та PowerScript, Perl, awk, sed, MATLAB, Mathematica тощо.

Я думаю: Абсолютно так .

Насправді більшість впроваджень сходяться на одній і тій же базовій стратегії

Дійсно, C ++ має на меті перенести на домі компілятора якусь концепцію високого рівня, яку зазвичай передають перекладачам, але вона залишається на стороні меншості ...

Корисна відмінність: інтерпретовані програми можуть змінювати себе, додаючи або змінюючи функції під час виконання.