Почему Синтаксический сахар иногда считается плохим?

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

Изменить: я не хотел называть имена, но, поскольку люди спрашивали, похоже, большинство программистов на С++ и Java, например, откровенно не заботятся о том, что на их языке отсутствует синтаксический сахар. Во многих случаях это не обязательно то, что они просто похожи на другие части языка, достаточные для того, чтобы недостаток сахара стоил компромисса, так что они действительно не заботятся. Кроме того, программисты Lisp, похоже, почти гордятся своим странным обозначением языка (я не буду называть его синтаксисом, потому что это технически не так), хотя в этом случае он более понятен, потому что он позволяет Lisp средствам метапрограммирования быть такими же мощными как они есть.

ОТВЕТЫ

Ответ 1

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

некоторые конкретные примеры:

Первый - это С# (или java) специфический, автоматический бокс и блокировка/синхронизированная конструкция

private int i;
private object o = new object();

private void SomethingNeedingLocking(bool b)
{
    object lk = b ? i : o;
    lock (lk) { /* do something */ }
}

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

Объявление нескольких переменных и указателей:

long* first, second;

Классическая ошибка (хотя легко заметить). Сахар из нескольких переменных не будет соответствовать объявлению указателя.

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

i = i + 1;

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

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

Ответ 2

Синтаксический сахар вызывает рак точки с запятой. Алан Перлис

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

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

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

Привет,

Ответ 3

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

Ответ 4

Глупости. C и Lisp программисты используют синтаксический сахар все время.

Примеры:

  • a[i] вместо *(a+i)
  • '(1 2 3) вместо (quote 1 2 3)

Ответ 5

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

Ответ 6

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

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

Например, LINQ является синтаксическим сахаром, потому что он не добавляет новых возможностей к С# 3, которые еще не были возможны в С# 2. Но сделать то же самое, что и простое выражение LINQ в С# 2, потребовало бы гораздо большего количества кода для выполнения и было бы гораздо труднее прочитать.

Иными словами, дженерики не являются синтаксическим сахаром, потому что вы можете делать с ними что-то на С# 2, которые были невозможны с С# 1, например создание класса коллекции, который может содержать любой тип значения без бокса.

Ответ 7

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

Ответ 8

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

Ответ 9

Лично я всегда считал термин "синтаксический сахар" неоднозначным. Я имею в виду, если вы хотите получить техническую информацию, просто о чем-либо, кроме основной арифметики, инструкции if, а goto - синтаксический сахар.

Я думаю, что большинство людей имеет в виду, когда они отвергают "синтаксический сахар", так это то, что языковая функция делает что-то сложное слишком просто. Самым известным примером этого является Perl. Но поскольку я не эксперт Perl, я приведу вам пример того, что я говорю в python (взято из этого вопроса):

reduce(list.__add__, map(lambda x: list(x), [mi.image_set.all() for mi in list_of_menuitems]))

Это очевидная попытка сделать что-то более ужасное, ужасно неправильное.

Это не значит, что я на стороне удаления таких функций. Я считаю, что такие функции нужно тщательно использовать.

Ответ 10

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

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

Ответ 11

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