Чи є якийсь механізм зробити мову програмування стабільнішою (сумісною) для змін?

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

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

Мовна стабільність не є технічним рішенням. Це договір між мовним автором та користувачами.

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

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

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

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

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

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

  • Чи можу я представити нового оператора, такого як |> не залишаючи мови? Чи можу я вибрати пріоритетність та асоціативність для цього оператора?
  • Скільки церемонії я повинен пройти для вбудованої функції / лямбда / закриття?
  • Чи можна використовувати існуючий синтаксис мови для реалізації синтаксису циклу foreach? Наприклад, Ruby і Scala можуть це зробити завдяки своєму гнучкому синтаксису виклику методу з лямбдами.

• Розгляньте засоби, щоб зберегти семантику розширюваною. Загальні потреби:

  • Перевантаження оператора, де визначені користувачем типи можуть присвоїти власне значення існуючим операторам. Це робить мову набагато приємнішою для математичних програм.
  • Буквальне перевантаження. Чи можу я зробити так, щоб рядкові літерали були моїми власними типами рядків? Чи можу я зробити, щоб усі числові літери в поточному масштабі були bignums?
  • Протоколи метаоб'єктів. Якщо мова не має ознак, чи можу я їх реалізувати всередині поточної об'єктної системи? Чи можна реалізувати інший порядок вирішення способу? Чи можу я поміняти місцями збереження об'єктів або способами розсилки?
• Зробіть регресійні тести. Багато тесту. Не тільки написані мовними дизайнерами, але й користувачами. Коли додавання функції перериває ці тести, ретельно зважте переваги цієї функції на користь зворотної сумісності.
• Версія своєї мови. Не тільки у вашій документації, а й у самому вихідному коді. Після цього єдиною частиною вашої мови, яка не може змінитися, є синтаксис прагми цієї версії. Приклади: Ракетка дозволяє вказати діалект. Perl дозволяє вам робити це use v5.20, що дозволяє використовувати всі зворотно несумісні функції Perl v5.20. Ви також можете однозначно завантажувати окремі функції use feature 'state'. Подібні: Python'sfrom __future__ import division .
• Подумайте про те, щоб сформувати свою мову таким чином, щоб вона мала кілька зарезервованих слів. Тільки тому, що classвведення класу не означає, що я не міг би мати локальну змінну class. На практиці це призводить до ключових слів, які вводять декларації змінних чи методів, що суперечать C-подібній традиції використання імен типів для введення декларацій. Ще одна альтернатива - використовувати сигіли для своїх $variables, як у Perl та PHP.

Частини цієї відповіді впливають на промову Гая Стіла «Зростання мови» (1998) ( pdf ) ( ютуб ).

Я думаю, що досить важливим кроком є ​​просування менеджера пакунків, який також може керувати версією мови.

Наприклад, я використовую SBT для Scala або Leiningen для Clojure. Обидва вони дозволяють мені заявити, яку версію мови, якою я хочу використовувати, для кожного проекту . Тому досить просто розпочати зелені проекти в останній версії мови, одночасно модернізуючи існуючі проекти більш комфортними темпами.

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