Почему синтаксический сахар иногда считается плохой вещью? [закрытый]

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

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

12
language-design syntactic-sugar

11 ответов

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

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

первый-C# (или 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 это не имеет значения, оценка происходит вне любых других оценок, но используется в другом месте это может быть источником путаницы (так как вы можете встраивать очень важный аспект расчет (следует ли использовать текущее или следующее значение) в очень маленькую и легко пропущенную форму.

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

9

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

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

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

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

с уважением,

10

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

8

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

примеры:

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

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

2

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

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

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

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

2

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

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

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

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

2

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

1

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

1

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

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

1

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

0