Сообщение Re: Синтаксический сахар vs реально полезные вещи в ЯП от 31.01.2023 10:12
Изменено 31.01.2023 10:55 gandjustas
Re: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Shmj, Вы писали:
S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.
S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.
Все что уменьшает количество кода для решения задачи влияет положительно, несмотря на твое отношение к этим изменениям.
S>Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.
S>Что бесспорно переводит на другой уровень — Expression Trees для ORM.
Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.
В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.
S>Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.
Демагогия. Если взять пример
и попробовать его написать без свойств, лямбд и Extension Methods, то очень даже влияет.
S>Ваше мнение?
У тебя слойком много свободного времени.
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>Ваше мнение?
У тебя слойком много свободного времени.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, Shmj, Вы писали:
S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.
S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.
Все что уменьшает количество кода для решения задачи влияет положительно, несмотря на твое отношение к этим изменениям.
S>Вот если взять свойства. Вроде удобно. Но по сути ни на что не влияет — написать две функции — не сложнее.
S>Что бесспорно переводит на другой уровень — Expression Trees для ORM.
Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.
В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.
S>Или взять возможность писать вместо save(Person* p) — p.Save() — удобно, но не особо на что влияет.
Демагогия. Если взять пример
и попробовать его написать без свойств, лямбд и Extension Methods, то очень даже влияет.
S>Ваше мнение?
У тебя слишком много свободного времени.
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>Ваше мнение?
У тебя слишком много свободного времени.