Що робить мову "оптимізованою" для конкретного завдання?

Часто є мови програмування, спеціалізовані для конкретних завдань. Деякі мови програмування є прекрасними в арифметиці масиву (такі як матриці та використання багатовимірних масивів), проте деякі набагато кращі в математиці вищого рівня, яку важко відтворити іншими мовами (все ще можливо все одно).

Що з мовою робить її кращою для конкретної задачі або кінцевої мети, ніж інші мови, враховуючи, що більшість просто збирається до складання?

Я говорю про цілісні мови Тюрінга, ті, які є еквівалентом Тьюрінга.

Є кілька речей, які слід врахувати

• Абстракція: що трактує мова як "особливу"? Чи є матриці значеннями першого класу, як у Matlab, чи кодуєте їх за допомогою більш простих типів, таких як масиви, як у C? C змушує задуматися про те, як реалізовані матриці, Matlab не робить.

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

  Чим більше функцій додано, тим складнішою стає мова. Тож, хоча існують декілька мов "багато парадигми", такі як C ++ та D, більшість мов вибирають нішу, вибирають важливі для цієї ніші речі та надають їм пріоритет як основним абстракціям.

• Продуктивність: вся абстракція постачається з вартістю, будь то час компіляції або час виконання. Деякі мови обмежують себе таким чином, що робить їх менш абстрактними, але ефективнішими.

  Ранній Фортран не допускав покажчиків чи рекурсії, тому він був чудовим при хрускоті чисел, швидше, ніж мова на зразок C, де у вас було багато циклів. Але це було жахливо при кодуванні великих структур даних, як дерева, де вам потрібні вказівники для непрямості. (Зауважте, що я не знаю багато про сучасний Фортран.)

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

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

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

Наприклад, для множення використовуються різні випадки (див. Множення GMP) .

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

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

Коли якесь завдання, яке стосується конкретного домену (тут також орієнтована мова на домен), орієнтується на конкретні розрахунки, вони вдосконалюються та оптимізуються (з роками) для цільової аудиторії. Але бути оптимальним не завжди так. Наприклад, Perl має довгу історію поводження з рядками, але PCRE (тут просто регулярні вирази Perl) - не найшвидші існуючі (і використовують багато пам'яті), але надзвичайно виразні та потужні.

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

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

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

Це відмінне запитання і на нього легко відповісти. Чи є щось про мову Erlang, що робить його придатним для телекомунікаційних програм у режимі реального часу? Або це щось про компілятор Erlang? Або це щось про спільноту та екосистему Ерланг? Можливо, це те, що люди, які вміють писати телекомунікаційні програми, знають Ерланг, а люди, які знають Ерланг, знають у телекомунікаційних програмах? Я підозрюю, що всі ці фактори грають певну роль.

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

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

Наприклад, і C, і C ++ можна використовувати для об'єктно-орієнтованого програмування - і справді, бібліотека GObject є хорошим прикладом OO C. Структура функцій змінного струму, що містить функціональні покажчики, може служити тій самій цілі, що і віртуальні методи класу C ++, і може виконувати краще; покарання за розробку - це клей-код для розподілу пам’яті, ініціалізації функціональних покажчиків та вибору стратегії виклику «батьківських» методів. Більшу частину часу це чіткіше / безпечніше, Class klass * = new class()ніж вводити struct class *klass = malloc(sizeof(struct class));klass->fn1 = ...;klass->fnN = ....