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

S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.

S>Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.
S>Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.
S>Возможность наследования без необходимости вручную присваивать новые версии ссылок на функции — вроде чуть удобнее, но тоже не особо на что влияет.
S>Взять пространства имен, когда можно вместо MyNamespace1_Person записать просто Person с переносом using MyNamespace1 — ну, наверное, чуть удобнее, но так ли уж?
Никакой "сути" нет. Есть выражение намерений разработчика. Каждый отдельный кусочек "сахара" вроде бы мало на что влияет, но в сумме они складываются в существенно другой язык.
Ведь order.Total += item.Quantity*item.Price не только пишется, но и читается гораздо легче и быстрее, чем

acme_erp_orderManagement_setOrderTotal(order, 
    acme_finance_currency_add(acme_erp_orderManagement_getOrderTotal(order),
        acme_finance_currency_multiply(acme_erp_orderManagement_getItemQuantity(item), 
             cme_erp_orderManagement_getItemPrice(item)));

S>Шаблоны — можно ли отнести к сильно полезному? Или же заменяется частично кодо-0генерацией?
Всё заменяется кодо-генерацией. Собственно, вы всегда можете напилить свой DSL на основе LISP и порождать на его основе код на целевом языке, который потом будете обрабатывать компилятором. См. тж. cfront.

Резюме: любой язык программирования — синтаксический сахар. Либо над аналогом машины Тьюринга (для императивных языков), либо над аналогом функций Чёрча (для функциональных).
Пытаться разделить "суть" и "синтаксический сахар" — бессмысленно.

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

S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.

S>Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.
S>Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.
S>Возможность наследования без необходимости вручную присваивать новые версии ссылок на функции — вроде чуть удобнее, но тоже не особо на что влияет.
S>Взять пространства имен, когда можно вместо MyNamespace1_Person записать просто Person с переносом using MyNamespace1 — ну, наверное, чуть удобнее, но так ли уж?
Никакой "сути" нет. Есть выражение намерений разработчика. Каждый отдельный кусочек "сахара" вроде бы мало на что влияет, но в сумме они складываются в существенно другой язык.
Ведь order.Total += item.Quantity*item.Price не только пишется, но и читается гораздо легче и быстрее, чем

acme_erp_orderManagement_setOrderTotal(order, 
    acme_finance_currency_add(acme_erp_orderManagement_getOrderTotal(order),
        acme_finance_currency_multiply(acme_erp_orderManagement_getItemQuantity(item), 
             acme_erp_orderManagement_getItemPrice(item)));

S>Шаблоны — можно ли отнести к сильно полезному? Или же заменяется частично кодо-0генерацией?
Всё заменяется кодо-генерацией. Собственно, вы всегда можете напилить свой DSL на основе LISP и порождать на его основе код на целевом языке, который потом будете обрабатывать компилятором. См. тж. cfront.

Резюме: любой язык программирования — синтаксический сахар. Либо над аналогом машины Тьюринга (для императивных языков), либо над аналогом функций Чёрча (для функциональных).
Пытаться разделить "суть" и "синтаксический сахар" — бессмысленно.