Должны ли языки программирования быть строгими или свободными? [закрыто]

В Python и JavaScript точки с запятой необязательны.

В PHP кавычки вокруг ключей массива являются необязательными ( $_GET[key]против $_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, компилятор не очень хорошо знает, что имела в виду программа). С другой стороны, если бы язык использовался :=для присваивания и ==для сравнения на равенство, а не использовать один= для любой юридической цели, это значительно уменьшит возможности как для случайных назначений, которые должны были быть сравнениями, так и для случайных сравнений, которые не должны были выполняться, которые должны были быть назначениями.

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

  Словарь <complexType1, complexType2> item =
    новый словарь <осложненный тип1, сложный тип2 ()>;

с

  var item = new Dictionary <осложненный тип1, сложный тип2 ()>;

не требует какого-либо сложного вывода типа, но делает код значительно более читабельным (среди прочего, использование более подробного синтаксиса только в сценариях, где это необходимо, например, потому что тип места хранения не точно соответствует типу выражения его создание поможет привлечь дополнительное внимание к местам, где это может потребоваться).

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

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

Для человека, имеющего опыт работы с языком, значение фрагмента кода должно быть ясным без глубокого анализа контекста.

Язык должен иметь возможность отмечать ошибки как можно чаще. Если каждая случайная последовательность символов создает синтаксически правильную программу, это бесполезно. И если переменные создаются автоматически при первом использовании, то неправильное написание clientas cleintне даст вам ошибки компиляции.

Помимо синтаксиса, язык должен иметь четко определенную семантику, и, возможно, это даже сложнее, чем выбор достойного синтаксиса ...

Хорошие примеры:

• В Java "1"это строка, 1int, 1.0double и 1Llong. Один взгляд, и вы знаете, что это такое.

• В Java =это задание. Он присваивает значение для примитивных типов и ссылку для ссылочных типов. Он никогда не копирует сложные данные и не сравнивает их.

• В Java для вызова метода нужны круглые скобки, и этот способ четко отличается от переменных - поэтому, если нет круглых скобок, вам не нужно искать определение метода, это просто чтение данных.

Плохие примеры:

• В Java подобный символ clientможет быть почти любым: элемент пути пакета, имя класса или интерфейса, имя внутреннего класса, имя поля, имя метода, локальная переменная и даже больше. Пользователь должен вводить или соблюдать соглашения об именах или нет.

• В Java точка .чрезмерно используется. Это может быть разделитель в имени пакета, разделитель между пакетом и классом, разделитель между внешним и внутренним классом, соединитель между выражением экземпляра и методом, который будет вызван в экземпляре, и многое другое.

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

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

Вы могли бы рассмотреть аналогию с естественным языком. По электронной почте вы грамматик нацист? Или вы в порядке с некоторыми грамматическими ошибками, такими как разделенные инфинитивы, пропущенные соединения или неуместные модификаторы. Ответ сводится к личным предпочтениям.