2009-02-13 2 views
11

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

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

+1

Можете ли вы привести примеры или случаи использования? – spoulson

+0

Я никогда не слышал этого мнения. Можете ли вы привести пример того синтаксического сахара, о котором вы говорите? –

+1

На случайной стороне заметки, я только что зарегистрировал SyntaticSugar.com – mmcdole

ответ

8

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

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

Первый 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-го экземпляра i каждый раз. Можно утверждать, что конструкция блокировки более полезна и что какая-то другая конкретная конструкция, на которой было бы заблокирована, была бы лучше, но, конечно, комбинация все еще испорчена.

Несколько переменная декларации и указатели:

long* first, second; 

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

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

i = i + 1; 

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

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

+0

В C оператор ++ изначально был не сахаром, а оптимизацией – 2009-02-13 21:49:54

+6

справедливая точка, сахар C для сборки в любом случае j/k;) – ShuggyCoUk

+0

Взятие блокировки на тип значения не является законным в C# (не знаю Java). Вам нужно было бы сделать что-то вроде этого: lock ((object) i) Но тогда это делает ошибку очевидной, не так ли! –

1

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

1

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

8

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

+5

Вы ненавидите как .NET, так и Java в одном ответе? Браво! ;-) –

+0

В некотором смысле, да. :) – BobbyShaftoe

0

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

+1

Что отличает синтаксический сахар одного языка от другого языка? Вы можете утверждать, что большинство изначально составленных языков - это просто синтаксический сахар поверх сборки. Точно так же ООП можно сделать на С, это просто некрасиво. –

+0

какой-то аспект ООП, я имею в виду –

+0

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

10

Синтаксический сахар вызывает рак точка с запятой. Alan Perlis

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

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

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

С уважением,

+2

Может кто-нибудь объяснить цитату Аланом Опасности? Я никогда этого не понимаю. – day

+0

@day здесь два объяснения: 1. http://softwareengineering.stackexchange.com/questions/194007/what-is-the-difference-between-syntax-and-syntactic-sugar#194020 2. https: // GitHub.com/strint/sicpAns/issues/2 –

2

Смотрите Law of Leaky Abstractions - слишком много сахара, и вы просто использовать его без понимания и зная, что происходит, и это делает его более трудно отлаживать, если что-то делает ошибется.Дело не в том, что «синтаксический сахар» - это плохо, просто многие программисты полагаются на него, не осознавая того, от чего они защищены, а затем, если синтаксический сахар сталкивается с проблемами, они завинчиваются.

1

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

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

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

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

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

1

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

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

2

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

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

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

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

4

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

Примеры:

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

Доза - это то, что важно. '# @ \' (,()) ', вероятно, плохой синтаксис, но я даже не знаю, что означают' # 'и' @', а кроме Common Lisp есть Scheme, который использует разные имена. –

Смежные вопросы