Яка різниця між складеними та інтерпретованими мовами програмування?


Відповідь 1:

Інтерпретація (оцінювання) програми зводиться до оцінки висловлювань на цій мові (виконання дій, які програма кодує).

Через процес складання мова перекладається на іншу мову. Під час компіляції, скажімо, C у виконуваному файлі, GCC (або будь-який компілятор, який ви використовуєте) переведе C на "виконувану" мову вашої машини. Процесор на вашому комп’ютері - це апаратне реалізація інтерпретатора для мови, визначеної архітектурою набору процесорів (можливо, X86-64).


Відповідь 2:

Терміни безглузді. Мова не є ні "інтерпретованою", ні "складеною": це просто мова. Інтерпретатори та компілятори - це методи реалізації (що деякі інші публікації тут пояснюють досить чітко). Практично будь-яка мова може бути реалізована в будь-якому випадку, і навіть в більшій кількості, ніж це (наприклад, JIT є гібридом двох). Візьміть дві канонічно "інтерпретовані" або "складені" мови: Схема для першої та С для другої. Я випадково вивчив схему за допомогою компілятора та C за допомогою інтерпретатора (так, вони існують).

Тому будь ласка, перестаньте використовувати ці терміни. Вони нічого не означають.

Ще одне пов'язане джерело плутанини - думати, лише тому, що ви бачите інтерактивне запит (він же, REPL), що він повинен бути перекладачем.

Багато років я використовував схему Chez, яка є повноцінним компілятором (і справді вражаючою). У Chez, коли ви вводите програму в запит на взаємодію, вона автоматично збирає програму, запускає її, а потім виводить відповідь. Словом, це компілятор. Це інтерактивне.

Ракетка використовує компілятор JIT. Це робиться тихо на задньому плані. PyPy забезпечує компілятор JIT для Python для доповнення звичайного інтерпретатора Python.

Мова програмування Pyret забезпечує середовище онлайн-програмування у веб-переглядачі. Коли ви вводите вираз, він негайно компілює цей вираз до JavaScript, просить JavaScript запустити його, а потім надрукує відповідь. Тобто Pyret також реалізується компілятором.

У моєму класі учні звичайно пишуть перекладачів. У них немає нічого особливо «інтерактивного». Оскільки вони є інтерактивними, це тому, що вони написані на Racket або Pyret, і тому успадковують інтерактивність навколишнього середовища - компілятор!

Тому не плутайте режим реалізації з режимом взаємодії. Тільки тому, що система взаємодіє певним чином, це не означає, що вона реалізована певним чином. Дійсно, це робить несправедливістю тих авторів-упорядників, котрі намагалися важко загорнути свої компілятори в цикл "читати-збирати-виконувати-друкувати", не даючи їм кредиту за їх роботу. Не кожному компілятору потрібно запустити cc в командному рядку та вручну виконати результат a.out.


Відповідь 3:

Уявіть, що ви говорите лише англійською, а ваш друг лише французькою. Ви пишете йому лист англійською мовою і просите двомовної людини перекласти його за вас.

Він запитує, чи хочете ви, щоб я приніс англійському листу вашому другові, стояв поруч із ним і перекладав йому одне речення за раз? Або ви хочете, щоб я переклав всю справу на французьку мову, а потім надішлю йому переклад?

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

Потрібно трапити якийсь переклад, оскільки ми програмуємо на зручних для людей мовах, але не корисних для комп'ютерів. Щоб комп'ютери змогли їх зрозуміти, тоді їх потрібно перекласти, інтерпретуючи або склавши.

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

Тоді як ви запускаєте інтерпретований код на будь-якому комп’ютері, ніж інтерпретатор. JavaScript - приклад. Коли він доставляється через Інтернет на ваш комп’ютер, він не є у версії Mac чи версії для ПК. Це у людській версії, яку ваш комп'ютер не розуміє. Потім він інтерпретується інтерпретатором, який "розмовляє" на Mac або ПК.

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

Сучасний комп’ютер працює так швидко, відставання часто не має значення для людини. Це помітно лише у високоінтенсивних процесорах, таких як 3D-ігри.


Відповідь 4:

Як слово попередження, це, мабуть, не відповідь, яку ви шукаєте. Ви, швидше за все, шукаєте розрізані та висушені "інтерпретовані мови повільно, тому що вам потрібно аналізувати код кожен раз, коли ви запускаєте програму" такі речі, які є широко поширеними, але не зовсім точними, оскільки передбачає, що реалізація якось притаманна мові. Це сказало ...

Це дуже схоже на запитання, в чому різниця між людьми, яких ви зустрічаєте в офісі, порівняно з людьми, яких ви зустрічаєте в ресторані: Вони ті самі люди, просто в іншому контексті.

Точно так само "складена мова" - це та, для якої хтось написав компілятор. "Інтерпретована мова" - це та, для якої хтось написав перекладача. Вони можуть бути однією мовою.

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

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

Якщо ви насправді хочете різниці, значить, це так: Інтерпретовані мови, як правило, новіші та мають менше спільноти навколо себе. Чому? Тому що перекладача простіше зібрати, і люди вважають за краще компілятор.

Або, швидше, те, чи користувачі мови працюють із компілятором чи інтерпретатором, є гарним наближенням досяжності / віку мови та наскільки вона статична. Мова, схожа на C ++, ймовірно, матиме компілятор у перший день, оскільки мови, схожі на C ++, є статичними. Мова, яка залишає багато рішень на час виконання, хоча в більшості своїй буде інтерпретуватися довше.

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