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

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

Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.

Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.

Взять пространства имен, когда можно вместо MyNamespace1_Person записать просто Person с переносом using MyNamespace1 — ну, наверное, чуть удобнее, но так ли уж?

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

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

Шаблоны — можно ли отнести к сильно полезному? Или же заменяется частично кодо-0генерацией?

Что бесспорно переводит на другой уровень — Expression Trees для ORM.

Ваше мнение?

S>Ваше мнение?

Еще Эйнштейн доказал, что E = m * c^2

Errors = more * (code^2)

Чем больше строк кода, тем больше ошибок (в квадрате). Так что если синтаксический сахар позволяет уместить 4 строчки (итерация по списку) в 1 (list comprehension), то и ошибок там будет меньше.

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

SD>Чем больше строк кода, тем больше ошибок (в квадрате).

А что длина строки не важна?

S>А что длина строки не важна?

Обычно она ограничена 120 символами (иногда даже меньше, вплоть до 100, и даже меньше, но то уже для совсем странных языков типа ассемблера).

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

SD>Обычно она ограничена 120 символами
Самим языком длина строки как правило не ограничена. Можно хоть всю прогу в одну строку нахреначить.

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

SD>Обычно она ограничена 120 символами (иногда даже меньше, вплоть до 100, и даже меньше, но то уже для совсем странных языков типа ассемблера).

Ну вы же не в каждой строке используете весь лимит, верно? Будет больше ошибок, если 1 строка с заполнением всех 120 символов или же 10 строк от 1 до 20 символов с общим количеством 120 символов?

CC>Самим языком длина строки как правило не ограничена. Можно хоть всю прогу в одну строку нахреначить.

Я не про язык, а про здравый смысл. Мало кто решится соединить несколько statements в одну строку на любом языке.

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

SD>Я не про язык, а про здравый смысл. Мало кто решится соединить несколько statements в одну строку на любом языке.

Да лехко!

switch (foobar)
{
...
case 100500:    FooBar (foo, bar);    break;
...
}

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

Здравствуйте, 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.

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

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

S>>Ваше мнение?

SD>Еще Эйнштейн доказал, что E = m * c^2

SD>Errors = more * (code^2)

А Исаак Ломоносов сказал, что большинство цитат из Интернета приписано тем, кто их никогда не говорил.

SD>Чем больше строк кода, тем больше ошибок (в квадрате).

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

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

S>Взять пространства имен, когда можно вместо MyNamespace1_Person записать просто Person с переносом using MyNamespace1 — ну, наверное, чуть удобнее, но так ли уж?

С какого-то уровня — так. Потому что замусоривание вида всеми этими префиксами начинает требовать основную часть внимания на реальное соответствие этим префиксам.

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

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

S>Шаблоны — можно ли отнести к сильно полезному? Или же заменяется частично кодо-0генерацией?

То же самое — хорошо, пока не начал плодить ошибки.

S>Ваше мнение?

Ты тролль. Это видно по всем темам.
Но иногда таки есть настроение поговорить и на темы, запущенные троллями.

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

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

У меня есть такое своеобразное определение синтаксического сахара.

Во-первых, я рассматриваю синтаксический сахар не вообще абстрактно, а в сравнении — например, если сравнивать разные языки, или разные версиии языка, и т.п.

И какую-то новую языковую конструкцию я не считаю синтаксическоим сахаром в одном из двух случаев:

1) Если это какая-то принципиально новая фича или парадигма, что раньше вот так сделать было нельзя, а теперь можно (например, та же сборка мусора)

2) Если за счет этой фичи меняется не просто количество строк кода, а улучшается асимптотика количества строк кода в зависимости от количества каких-то программных объектов (переменных, классов, функций, типов и т.п.).
Т.е. если в новой версии вместо 100 строк кода надо писать одну — это синтаксический сахар. А вот если вместо N^2 строк кода надо писать 100 * N строк — это не синтаксический сахар, а значительное улучшение (например, шаблоны).

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

Все, чего нет в Go — оно и не нужно.
Только усложняет язык.

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

SD> Так что если синтаксический сахар позволяет уместить 4 строчки (итерация по списку) в 1 (list comprehension), то и ошибок там будет меньше.

Тогда ускользает ощущение сложности алгоритма. С таким сахаром джун лекго напишет O^6 код и даже этого не заметит.

Моё мнение — чем меньше тривиального кода, тем лучше. И это относится к тому, что реально сокращает время разработки. В принципе всё, что ты перечислил, сокращает объём тривиального кода и сокращает время разработки.

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

На мой взгляд почти идеальный баланс это Java 1.4 (до введения генериков). Я бы туда добавил только properties и некоторые мелкие фичи из поздних версий Java.

Мне не хватает современного языка такого вида.

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

vsb>На мой взгляд почти идеальный баланс это Java 1.4 (до введения генериков). Я бы туда добавил только properties и некоторые мелкие фичи из поздних версий Java.

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

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

А тут образец -- это Java до добавления генериков
Вот как так?

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

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

SD>>Чем больше строк кода, тем больше ошибок (в квадрате).

S>А что длина строки не важна?

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

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

vsb>>На мой взгляд почти идеальный баланс это Java 1.4 (до введения генериков). Я бы туда добавил только properties и некоторые мелкие фичи из поздних версий Java.

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

Обычный код.

S>Да даже в Go, который создавался для совсем уж необучаемых даунов, генерики в итоге завезли (при этом про надобность такой фичи авторам Go говорили все кому не лень чуть ли не с самого начала).

Ну я вот на Go недавно несколько тысяч строк написал. Генерик я использовал там ровно в одном месте:

func formatPtr[T any](v *T) string {
    if v == nil {
        return "nil"
    }
    return fmt.Sprintf("%#v", *v)
}

и то больше ради интереса, посмотреть хоть на эти генерики. Не было бы генериков — написал бы formatStringPtr и formatInt64Ptr. Вместо 6 строк было бы 12. В жаве такого кода вообще не было бы, там указатели ковариантны.

Суть кода — даёт хттп-интерфейс для sqlite-вызовов и для проксирования запросов.

S>А тут образец -- это Java до добавления генериков
S>Вот как так?



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

Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет. И нормально пишут. Тебя это тоже так удивляет? Я считаю, что писать вообще без типов это уже чересчур. Но для меня золотая середина пролегает вот примерно где-то в районе Java 1.4.

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

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

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

S>Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.
S>Что бесспорно переводит на другой уровень — Expression Trees для ORM.
Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.
В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.

S>Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.
Демагогия. Если взять пример

class Order 
{
    decimal Total => lines.Sum(l => l.Price * l.Quantity) * this.Discount
}

и попробовать его написать без свойств, лямбд и Extension Methods, то очень даже влияет.

S>Ваше мнение?
У тебя слишком много свободного времени.

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

vsb>На мой взгляд почти идеальный баланс это Java 1.4 (до введения генериков). Я бы туда добавил только properties и некоторые мелкие фичи из поздних версий Java.

Восьмая Java — это 1.8? Писал как-то на ней, после даже 0x03 плюсиков — полный отстой. Про 1.4 даже думать не хочется, что там