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

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

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

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

Моє головне питання не має нічого спільного з Рустом та його власністю конкретно - але сміливо використовуйте його як приклад у своїх коментарях / відповідях, якщо вам потрібно.

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

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

• Це процес проб і помилок, в тому сенсі, що ви придумали просту форму функції, потім спробуйте знайти способи її порушення, потім виправити, якщо ви успішно її порушите, а потім повторіть? І тоді, коли ви не можете придумати будь-які інші можливі порушення, ви сподіваєтесь, що нічого не залишилося, і називати це день?

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

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

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

Haskell має проміжне представлення, яке по суті є обчислення лямбда, доповнене кількома простими речами, щоб полегшити роботу. Обчислення лямбда використовується і перевірено, оскільки комп'ютер був просто людиною, яка обчислювала речі. Цікавим моментом, який Саймон Пейтон Джонс зазначає часто, є те, що коли вони щось роблять з дикою та шаленою мовою, він знає, що це принципово добре, коли він зрештою зводиться до цієї проміжної мови.

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

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

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

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

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

Перше і найскладніше, про що дизайнер мови повинен подбати, впроваджуючи нові функції, - це підтримувати свою мову послідовно:

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

Для керівництва в цьому питанні дизайнер спирається на набір правил та принципів дизайну. Цей підхід дуже добре описаний у " Дизайні та еволюції C ++ " від Bjarne Stroustrup , одній з рідкісних книг, присвячених мовному дизайну. Що дуже цікаво, це бачити, що мови рідко розробляються у вакуумі, і дизайнер виглядає також, як їхні мови реалізували подібні функції. Ще одне джерело (онлайн та безкоштовно) - принципи дизайну мови java .

Якщо ви подивитесь на публічні розслідування комітетів із стандартизації, то побачите, що це більше процес помилки проб. Ось приклад модуля C ++ - цілком нова концепція, яка буде представлена ​​в наступній версії мови. І тут розроблений аналіз після деяких мовних змін , щоб оцінити його успішність. І тут Процес спільноти Java для визначення нових специфікацій Java, наприклад, нового api . Ви побачите, що цю роботу виконують кілька експертів, які творчо складають концептуальний документ та першу пропозицію. Потім ці пропозиції переглядаються більшою громадою / комітетом, який може вносити зміни до пропозиції, щоб забезпечити більш високий ступінь узгодженості.

Як перевірити особливості мови програмування? Це дуже гарне запитання, і я не впевнений, що сучасний стан підходить до роботи.

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

Навіть дуже розумні дизайнери мови, які наполегливо працюють над підтримкою звукості типу, виявляють такі порушення, як ця помилка Іржа . Система типу Руста для мене не настільки очевидна, але я думаю, що в цьому випадку наявність типової вартості системи відстеження типу означає, що все життя "підтипування" (підпунктів) стикається з очікуванням на звичайне підтипування, примуси, посилання та змінність, створюючи лазівку, де staticвсе життя ref може вказувати на значення, виділене стеком, а пізніше стає звисаючим посиланням.

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

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

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

Прикладна стаття на цю тему: « Програмісти - це люди, занадто , мова програмування та дизайнери API можуть багато чого навчитися у галузі дизайну людських факторів».

Приклад запитання SE на цю тему: Чи перевірена синтаксис будь-якої мови програмування?

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

Такі мови, як Smalltalk, Python та Dart, були розроблені з акцентом на зручність використання. Ясно, що Хаскелл не був.