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


14

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

В PHP кавычки вокруг ключей массива являются необязательными ( $_GET[key]против $_GET['key']), хотя, если вы их опустите, сначала будет искать константу с этим именем. Это также позволяет использовать 2 разных стиля для блоков (двоеточие или скобки).

Сейчас я создаю язык программирования и пытаюсь решить, насколько строгим он должен быть. Есть много случаев, когда дополнительные символы на самом деле не нужны и могут быть однозначно истолкованы из-за приоритетов, но мне интересно, стоит ли мне их применять или нет, чтобы поддерживать последовательность.

Как вы думаете?


Хорошо, мой язык не столько язык программирования, сколько причудливый язык шаблонов. Этакая помесь шаблонов Haml и Django . Предназначен для использования с моим веб-фреймворком C # и должен быть очень расширяемым.


22
Это тема для священной войны.

1
Pythonistas не рекомендуют использовать точки с запятой. Честно говоря, я не уверен, нужны ли они вообще - только для разрешения нескольких утверждений в строке, чего можно полностью избежать без страданий. Итак ... Я за более строгие языки. Тем не менее, иногда вы можете применять вещи вне языка с помощью инструментов анализа кода, таких как StyleCop.
Работа

1
Кавычки для ключей массива PHP не являются обязательными. Они были в PHP2, но более поздние версии автоматически определяли константы тогда. Однако они не допускаются при базовой интерполяции строк "..$_GET[raw]..".
Марио

1
@Ralph: правила немного сложнее. Правильно написать "xx$_GET[raw]xx"- Если вы начинаете использовать фигурные скобки, то ключ должен быть заключен "xx{$_GET['raw']}xx"в кавычки. Если используются фигурные скобки, то обычный синтаксический анализатор PHP проверяет это и применяет строгий синтаксис. Просто для "$_GET[x]"этого ключ обрабатывается как необработанная строка, и это также строгое правило, в котором PHP будет анализировать ошибку "$_GET['x']".
Марио

2
@mario: Сам факт, что у нас даже есть этот разговор, означает, что в обработке ключей массива есть некоторая неопределенность и путаница. Кажется, что внутри строк, это однозначно, но противоречиво (вы не можете использовать кавычки, когда уже в строке, если вы не используете фигурные скобки, тогда вы должны, но снаружи вы должны). И за пределами строк, в "нормальном" PHP ... ну, это делает странную чушь, как это.
mpen

Ответы:


19

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

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

Вы должны получить баланс правильно для целевого использования. Чем строже он, тем дольше вам нужно тратить на написание кода, но вы получаете большую надежность, возможность повторного использования и простоту обслуживания.


26

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

В современных языках программирования можно опустить точку с запятой, например, в определенных местах, не становясь двусмысленным (последнее выражение в {}блоке - одно). Если язык программирования позволяет вам пропустить символы в этих случаях, у программиста появилась дополнительная проблема; Помимо общего синтаксиса языка теперь она должна знать, в каких случаях разрешено также пропускать части синтаксиса.

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

Ваш пример PHP открывает возможность для незначительных ошибок в программе, когда константа keyбудет добавлена ​​в том же контексте. Компилятор не может знать, что это не то, что имелось в виду, поэтому проблема становится очевидной только во время выполнения, а не во время компиляции.


1
Согласитесь, вы должны ограничить возможности для разработчиков: больше возможностей => нужно больше думать (я должен поступить так или иначе) => меньше времени для реальной работы
Kemoda

Я не вижу, что отсутствие неявного приведения типов связано с синтаксисом языка.
dan_waterworth

5
Кроме того, когда вы читаете, $_GET[key]вы ничего не знаете. Вы заканчиваете тем, что искали весь проект, просто чтобы знать, keyявляется ли он константой или нет. Такая вещь экономит 0,5 секунды записи и занимает 20 секунд на чтение.
Моше Рева

Если ваш язык дает вам варианты без различия, стиль кодирования - будь то кодифицированный или нет - имеет тенденцию стандартизировать на одном из них ...
Deduplicator

11

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

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

Из вашего примера вы упомянули, что точки с запятой необязательны в Python и JavaScript. По крайней мере, для Javascript это не совсем так. Точки с запятой так же необходимы в JS, как и на любом другом языке семейства C. Но синтаксический анализатор JavaScript требуется в спецификации языка для вставки пропущенных точек с запятой при определенных обстоятельствах. Это широко расценивается как очень плохая вещь, потому что это имеет тенденцию ошибаться в ваших намерениях и испортить ваш код.


6

Ответ на вопрос, насколько свободно вы должны говорить, равен ответу на вопрос, сказанный в техасском акценте: «Как тебе повезло, панк?».


Я не понимаю
mpen

4
Моя неудачная попытка пошутить, что динамическая типизация может укусить вас, когда системы становятся все больше и больше, особенно при добавлении в смесь неопытных разработчиков. По моему опыту, системы любой ценности имеют тенденцию расти все больше и больше, и число их разработчиков постоянно растет. Наличие «Найти все варианты использования символа», «Переименовать все», «Безопасное удаление» или «Найти ошибки в решении» является абсолютно бесценным. Динамическая типизация в ограниченном смысле, что VB имеет позднюю привязку и делает обширное приведение типов, вызвало много ошибок на текущем концерте.
Хенрик

Ergo, если вам повезло с вашим проектом, например, с хорошими и опытными разработчиками или с точки зрения написания правильного кода; Вы можете использовать динамическую типизацию.
Хенрик

2
Ах ... но этот вопрос никогда не
касался

1
Ах, очень верно, Рапл. Я просто склонен думать о динамических языках как более свободных, так как они обычно более свободные. Вы правы, хотя.
Хенрик

4

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


+1: полностью согласен Я не понимаю, почему такие принципы, как KISS и YAGNI, не должны применяться к языковому дизайну.
Джорджио

2

Мое личное предпочтение заключается в том, чтобы обладать достаточной строгостью, чтобы поймать мои опечатки, но с как можно меньшим количеством дополнительного шаблона. Я говорю об этой проблеме на http://www.perlmonks.org/?node_id=755790 .

Тем не менее, вы разрабатываете свой язык для себя. Вы должны сделать так, как хотите.


+1: ... Способность обладать достаточной строгостью, чтобы поймать мои опечатки, но с минимальным дополнительным шаблоном, насколько это возможно. - Да. Вам знаком план Андерса Хейлсберга по C #? Он принимает сознательное решение, чтобы подчеркнуть "сущность, а не церемонию". channel9.msdn.com/Blogs/matthijs/…
Джим Г.

@ Джим-г: Спасибо за мысль. Я не знаком со многим из всего о C #. Я не работал в мире Microsoft много, много лет.
btilly

1

Мне нравится, когда мои языки делают то, что я имею в виду. Как правило, это довольно сильно склоняется к свободе. Я также хотел бы иметь возможность пометить «строгий» на элементе или блоке, чтобы иметь возможность отладки / анализа этой ограниченной области.


1

Я, как правило, склоняюсь к тому, чтобы сказать «Что облегчит мне как программисту». Конечно, это может означать больше чем одно. В Javascript практически нет проверки типов, которая прекрасно работает, пока вы не наткнетесь на странную ошибку. С другой стороны, в Haskell есть много проверок типов, которые откладывают большую часть работы вперед, но забивают некоторые классы ошибок.

Если честно, я бы проверил несколько языков, чтобы посмотреть, что они делают, и попытался бы найти нишу, которую ни один из них не нашел!

Я не думаю, что есть один очевидный правильный способ сделать это, или, по крайней мере, если это не то, о чем люди еще не нашли консенсуса. Таким образом, создавая языки с разными системами типов, мы учимся.

Удачи.


1

Я хотел бы предложить, чтобы у хорошего языка программирования были строгие правила, которые, как ожидается, должны внедряться последовательно, но правила должны быть написаны таким образом, чтобы быть полезными. Кроме того, я бы предложил подумать о разработке языка, чтобы избежать случаев, когда «расстояние Хэмминга» между двумя существенно разными программами равно одному. Очевидно, что этого не добиться с помощью числовых или строковых литералов (если программист, который имел в виду 123 вместо 1223 или 13, компилятор не очень хорошо знает, что имела в виду программа). С другой стороны, если бы язык использовался :=для присваивания и ==для сравнения на равенство, а не использовать один= для любой юридической цели, это значительно уменьшит возможности как для случайных назначений, которые должны были быть сравнениями, так и для случайных сравнений, которые не должны были выполняться, которые должны были быть назначениями.

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

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

с

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

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

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


1

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

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

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

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

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

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

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

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

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

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

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

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

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


Вы в основном говорили о неоднозначности, но может быть несколько способов сделать одно и то же без создания двусмысленности. Может быть, мы можем иметь два оператора умножения, *и ×. Оба 5*3и 5 × 3` означают одно и то же, и опытный программист точно знает, что они имеют в виду, не оглядываясь на окружающий контекст. Проблема, однако, в том, что теперь есть два способа сделать одно и то же, и кто-то может переключаться между ними по всей программе. Я считаю, что это то, что меня больше беспокоило, когда я задавал вопрос.
mpen

-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.