Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Sinclair, Вы писали:

S>>Ну если бы они были сделаны как в жаве, то были бы сахаром. Но они сделаны по-нормальному, потому сахаром не являются.
R>Под "они сделаны", так понимаю, вы подразумеваете "в .NET они сделаны" — тогда и надо так говорить, то есть конкретно ".NET Generics", а не обобщением обо всех генериках.

Скорее можно говорить, что в Java генерики какие-то недоделанные, т.к. не захотелось Sun-у ломать совместимость с предыдущими версиями JVM. А, например, в Eiffel генерики вовсе не являются тупыми кастами.

Здравствуйте, nikov, Вы писали:

N>Как тогда объяснить тот факт, что человек, не знающий уравнений Максвелла, может писать сложные SQL-запросы?

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

Это вообще — очень простой вопрос. Очевидно, что мнемонические коды для машинных команд есть не более, чем синтаксический сахар. Тем не менее, в мнемокодах програмировать несравненно легче.

Ты мне другое объясни — хорошо, путь формальное определение понятию "синтаксический сахар" вдруг найдется. Я в это не верю, но могу и ошибиться. Однако какое имеет значение — является ли та или иная конструкция этим самым сахаром или нет? Значение имеет — удобна ли она. Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mrozov, Вы писали:

M>>Здравствуйте, Sinclair, Вы писали:

S>>>Здравствуйте, mrozov, Вы писали:
M>>>>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.
S>>>Могу. Синтаксический сахар — это возможность выразить в компактном виде то, что и так есть в языке.
M>>Иными словами, в языке, который поддерживает ассемблерные вставки, синтаксическим сахаром является весь язык целиком, правильно?
S>Как правило, нет. Редкий язык позволяет делать ассемблерные вставки настолько органичным образом, чтобы можно было выражать на них целые конструкции языка. Попробуй, к примеру, выразить try/catch на ассемблерной вставке.

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

M>>Разве? Это просто сахар для того, чтобы не написать один код несколько раз. Или сахар для того, чтобы не приводить типы.
S>В том-то и дело, что результатом работы генерика является не просто "код, который не надо писать много раз". Чистый синтаксический сахар обычно действует локально, и не затрагивает структуру программы.

Ну вот и получается, что сахар — это несущественное улучшение. Т.е. все сводится к полезности.
Например — c# и ключевое слово var. Многие его характеризуют, как синтаксический сахар. А между тем, оно избавляет от необходимости определять целый дополнительный класс. И где тут отличие от дженериков?

Брось, комрад. За этим термином не скрывается никакой высшей истины. Это просто эмоциональная оценка, как правило — достаточно личная.

Здравствуйте, mrozov, Вы писали:

M>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

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

В качестве примера синтаксического сахара приводится поддержка ООП в C++.

Object-oriented programming
The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style. Moreover, the specialized syntax works to emphasize the object-oriented approach to new programmers. Features of the C# (C Sharp) programming language, such as properties and interfaces, similarly do not enable new functionality but instead make specific programming practices more prominent and more natural.

А вы мне про шаблоны...

И, кстати, чуть ниже дано определение обратного понятия:

Syntactic salt
The metaphor has been extended by coining the term syntactic salt, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what's going on, rather than to express a program action. Some programmers consider required type declarations to be syntactic salt. A requirement to write "end if", "end while", "end do", etc. to terminate the last block controlled by a control construct (as opposed to just "end" or even simpler syntax using braces "}") is widely considered syntactic salt.

Во-во.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, mrozov, Вы писали:

M>>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

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

Категорически не могу согласиться. Были когда-то чемпионаты по написанию программ в одну строчку. Тут не в объеме кода дело, а в выразительной мощности скорее.

E>Т.е. хочешь делать меньше ошибок -- пиши меньше кода. Синтаксический сахар позволяет писать меньше кода.
Но ведь не только сахар позволяет это сделать, верно? Это определение подходит только в том случае, если принять мою максиму о том, что синтаксическим сахаром является все, кроме машинных кодов (и даже некоторые из них). Как ты (вероятно) догадываешься, сам я в нее не верю.

M>В качестве примера синтаксического сахара приводится поддержка ООП в C++.
M>

Object-oriented programming
The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style.

А я не согласен с цитатой. 3 кита ООП — это наследование, полиморфизм и инкапсуляция. Если первые 2 концепции реализуются в С (хоть и с лишней писаниной в случае полиморфизма), то инкапсулящия насколько я понимаю полноценно в C не реализуется. Это именно то что нельзя назвать синтаксическим сахаром — базовая концепция, которую должен поддерживать компилятор.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, mrozov, Вы писали:

ANS>>>Это не доказывает, что "SELECT" всегда и везде является синтаксическим сахаром. Вот возьмём реляционную БД — "SELECT" является синтаксическим сахаром к чему?
M>>К вызову функции с именем Select и списком параметров. См. DLinq.

ANS>Уууу! Откуда в реляционной алгебре Dlinq?

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

В DLinq-е есть возможность описать сложные sql-запросы посредством цепочки вызовов методов. Это доказывает, что SQL не предоставляет никаких принципиально новых возможностей по сравнению с процедурным языком программирования. Он просто сокращает и упрощает запись той же логики. А это, в свою очередь, и является основной частью определения того, что такое "синтаксический сахар". Так понятней?

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

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

Здравствуйте, mrozov, Вы писали:

M>>>Т.е. вопрос в том — что это дает программисту, а не то, как это квалифицируется.

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

M>Категорически не могу согласиться. Были когда-то чемпионаты по написанию программ в одну строчку. Тут не в объеме кода дело, а в выразительной мощности скорее.

Довести до маразма можно все, что угодно.
Но вот исследования по плотности ошибок проводил, кажется, Ericsson. И еще о чем-то похожем говорят ДеМарко и Листер в "Peopleware"

E>>Т.е. хочешь делать меньше ошибок -- пиши меньше кода. Синтаксический сахар позволяет писать меньше кода.

M>Но ведь не только сахар позволяет это сделать, верно?

Верно. Но сахар позволяет это делать.

M>Это определение подходит только в том случае, если принять мою максиму о том, что синтаксическим сахаром является все, кроме машинных кодов (и даже некоторые из них). Как ты (вероятно) догадываешься, сам я в нее не верю.

Тогда к чему это все?

Здравствуйте, Left2, Вы писали:

M>>В качестве примера синтаксического сахара приводится поддержка ООП в C++.
M>>
L>

L>Object-oriented programming
L>The C programming language is fully capable of object-oriented programming using its facilities of function pointers, type casting, and structures. However, languages such as C++ make object-oriented programming more convenient by introducing syntax specific to this coding style.

L>А я не согласен с цитатой. 3 кита ООП — это наследование, полиморфизм и инкапсуляция. Если первые 2 концепции реализуются в С (хоть и с лишней писаниной в случае полиморфизма), то инкапсулящия насколько я понимаю полноценно в C не реализуется. Это именно то что нельзя назвать синтаксическим сахаром — базовая концепция, которую должен поддерживать компилятор.

Там чуть выше, кстати, указано, что большинство конструкций, которые можно было бы назвать сахаром, тем не менее явно поддерживаются компилятором.
Кроме того, поддержать инкапсуляцию можно и иначе — называть методы по паттерну InternalMethodName, например. В конце концов, c# позволяет вызвать закрытый метод через reflection, если очень уж хочется.

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

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

Здравствуйте, eao197, Вы писали:
E>Тогда к чему это все?

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

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

Другие комрады, в свойственной им манере, начали нервно ставить мне минусы и уверять, что они прекрасно понимают, что такое синтаксический сахар и чем он отличается от просто возможностей языка. Но я что-то сомневаюсь. Имею я право посомневаться?

Кроме того, друг Евгений, мне щас абсолютно нефиг делать и настроение у меня откровенно нерабочее. Закончу строчить и начну писать заявление на отпуск. Хочу на море.

Здравствуйте, nikov, Вы писали:

N>Как тогда объяснить тот факт, что человек, не знающий уравнений Максвелла, может писать сложные SQL-запросы?

Видимо сахар с травой.

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

Здравствуйте, mrozov, Вы писали:

M>Другие комрады, в свойственной им манере, начали нервно ставить мне минусы и уверять, что они прекрасно понимают, что такое синтаксический сахар и чем он отличается от просто возможностей языка. Но я что-то сомневаюсь. Имею я право посомневаться?

Безусловно имеешь.
Имхо, оценка "синтаксического сахара" (как и "синтаксического оверхеда") очень субъективна.

M>Кроме того, друг Евгений, мне щас абсолютно нефиг делать и настроение у меня откровенно нерабочее. Закончу строчить и начну писать заявление на отпуск. Хочу на море.

Понимаю тебя. Надеюсь, что заявление тебе подпишут

Здравствуйте, mrozov, Вы писали:

M>>>К вызову функции с именем Select и списком параметров. См. DLinq.

ANS>>Уууу! Откуда в реляционной алгебре Dlinq?

M>В DLinq-е есть возможность описать сложные sql-запросы посредством цепочки вызовов методов. Это доказывает, что SQL не предоставляет никаких принципиально новых возможностей по сравнению с процедурным языком программирования.

DLinq может быть синтаксическим сахаром в C# сколько угодно. Но C# не имеет никакого отношения к SQL.

M>Он просто сокращает и упрощает запись той же логики. А это, в свою очередь, и является основной частью определения того, что такое "синтаксический сахар". Так понятней?

Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Здравствуйте, eao197, Вы писали:

E>Понимаю тебя. Надеюсь, что заявление тебе подпишут

Я еду фоткать рыбок! Ну или еще чего-нибудь придумаю.
Как говаривала одна моя знакомая — ура-ура.

M>Кроме того, поддержать инкапсуляцию можно и иначе — называть методы по паттерну InternalMethodName, например. В конце концов, c# позволяет вызвать закрытый метод через reflection, если очень уж хочется.
называть методы по паттерну InternalMethodName — это перекладывать на программиста работу компилятора. Ну а насчёт вызова через рефлекшн — так и в C++ #define private public никто не отменял. Инкапсуляция спасает от неосознанного (случайного) использования приватных методов, перед хакерской атакой она бессильна.

M>Я эту цитату привел исключительно для того, чтобы продемонстрировать, что этот термин вовсе не является формальным и well-known понятием. То, что для одного — сахар, для другого — важнейшая абстракция.
Все понятия такого рода допускают некую вольность трактовки, тут никто не спорит. Тем не менее эта вольность не обесценивает эти понятия до уровня бесполезных.

Здравствуйте, mrozov, Вы писали:

M>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Еще раз. Есть оператор SQL "SELECT". Через какой оператор SQL можно выразить этот "SELECT"? Если его можно можно выразить через некий SQL-оператор, то "SELECT" это синтаксический сахар в SQL. Всё. При этом некая фича может быть синтаксическим сахаром в одном языке и быть базовым функционалом в другом.

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

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

Здравствуйте, mrozov, Вы писали:

M>Очень хорошо. Правильно ли я понимаю, что в любом языке, поддерживающим ассемблерные вставки, синтаксическим сахаром является весь язык целиком? Если нет — то почему. Спасибо.

Не правильно. Хотя бы потому, что в общем случае в конструкциях языка ничего не говорится об ассемблере. Например, программа на "С" выполняется на абстрактной "С"-машине, а не на конкретной x86 или PPC. А вставка на ассемблере взаимодействует с программой на "С" только случайно Конкретный пример: VW ST. Но это не делает St синтаксическим сахаром к ассемблеру. Кстати, одни и те же конструкции языка могут, в конечном итоге, транслироваться в разные ассемблерные комманды. Расстворимый какой-то сахарок получается.

А вот SQLJ это скорее синтаксический сахар к жабе, потому как он не имеет прямого отношения к SQL и сознательно прикручен поверх жабы

Здравствуйте, mrozov, Вы писали:


M>Может мне кто-нибудь объяснить, что такое "синтаксический сахар"? По-моему, это одно из самых идиотических понятий во всем IT.

Самое идиотическое понятие во всем IT — само понятие IT. А "синтаксический сахар" существовал задолго до IT.