Я розумію відмінності між інтерпретованими та компільованими мовами, але якщо хтось міг би навести кілька прикладів ситуацій, коли можна скористатись інтерпретованими мовами над компільованими мовами, а також ситуацій, коли, ймовірно, використовуються компільовані мови над інтерпретованими мовами, бути дуже корисним.
Відповіді:
Існує (наскільки мені відомо) не існує такого поняття, як інтерпретована "мова" чи складена "мова".
Мови визначають синтаксис та значення ключових слів коду, конструкцій потоку та інших інших речей, але я не знаю жодної мови, яка б визначала, чи потрібно її складати чи інтерпретувати у мовній специфікації.
Тепер, якщо у вас виникає питання, коли ви використовуєте компілятор мови проти інтерпретатора мови, він дійсно зводиться до професіоналів / конвеєрів компілятора порівняно з інтерпретатором та метою проекту.
Наприклад, ви можете використовувати компілятор JRuby для легшої інтеграції з бібліотеками java замість інтерпретатора рубіну MRI. Ймовірно, є також причини використовувати інтерпретатор рубіну MRI через JRuby, я не знайомий з мовою, хоча і не можу з цим говорити.
Розрекламовані переваги перекладачів:
Розрекламовані переваги компіляторів:
Однак я б став би в 90% випадків, що це щось подібне: я хочу написати це програмне забезпечення в blub, оскільки я добре його знаю, і воно повинно зробити гарну роботу. Я буду використовувати інтерпретатор blub (або компілятор), оскільки це загальноприйнятий канонічний метод для написання програмного забезпечення в blub.
Отже, TL; DR - це порівняно для кожного конкретного випадку порівняння інтерпретаторів та компіляторів для конкретного випадку використання.
Також FFI: Інтерфейс іноземних функцій, іншими словами інтерфейс для взаємодії з іншими мовами. Більше читання на wikipedia
Тут важливим моментом є те, що багато мовних реалізацій насправді роблять якийсь гібрид обох. Сьогодні багато часто використовуваних мов працюють, складаючи програму в проміжний формат, такий як байт-код, а потім виконуючи це в інтерпретаторі. Ось як зазвичай реалізуються Java, C #, Python, Ruby та Lua. Фактично, це, мабуть, те, як реалізована більшість використовуваних сьогодні мов. Отже, справа в тому, що мова сьогодні і інтерпретує, і складає їх код. Деякі з цих мов мають додатковий компілятор JIT для перетворення байт-коду в нативний код для виконання.
На мою думку, ми повинні припинити говорити про інтерпретовані та складені мови, оскільки вони вже не є корисними категоріями для розрізнення складності мовних реалізацій сьогодні.
Коли ви питаєте про достоїнства інтерпретованих та складених мов, ви, мабуть, маєте на увазі щось інше. Ви можете запитати про достоїнство статичного / динамічного набору тексту, достоїнства розповсюдження власних виконуваних файлів, відносні переваги компіляції JIT та AOT. Це всі питання, які стикаються з інтерпретацією / складанням, але це різні питання.
Перш за все, мова програмування може бути інертно і компільована. Інтерпретація та компіляція - це лише методи генерації виконуваного коду з вихідного коду. За допомогою інтерпретатора вихідний код читається та інтерпретується інтерпретатором, який потім виконує код під час його інтерпретації. З іншого боку, компілятор зчитує вихідний код і генерує виконуваний двійковий файл із вихідного коду - так що програма може запускатися як окремий процес незалежно.
Тепер, перш ніж хтось задається питанням ... Так, C / C ++ / C # / Java можна інтерпретувати, і так, сценарії JavaScript та Bash можуть бути складені. Чи є перекладачі чи компілятори для цих мов - інше питання.
Тепер фактично відповісти на питання, коли ми будемо використовувати "інтерпретовану мову" над "складеною мовою". Питання саме по собі дещо заплутане, але я припускаю, що це означає, коли віддавати перевагу інтерпретації над компіляцією. Одним із мінусів компіляції є те, що він генерує деяку накладну витрату завдяки процесу компіляції - вихідний код повинен бути зібраний до виконуваного машинного коду, тому він не підходить для завдань, які вимагають мінімальної затримки при виклику вихідного коду для виконання програми. З іншого боку, компільований вихідний код майже завжди швидший, ніж еквівалентний інтерпретований вихідний код через накладні витрати, спричинені інтерпретацією коду. Інтерпретатори з іншого боку можуть викликати і запускати вихідний код з дуже маленькими викликами накладних витрат, але за рахунок виконання робочого часу.
Зрештою, майже неможливо згадати будь-які певні випадки використання, коли слід віддати перевагу один за одним, але, наприклад, один (на мій підкреслення дуже нереальний) випадок, коли вихідний код програми динамічно змінюється між викликами програми і надмірні витрати на компіляцію занадто високий, щоб він був життєздатним вибором. У цьому випадку, мабуть, було б бажано інтерпретувати вихідний код замість компіляції.
Однак є щось, що можна вважати прикладом у реальному світі: вихідний код hidnig після розгортання. З ріднимСкомпільований код розробник розгортає виконуваний макін-код програми та даних. З інтерпретованим кодом повинен бути розгорнутий сам вихідний код, який потім може бути перевірений та реінжинірований з набагато меншими зусиллями, ніж те, що стосується реверсивного коду машинного коду. Єдиним винятком цього є такі мови, як C # і Java, які компілюються до прямої мови / байт-коду (MSIL для C # та Java-байт-код для Java), який потім розгортається і компілюється "вчасно" під час виконання, як і інтерпретатор. Однак існують так звані декомпілятори для MSIL та Java Bytecode, які можуть реконструювати оригінальний вихідний код з відносно хорошою точністю, і як така реверсивна інженерія таких продуктів набагато більш тривіальна, ніж продукти реверсивної інженерії, які розгорнуті в рідному машинному коді.
Я можу придумати такі сценарії, коли ви використовуєте інтерпретовану мову:
Я можу придумати такі сценарії, коли ви хочете скласти свій код:
Зрештою, великий компроміс полягає між продуктивністю (скільки рядків коду потрібно написати) та продуктивністю (наскільки швидко буде виконуватися ваша програма).
Оскільки інтерпретовані мови при перетворенні на інформацію про процесор мають більше інформації, вони можуть розраховувати на рефлексію та динамічне введення, що значно підвищує продуктивність . Ще одна перевага інтерпретованих мов полягає в тому, що вони є незалежними від платформи, тому для платформи існує перекладач.
Оскільки центральний процесор не повинен перетворювати код мови в машинний код і одночасно запускати код, як і в інтерпретованому випадку, компільовані мови дають більш швидкі програми. Крім того, система, побудована на компільованій мові, більш безпечна, оскільки вона може виявляти проблеми під час компіляції, що в основному означає, що ви бачите помилку під час її введення (із сучасними IDE), а не бачите її лише тоді, коли ви фактично запускаєте програму (звичайно, , це не виправляє логічних помилок).
Знаючи це, інтерпретовані мови підходять для:
І компільовані мови підходять, коли:
Окрім причин, які згадували інші, є один особливо важливий випадок використання для вибору спеціальної інтерпретації будь-якої форми складання чи будь-якого гібридного підходу.
У випадку, якщо мова програмування використовується як протокол зв’язку , і коли важлива затримка відповіді, є більш доцільним уникати витрачання часу на компіляцію та будь-яку можливу попередню обробку.
Це стосується, наприклад, мов агентів, або способу, як, скажімо, Tcl / Tk зазвичай використовується.
Іншою можливою причиною дотримування інтерпретації є те, що інтерпретатор мови використовується для завантаження самого себе або більш досконалої мови вищого рівня, а її простота важливіша за ефективність процесу завантаження.
Для майже будь-якого іншого можливого випадку використання компіляція (або гібридний підхід) найкраще підходить.