Чи повинні мови програмування бути суворими чи вільними? [зачинено]

У Python та JavaScript напівколонки необов’язкові.

У PHP цитати навколо ключів масиву необов’язкові ( $_GET[key]vs $_GET['key']), хоча якщо ви їх опустіть, то спочатку шукайте константу за цим іменем. Він також дозволяє 2 різних стилів для блоків (двокрапку або дужку з обмеженою точкою).

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

Що ти думаєш?

Гаразд, моя мова є не стільки мовою програмування, скільки фантазійною мовою шаблонів. Вигляд хреста між шаблонами Haml і Django . Мається на увазі, що він використовується в моєму веб-рамках C # і повинен бути дуже розширеним.

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

Наприклад, Perl - це дуже вільна мова, і я вважаю це дуже корисним для написання сценаріїв швидкого виправлення чи скорочення чисел. Для надійних надійних проектів я використовую C #.

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

Те, що я шукаю в мові програмування (на відміну від мови сценаріїв), - це послідовність і сильне введення тексту.

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

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

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

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

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

У своєму прикладі ви згадали, що крапки з комою необов’язкові в Python та JavaScript. Принаймні, для Javascript це не зовсім вірно. Крапки з комою так само вимагаються в JS, як і в будь-якій іншій мові сімейства C. Але JavaScript-аналізатор вимагає мовної специфікації, щоб вставити пропущені крапки з комою за певних обставин. Це широко вважається дуже поганою справою оскільки воно має намір помилитися з вашими намірами та накрутити свій код.

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

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

Мої особисті переваги полягають у здатності мати достатньо суворості, щоб ловити мої помилки, але з якомога меншою кількістю зайвих плит. Я говорю про це питання в http://www.perlmonks.org/?node_id=755790 .

Це сказало, що ви самі розробляєте свою мову. Ви повинні зробити його таким, яким ви хочете.

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

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

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

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

Удачі.

Я б припустив, що в хорошій мові програмування повинні бути чіткі правила, які реалізації, як очікується, слідкуватиме послідовно, але правила повинні бути написані таким чином, щоб бути корисними. Я б також запропонував розглянути можливість створення мови, щоб уникнути випадків, коли "відстань Хеммінга" між двома суттєво різними програмами є лише однією. Очевидно, що цього не можна досягти за допомогою числових чи рядкових літералів (якщо програміст, який мав на увазі 123, замість цього типу 1223 або 13, компілятор не може дуже добре знати, що означає програма). З іншого боку, якби мова мала використовуватись :=для призначення та ==для порівняння рівності, а не використовувати одну= з будь-якою юридичною метою, це значно зменшило б можливості як для випадкових доручень, які повинні були бути порівняннями, так і випадкових порівнянь, що не роблять нічого, що мали бути завданнями.

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

  Словник <складнийТип1, складнийТип2> елемент =
    новий словник <ускладненийType1, ускладненийType2 ()>;

з

  var item = новий словник <ускладненийType1, ускладненийType2 ()>;

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

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

Для мене читабельність є найважливішою.

Для того, хто має досвід роботи з мовою, значення фрагмента коду повинно бути зрозумілим без необхідності глибокого аналізу контексту.

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

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

Хороші приклади:

• У Java "1"- це рядок, 1є int, 1.0є подвійним і 1Lє довгим. Один погляд, і ти знаєш, що це таке.

• У Java =- це призначення. Він призначає значення для примітивних типів і посилання для референтних типів. Він ніколи не копіює складні дані та не порівнює.

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

Погані приклади:

• У Java подібний символ clientможе бути майже будь-яким: елементом контуру пакета, іменем класу чи інтерфейсу, іменем внутрішнього класу, іменем поля, назвою методу, локальною змінною тощо. Користувач повинен вводити чи дотримуватися умов іменування чи не виконувати їх.

• У Java крапка .використовується надмірно. Це може бути роздільник в межах імені пакета, роздільник між пакетом і класом, роздільник між зовнішнім і внутрішнім класом, з'єднувач між виразом екземпляра та методом, який слід викликати в екземплярі, та багато іншого.

• У багатьох мовах фігурні дужки ifблоків необов’язкові, що призводить до неприємних помилок, якщо хтось додає ще один (не дійсно існуючий) блок.

• Оператори інфікування: іноді мені доводиться зупинятися на числовому виразі і подумати, що це означає, крок за кроком. Всі ми звикли писати математичні вирази в інфіксації, як a * b / c * d + e. Більшу частину часу ми пам’ятаємо перевагу множення та ділення над додаванням і відніманням (але чи ти зрозумів, що ми не ділимось c*d, а ділимо лише на, cа потім множимо на d?). Але є так багато додаткових операторів інфіксації з власними правилами пріоритетності та перевантаженням на деяких мовах, що важко відстежувати. Можливо, застосування кращих дужок було кращим підходом ...

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