Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.01.23 06:45
Оценка: +6
Здравствуйте, 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.

Резюме: любой язык программирования — синтаксический сахар. Либо над аналогом машины Тьюринга (для императивных языков), либо над аналогом функций Чёрча (для функциональных).
Пытаться разделить "суть" и "синтаксический сахар" — бессмысленно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отредактировано 01.02.2023 7:01 Sinclair . Предыдущая версия .
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 31.01.23 00:44
Оценка: 3 (1) +2 -1 :)
S>Ваше мнение?

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

Errors = more * (code^2)

Чем больше строк кода, тем больше ошибок (в квадрате). Так что если синтаксический сахар позволяет уместить 4 строчки (итерация по списку) в 1 (list comprehension), то и ошибок там будет меньше.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: LaptevVV Россия  
Дата: 31.01.23 07:23
Оценка: -1 :))) :)
Все, чего нет в Go — оно и не нужно.
Только усложняет язык.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.01.23 10:12
Оценка: +5
Здравствуйте, 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>Ваше мнение?

У тебя слишком много свободного времени.
Отредактировано 31.01.2023 10:55 gandjustas . Предыдущая версия .
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 31.01.23 06:51
Оценка: +4
Здравствуйте, SkyDance, Вы писали:

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


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


SD>Errors = more * (code^2)


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

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


Ссылку на исследования — в студию.
Причём так, чтобы универсально подходило ко всем языкам, и чтобы там был именно квадрат.
The God is real, unless declared integer.
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Doom100500 Израиль  
Дата: 31.01.23 08:16
Оценка: +2 -1
Здравствуйте, SkyDance, Вы писали:

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


Тогда ускользает ощущение сложности алгоритма. С таким сахаром джун лекго напишет O^6 код и даже этого не заметит.
Спасибо за внимание
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 31.01.23 09:55
Оценка: +3
Здравствуйте, vsb, Вы писали:

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


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

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

А тут образец -- это Java до добавления генериков
Вот как так?
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: AntoxaM  
Дата: 31.01.23 16:58
Оценка: +3
Здравствуйте, vsb, Вы писали:


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

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

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

Гм, вместо системы типов, которая при компиляции всё проверит, писать решение на строках, которое упадёт только в рантайме. Странный выбор.

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

Люди конечно пишут, но как-то не всем нравится без типов. Неспроста появились TS и аннотации типов в Питоне, в которых(surprise) есть генерики.
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 08:46
Оценка: +3
Здравствуйте, vsb, Вы писали:

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


G>>1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.


vsb>В Go это решается встроенными структурами данных и утверждением, что свои структуры данных нужны достаточно редко, чтобы это не было проблемой.

Ага, а спустя 5 лет таки добавили генерики. Что поменялось? Стали структуры часто нужны? Или изначальные утвреждения были ошибочными.

vsb>Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

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

G>>2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.


vsb>Функциональное программирование переоценено.

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

vsb>В го его нет и нормально.

Это точно

vsb>Десятки лет писали без него и проблем не знали.

Десятки лет писали на С++\Java\C# и проблем не знали. Зачем же go?

vsb>По-мне половина функционального кода в той же жаве читается хуже, чем версии на циклах и условиях. Да, есть случаи, когда функциональный подход прям прекрасно ложится на алгоритм, а императивный подход многословен. Но это не то, что помешает писать хорошие программы.

Количество кода это не субъективная величина. Если одну и ту же задачу можно решить на языке А в 50 строк, а на языке Б в 20, то всегда стоит выбирать Б, независимо от того кому какой язык нравится.



vsb>В общем обе эти проблемы решаются концепцией магических типов.

То есть нормальные библиотеки могут создать авторы языка. Такой язык становится малополезным.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 03.02.23 07:51
Оценка: 1 (1) +1
Здравствуйте, Sharov, Вы писали:

НС>>Такое ощущение, что ты не читаешь что тебе отвечают. Еще раз — свойство это часть системы типов.

S>Я это уже понял, что дальше, как это помогает в генерации sql, например?

Для генерации, например, в системе типов необходима явная связь между геттером и сеттером.

НС>>Я выделил жирным в цитате, что ты не заметил при первом прочтении. Дело не в писанине.

S>Я это видел. А почему это так важно

Почему важен дополнительный контроль со стороны компилятора? Ты правда не знаешь ответа?

S>Для меня они сахар


First class citizen в системе типов не может быть сахаром по определению. Сахар это то, что может быть выражено другими средствами языка. Свойства, очевидно, не могут, это уникальная сущность, по другому не выражаемая.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 31.01.23 11:14
Оценка: -2
Здравствуйте, vsb, Вы писали:

vsb>Я про типы в коде.


Я тоже.

Типы есть и никуда не деваются.

В отличии от программирования на ассемблере или на C/C++ когда все прячется за void*.

S>>Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.


vsb>Это всё теория.


Ну ничёсе, пардон май френч. Это самая что ни есть практика.

vsb>На практике без типов у тебя каждая опечатка вылезает только в рантайме.


В динамически типизированном ЯП -- да, вылезет. К счастью.
В чистой сишечке ничего не вылезет, разве что программа быстро упадет, если повезет.

vsb>А значит тебе надо тестировать каждую строку кода, чтобы быть хоть сколько-то в нём уверенным.


Ну вот в динамически-типизированных языках такую цену приходится платить за обобщенный код.

Когда же обобщенное программирование не поддерживается от слова совсем, то и объем исходного кода раздувается, и тестировать все это все равно приходится.

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


У вас какая-то шизофреничность в желаниях. То Java до генериков идеал, то Go с генериками.
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 31.01.23 16:24
Оценка: +2
CC>case 100500: FooBar (foo, bar); break;

Это по сути один statement. Метка ("case") это атрибут, а break — вообще пережиток обратной совместимости с "языком для goto".

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


Само собой. Речь не о том, что нужно все "однострочные методы" убрать, или потребовать форматировать всю программу в одну строку.

А о простой статистике — чем больше буковок кода (при прочих равных), тем больше багов в этом коде. Собственно, языки высокого уровня для того и нужны, чтобы уменьшить количество этих самых буковок, а значит, ускорить чтение и написание кода, заодно снизив и количество багов. Посему называть "синтаксический сахар" бесполезным — ошибка. Это очень важный компонент языка программирования. Порой, пожалуй, даже более важный, чем остальное. А то ведь С — это "синтаксический сахар" поверх ассемблера.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 01.02.23 08:11
Оценка: +1 :)
Здравствуйте, CreatorCray, Вы писали:

SD>>а break — вообще пережиток обратной совместимости с "языком для goto".

CC>Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.

А это неважно. Главное что семантически это один элемент и писать несколько стейтментов заставляет уродство языка. И то что ты написал одной строкой тому доказательство.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 10:02
Оценка: -2
Здравствуйте, so5team, Вы писали:

G>>>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?


vsb>>Какие? Я таких не знаю.


S>Ada, Eiffel, Rust, D.


Про первые два ничего не знаю, вторые два — низкоуровневые.

Высокоуровневые это, например, JS, Python. И там постоянно пакеты ставишь и оно что-то сишное компилировать начинает.

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

S>Полагаю, что сюда же можно отнести и Haskell с разными OCaml-ями. Но тут я не копенгаген.


Не знаю, что там с окамлями, но хаскель — адский тормоз. Думаю, его спасает только то, что на нём никто не пишет.
Отредактировано 03.02.2023 10:04 vsb . Предыдущая версия . Еще …
Отредактировано 03.02.2023 10:03 vsb . Предыдущая версия .
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 03.02.23 20:19
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

S>>возможным. Блин, это же сахар, в конце концов.

G>"не верю, докажите мне" не очень разумная позиция.

У него другой не бывает.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.23 20:33
Оценка: -1 :)
Здравствуйте, netch80, Вы писали:

S>>> Если их в языке нет нет понятия потока?

R>>Вы не найдете в стандарте языка Си понятие потока.

N>"Да что ж вы такое несёте то". ([rollcoin@])

N>Рекомендую просветиться.

Мне кажется, вы говорите об одном и том же. В самом яп нет ничего про потоки, но есть в стандартной библиотеке. Все таки яп и его библиотека это разные вещи.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: fk0 Россия https://fk0.name
Дата: 05.02.23 12:55
Оценка: :))
Здравствуйте, Shmj, Вы писали:

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

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

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


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


Для умных указателей нужно RAII, которое тоже будет вручную.

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


В C# не шаблоны, а кривая паделка студентов. Шаблоны в C++.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: Maniacal Россия  
Дата: 31.01.23 10:42
Оценка: 1 (1)
Здравствуйте, Shmj, Вы писали:

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


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


auto в C++ облегчает написание, но, порой, снижает читаемость кода.
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.02.23 20:32
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:


S>На уровне clr нету никаких св-в, там есть соотв. методы.

В метаданных свойства есть

S>Так и будет компилироватсья в sql.

Пока неясно


S>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.

в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?

Bind в обе стороны работает.

Собственно наличие метаданных свойств и позволяет делать всякие привязки и мэппинги. А синтаксис свойств не позволяет написать пару методов на которых мэппинги не сработают. Так что это чуть больше, чем просто синтаксический сахар
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 02.02.23 05:33
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

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

S>>Вот как так?

S>Попробую додумать за vsb


Я, к сожалению, так и не понял, что не так к генериками по мнению vsb.

S>правда, оговрюсь, что на яве я не писал.


Так разговор же к Java не был привязан.

Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.

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

Подозреваю, что позицию vsb следует понимать как-то так.
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 06:52
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

G>>2) Как потом оно будет компилироваться в SQL ?

S>На уровне clr нету никаких св-в

В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует. Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 08:38
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

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


S>Но что это меняет? Все равно будут вызываться методы. Т.е. пропертя это своего рода синтаксический сахар,

S>довольно удачный. Но почему без них невозможно в sql не понятно?
Ну предложите вариант как сделать произвольную проекцию типизированной (проверяемой при компиляции) без свойств.

S>У меня будут вместо св-в генерироваться, допустим ORM, соотв. методы типа get_X. Дергать их.

S>Т.е. там, где исп. св-ва, что мешает исп. сгенерированные методы?
А как их потом перевести в sql?


S>>>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.

G>>в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
G>>Bind в обе стороны работает.
S>Да, упустил. Ну опять же, кто-то это дело будет интерпритировать и у соотв. объекты вызывать соотв. методы get\set.
И снова вопрос типизации и проверки при компиляции.


G>>Собственно наличие метаданных свойств и позволяет делать всякие привязки и мэппинги. А синтаксис свойств не позволяет написать пару методов на которых мэппинги не сработают. Так что это чуть больше, чем просто синтаксический сахар


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

S>способо избавить программиста от лишнего кода или от сгенерированного кода. Т.е. св-ва -- это просто
S>упрощение, а не концептуальная возможность. В конце концов, как в яве то без св-в живут и сущ. ORM
S>типа NHibernate?
NHibernate это для .NET, а в Java просто Hibernate и в произвольные типизированные проекции он не умеет. И предикаты тоже.
Кстати в NHibernate вроде как прикрутили Linq


S>Т.е. я согласен, что св-ва многое упрощают и т.д. Я не пониманию, почему св-ва делют что-то концептуально

S>возможным. Блин, это же сахар, в конце концов.
"не верю, докажите мне" не очень разумная позиция.
Re[11]: Eiffel
От: so5team https://stiffstream.com
Дата: 04.02.23 05:48
Оценка: 1 (1)
Здравствуйте, Sharov, Вы писали:

S>>Ada, Eiffel, Rust, D.


S>Ну кто его кроме Мейера и в исследовательских целях использует?


Как я понимаю, его продолжают использовать крупные компании, которые выбрали Eiffel еще в 1980-х и 1990-х (насколько помню, это транспорт, энергетика, европейская военка).
Тут же еще примечательно, что Eiffel разрабатывается небольшой фирмой EiffelSoftware, которая с этого продукта и живет (продажи EiffelStudio, консалтинг, обучение). Если бы Eiffel не использовался, то они бы не выжили бы, а так все еще существуют и выдают, минимум, по одному большому релизу EiffelStudio в год.
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 04.02.23 05:53
Оценка: 1 (1)
Здравствуйте, gandjustas, Вы писали:

G>Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны.


За последние 40. Ada -- это 1983-й год. И это стал, пожалуй, первый широко применявшийся язык со статической типизацией и поддержкой обобщенного программирования. Шаблоны в C++ через 7 лет появились под сильным влиянием Ada.

И это я еще не знаю историю развития функциональных языков. Не удивлюсь, если в какой-нибудь Miranda обобщенное программирование уже было в 1980-х.
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Shmj Ниоткуда  
Дата: 31.01.23 00:54
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

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


А что длина строки не важна?
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: CreatorCray  
Дата: 31.01.23 01:17
Оценка: :)
Здравствуйте, SkyDance, Вы писали:

SD>Обычно она ограничена 120 символами

Самим языком длина строки как правило не ограничена. Можно хоть всю прогу в одну строку нахреначить.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Shmj Ниоткуда  
Дата: 31.01.23 02:17
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

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


Ну вы же не в каждой строке используете весь лимит, верно? Будет больше ошибок, если 1 строка с заполнением всех 120 символов или же 10 строк от 1 до 20 символов с общим количеством 120 символов?
Отредактировано 31.01.2023 2:18 Shmj . Предыдущая версия .
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: CreatorCray  
Дата: 31.01.23 03:55
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

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


Да лехко!

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




Так что само утверждение уже неверно.
Лепить кучу всякого в одну строку никто не будет, но таки даже однострочные функции/методы имеют место быть и крайне полезны с точки зрения читабельности.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 31.01.23 07:01
Оценка: +1
Здравствуйте, Shmj, Вы писали:

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


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

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


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

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


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

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


Ты тролль. Это видно по всем темам.
Но иногда таки есть настроение поговорить и на темы, запущенные троллями.
The God is real, unless declared integer.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 31.01.23 09:35
Оценка: +1
Моё мнение — чем меньше тривиального кода, тем лучше. И это относится к тому, что реально сокращает время разработки. В принципе всё, что ты перечислил, сокращает объём тривиального кода и сокращает время разработки.

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

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

Мне не хватает современного языка такого вида.
Отредактировано 31.01.2023 9:43 vsb . Предыдущая версия .
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.01.23 10:00
Оценка: +1
Здравствуйте, Shmj, Вы писали:

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


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


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


Очевидно речь идет не про длину строки символов, а про количество операторов языка при одинаковой функциональности.
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.01.23 16:01
Оценка: +1
Здравствуйте, vsb, Вы писали:

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


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

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

В целом генерики облегчают жизнь. А вот код с рефлексией придется покрывать тестами, иначе можно ждать много самых разных артефактов, вплоть до того, что изобретем динамическую типизацию на ровном месте
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: LaptevVV Россия  
Дата: 01.02.23 05:35
Оценка: :)
LVV>>Все, чего нет в Go — оно и не нужно.
LVV>>Только усложняет язык.
_>Все, чего нет в Обероне — оно и не нужно.
_>Только усложняет язык.
Совершенно верно. В книжке Донована и Кернигана прям так и нарисовано: Go — прямой наследник Оберона.
А синтаксис взят из С.
И там еще есть ветка совсем экспериментальных языков (3 штуки), в основе которых CSP Хоара.
_>Все, чего нет в С++ — оно все нужно.
_>Очередность включения определяют члены комитета и другие уважаемые люди.
И с этим соглашусь.
Математические константы, которые Борланд в библиотеку занесла 25 лет назад, только-только появились...
И модули.
От этого я вообще фигею — конструкция ж хорошо проработана со времен Модулы-2.
Или он там книжек не читают?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 01.02.23 08:21
Оценка: +1
Здравствуйте, Doom100500, Вы писали:

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


Джун так может сделать с любым подходом, потому что обычные функции даже в самом синтаксически бедном ЯВУ тоже никто не отменял.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rudzuk  
Дата: 01.02.23 08:41
Оценка: -1
Здравствуйте, LaptevVV, Вы писали:

LVV> Все, чего нет в Go — оно и не нужно.

LVV> Только усложняет язык.

Язык без исключений не нужен. Fixed.
avalon/3.0.2
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 02.02.23 13:27
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.


В Go это решается встроенными структурами данных и утверждением, что свои структуры данных нужны достаточно редко, чтобы это не было проблемой.

Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

G>2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.


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

В общем обе эти проблемы решаются концепцией магических типов. Когда некоторые типы из стандартной библиотеки — коллекции, ну пусть даже какие-то функциональные типы, если так хочется — работают магическим образом и их невозможно повторить своим кодом. А какие-то кастомные коллекции и алгоритмы в 99% случаев не нужны. В тех 0.9% случаев, когда они нужны, они нужны исходя из алгоритмических соображений. Лишние переходы по указателям O-сложность хуже не сделают. И только в тех редчайших случаях, когда тебе нужен высший уровень производительности, язык не справится. Тогда надо просто спуститься на уровень ниже.
Отредактировано 02.02.2023 13:28 vsb . Предыдущая версия .
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 14:41
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>А методы свойств по умолчанию инлайнятся.


Простые методы без всяких свойств тоже инлайнятся.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 15:28
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

НС>>Простые методы без всяких свойств тоже инлайнятся.

S>В последних да,

Не в последних тоже.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 16:06
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>>Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает,

S>>а не делает концептуально возможным.
S>Ну прежде всего это Reflection и обработка кода через Roslyn или прочие парсеры и модификаторы кода.
S> Вот например атрибуты это сахар?

Хороший вопрос -- с одной стороны так проще что-то манефистировать для clr или рефлексии, с др. стороны
это можно сделать определенными методами/св-ми и т.п., но тогда надо вводить какие-то договоренности. Атрибуты
от этого освобождают.
Кодом людям нужно помогать!
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 03.02.23 09:52
Оценка: +1
Здравствуйте, vsb, Вы писали:

G>>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?


vsb>Какие? Я таких не знаю.


Ada, Eiffel, Rust, D.

Полагаю, что сюда же можно отнести и Haskell с разными OCaml-ями. Но тут я не копенгаген.
Отредактировано 03.02.2023 10:00 so5team . Предыдущая версия .
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 03.02.23 10:10
Оценка: +1
Здравствуйте, vsb, Вы писали:

G>>>>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?


vsb>>>Какие? Я таких не знаю.


S>>Ada, Eiffel, Rust, D.


vsb>Про первые два ничего не знаю


Тем не менее, это универсальные языки высокого уровня.

vsb>вторые два — низкоуровневые.


По поводу Rust-а еще можно было бы поспорить, но назвать низкоуровневым D -- это сильно, внушаить.

vsb>Высокоуровневые это, например, JS, Python. И там постоянно пакеты ставишь и оно что-то сишное компилировать начинает.


Сишное там не из-за высокоуровневости, а из-за динамической природы этих языков, за что и приходится платить накладными расходами в run-time.

vsb>Не знаю, что там с окамлями, но хаскель — адский тормоз. Думаю, его спасает только то, что на нём никто не пишет.


Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 03.02.23 10:54
Оценка: -1
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Я это уже понял, что дальше, как это помогает в генерации sql, например?

НС>Для генерации, например, в системе типов необходима явная связь между геттером и сеттером.

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

НС>>>Я выделил жирным в цитате, что ты не заметил при первом прочтении. Дело не в писанине.

S>>Я это видел. А почему это так важно
НС>Почему важен дополнительный контроль со стороны компилятора? Ты правда не знаешь ответа?

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

S>>Для меня они сахар

НС>First class citizen в системе типов не может быть сахаром по определению. Сахар это то, что может быть выражено другими средствами языка. Свойства, очевидно, не могут, это уникальная сущность, по другому не выражаемая.

Не просто другими, а существенно меньшим кол-ом кода. Св-ва многое упрощают, но не делают что-то концептуально возможным.
Пример -- ява. С ними однозначно лучше чем без них, спору нет.
Кодом людям нужно помогать!
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 12:51
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

vsb>>>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.

S>>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
S>>> Если их в языке нет нет понятия потока?
S>>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/

vsb>>Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.


S>Угу, а как блокировать доступ к переменным?


не должно быть никакого доступа к переменным.

S> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?


Сообщениями. Вон тут в теме разработчик sobjectizer-а, думаю, расскажет, почему акторы лучше общих переменных.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 21:58
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

G>>То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?


SD>Рассказы — это уже специфика группировок. Есть поддержка и первого варианта ("генерики не нужны"), и второго ("нужны"). Оба мнения имеют право на жизнь, есть обоснования и для того, и для другого.

Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны. И ФП тоже нужно.


G>>Это, конечно, очень повышает доверие к разработчикам языка

SD>А это вообще могут быть люди, не входящие ни в одну из перечисленых выше группировок
SD>Любой "design by committee" противоречив по определению.
Честно, не понимаю.
Сначала комитет постановил что "генерики не нужны", потом постановил что нужны.
Что изменилось за это время?
Синтаксический сахар vs реально полезные вещи в ЯП
От: Shmj Ниоткуда  
Дата: 30.01.23 22:21
Оценка:
Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

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

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

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

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

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

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

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

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

Ваше мнение?
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 31.01.23 01:00
Оценка:
S>А что длина строки не важна?

Обычно она ограничена 120 символами (иногда даже меньше, вплоть до 100, и даже меньше, но то уже для совсем странных языков типа ассемблера).
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 31.01.23 03:14
Оценка:
CC>Самим языком длина строки как правило не ограничена. Можно хоть всю прогу в одну строку нахреначить.

Я не про язык, а про здравый смысл. Мало кто решится соединить несколько statements в одну строку на любом языке.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: klopodav  
Дата: 31.01.23 07:08
Оценка:
S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

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


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

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

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

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

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

И да, в соответствии с этим определением — с практической точки зрения синтаксический сахар это далеко не всегда плохо, он бывает и очень полезным. Вреден только излишний синтаксический сахар, чересчур загромождающий и усложняющий язык.
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 31.01.23 10:00
Оценка:
Здравствуйте, 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.
Отредактировано 31.01.2023 10:08 vsb . Предыдущая версия . Еще …
Отредактировано 31.01.2023 10:05 vsb . Предыдущая версия .
Отредактировано 31.01.2023 10:03 vsb . Предыдущая версия .
Отредактировано 31.01.2023 10:01 vsb . Предыдущая версия .
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: пффф  
Дата: 31.01.23 10:17
Оценка:
Здравствуйте, vsb, Вы писали:

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


Восьмая Java — это 1.8? Писал как-то на ней, после даже 0x03 плюсиков — полный отстой. Про 1.4 даже думать не хочется, что там
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 31.01.23 10:22
Оценка:
Здравствуйте, пффф, Вы писали:

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


П>Восьмая Java — это 1.8?


Вроде 1.5 ребренднули в 5 и дальше уже начали называть без "1.". Так что — да.

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


Ну если вкратце — то 5 это генерики, 6 и 7 какие-то проходные, по языку там изменений почти не было, 8 это уже куча изменений, самое главное это лямбда и функциональная библиотека потоков для коллекций (streams).
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 31.01.23 10:24
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет.


Там типы есть.

Только типизация динамическая, а не статическая.

vsb>И нормально пишут. Тебя это тоже так удивляет?


Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 31.01.23 10:32
Оценка:
Здравствуйте, so5team, Вы писали:

vsb>>Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет.


S>Там типы есть.


S>Только типизация динамическая, а не статическая.


Я про типы в коде.

vsb>>И нормально пишут. Тебя это тоже так удивляет?


S>Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.


Это всё теория. На практике без типов у тебя каждая опечатка вылезает только в рантайме. А значит тебе надо тестировать каждую строку кода, чтобы быть хоть сколько-то в нём уверенным. Если есть статическая типизация, то компилятор даёт частичную уверенность. Если нет генериков, значит все структуры данных используют базовый тип вроде Object. То бишь нужно кастовать и неправильно указанный тип вылезет только в рантайме. Но тут всё же ошибиться куда сложней, тут нужно ошибиться не просто в одной букве, а в названии целого типа (или неправильно понять, что передаётся).

Вероятно у го в этом плане подход идеальный. Он даёт обобщённый интерфейс для базовых структур вроде массива, отображения и всё. В итоге 99% клиентского кода работают как будто в языке есть генерики. При этом это никак не повышает сложность системы типов и интуитивно понятно для программиста. В общем если говорить про идеальный язык, наверное конкретно эту бы фичу я тоже из го взял. Не давать генерики программисту в руки, но дать их стандартной библиотеке.
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 31.01.23 10:55
Оценка:
Здравствуйте, netch80, Вы писали:

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

"Никогда не доверяйте цитатам из интернета" (с) Ленин

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

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

Квадрат это конечно перебор, но плотность (количество на строку кода) ошибок растет при увеличении объема после определенного порога.
Исследование раз (язык ADA) https://www.cs.colostate.edu/~cs530/modsize.pdf — плотность ошибок модуля после объема в 250 строк начинает расти.
Исследование два (опенсорс Java) — https://www.researchgate.net/publication/221635599_A_Study_on_Defect_Density_of_Open_Source_Software — растет незначительно при росте размера ПО.

Поэтому при прочих равных писать меньше — всегда лучше.
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 31.01.23 16:31
Оценка:
G>Квадрат это конечно перебор, но плотность (количество на строку кода) ошибок растет при увеличении объема после определенного порога.

Квадрат, это, конечно, шутка (для соответствия формуле).
Спасибо за ссылки. Есть и другие исследования. Не смог сходу найти, но то, где в Ericsson переписали код AXD301, и получили в 4 раза меньше строчек при очень высоком uptime и низких ошибках.
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 31.01.23 16:47
Оценка:
Здравствуйте, Shmj, Вы писали:

Ну вот замыкания,Linq, yield, async await, ПМ, Span это тоже сахар. Но удобный. Экономит кучу времени.
Те же деревья выражений
и солнце б утром не вставало, когда бы не было меня
Отредактировано 31.01.2023 18:42 Serginio1 . Предыдущая версия . Еще …
Отредактировано 31.01.2023 16:49 Serginio1 . Предыдущая версия .
Отредактировано 31.01.2023 16:48 Serginio1 . Предыдущая версия .
Re: Синтаксический сахар vs реально полезные вещи в ЯП
От: vaa  
Дата: 01.02.23 04:20
Оценка:
Здравствуйте, Shmj, Вы писали:

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


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


Людям обычно плевать на чужое мнение, они просто ждут своей очереди высказаться (ц)



Рич Хикки довольно глубокий анализ дал на эту тему. В общем случае да чем проще тем лучше, но вопрос что есть просто не простой.
Св-ва шарпа это необходимость работы с binding winforms, потом уже его дальше потащили.

Объективно одна вещь (ЯП) может быть проще другой. Но субъективно чем лучше ты знаешь конкретный ЯП тем лучше код. Пожалуй это очевидно.

В фарпе например не стали сыпать сахар, а придумали движок CE,
теперь у них даже код разметки выглядит почти как родной
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: CreatorCray  
Дата: 01.02.23 04:39
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>а break — вообще пережиток обратной совместимости с "языком для goto".

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

SD>А о простой статистике — чем больше буковок кода (при прочих равных), тем больше багов в этом коде.

Тем не менее refactor rename всех имён на более длинные багов не добавит.

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

Ну вон perl преуспел в уменьшении колва буковок, но это только добавило ему зубодробительной нечитабельности.

SD> Посему называть "синтаксический сахар" бесполезным — ошибка.

А вот это как раз верно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: pagid_ Россия  
Дата: 01.02.23 05:29
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Все, чего нет в Go — оно и не нужно.

LVV>Только усложняет язык.

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

Все, чего нет в С++ — оно все нужно.
Очередность включения определяют члены комитета и другие уважаемые люди.
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vaa  
Дата: 01.02.23 07:15
Оценка:
Здравствуйте, pagid_, Вы писали:

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


LVV>>Все, чего нет в Go — оно и не нужно.

LVV>>Только усложняет язык.

_>Все, чего нет в Обероне — оно и не нужно.

_>Только усложняет язык.

А в обероне есть как в модуле-2 многопоточка (стр 127)?
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: pagid_ Россия  
Дата: 01.02.23 08:42
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Совершенно верно. В книжке Донована и Кернигана прям так и нарисовано: Go — прямой наследник Оберона.

Вот только почему-то Обероном иначе как учебным языком никто не пользуется, а Go несмотря на то, что с некоторых сторон выглядит уродинкой, язык вполне практичный

LVV>А синтаксис взят из С.

Это в java и C# синтаксис взят из С, а в Go какая-то страшненькая мешанина.
Тем не менее Go можно с пользой юзать. почему? Если не углубляться, а чисто идейно, потому как его создатели не изображали из себя мессий несущих в мир единственно правильное, в отличие от Вирта и последователей.

LVV>И модули.

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

LVV>От этого я вообще фигею — конструкция ж хорошо проработана со времен Модулы-2.

Потому как в Паскале, честно не претендующем ни на что кроме чисто учебного языка компиляция из нескольких файлов исходников предусмотрена не была предусмотрена.
Ну и Вирт и последователи не заботились о совместимости. Потому как ничего полезного на их языках у чего есть будущее и для чего может быть нужна совместимость, написано все равно не было. Нужно что-то добавить или переделать, по необходимости или из собственного каприза — легко и быстро запилим новый язык. С Си/С++ такое не прокатит.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 01.02.23 15:12
Оценка:
CC>Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.

Легальное, да (потому что обратная совместимость), часто используемое — отнюдь. Такое использование вообще не особо одобряется, в силу особенностей чтения этих макарошек из goto

CC>Тем не менее refactor rename всех имён на более длинные багов не добавит.


Так и строк не добавит.

CC>Ну вон perl преуспел в уменьшении колва буковок, но это только добавило ему зубодробительной нечитабельности.


У Perl проблемы были не (только) с этим.
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 01.02.23 16:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.

G>В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.

А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от
тех же set_,get_ в яве, сгенеренных ORM?
Кодом людям нужно помогать!
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 01.02.23 16:58
Оценка:
Здравствуйте, so5team, Вы писали:

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

S>Когда про ненужность обобщенного программирования говорят старые системные программисты или хардкорные embeddede-разработчики, которые вынуждены ужимать все в 32KiB, то их понять еще можно. Но вот за пределами этой специфической ниши...
S>Да даже в Go, который создавался для совсем уж необучаемых даунов, генерики в итоге завезли (при этом про надобность такой фичи авторам Go говорили все кому не лень чуть ли не с самого начала).
S>А тут образец -- это Java до добавления генериков
S>Вот как так?

Попробую додумать за vsb, правда, оговрюсь, что на яве я не писал. Так вот, у них дженерики были крайне плохо
реализованы через type erasure (1ая ссылка гугля). Т.е. компилятор
чего-то там генерил, удалял и т.п. run-time про дженерики ничего не знал. Т.е. вроде бы есть, а вроде бы лучше
чтобы и не было. Наверное, это имелось в виду. А по уму они сделаны с C# 2.0, например, когда run-time отменно знал
про такое расширение типов и компилятору не надо было приседать.
Кодом людям нужно помогать!
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.02.23 17:54
Оценка:
Здравствуйте, Sharov, Вы писали:

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


G>>Тебе не кажется что это взаимоисключающие утвреждения? Мэппинг в ORM, байндинг в UI — все делается на основе свойств.

G>>В теории любой мэппинг можно и на основе пары функций сделать, автоматически подставляя префиксы get_\set_, как в Java, но тогда теряется проверка типов при компиляции.

S>А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от

S>тех же set_,get_ в яве, сгенеренных ORM?

Пример номер раз:
var query = from x in db.Table
            select new Projection {
                X1 = x.Y1,
                X2 = x.Y2,
                X3 = x.Y3 - x.Y1,
            }


1) Это это можно переписать без свойств?
2) Как потом оно будет компилироваться в SQL ?


var query = from x in db.Table
            select new Projection {
                X1 = x.Y1,
                X2 = x.Y2,
                X3 = x.Y3 - x.Y1,
            }


Пример номер два (Blazor)
@page "/bind"

<p>
    <input @bind="InputValue" />
</p>

@code {

    private string? InputValue { get; set; }
}

Как сделать проверку типа привязки во время набора кода, если вместо свойства у нас пара функций?
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 01.02.23 19:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>А почему проверка типов отвалится, чем св-ва, и сгенеренные компилятором соотв. методы (C#) отличаются от

S>>тех же set_,get_ в яве, сгенеренных ORM?
G>Пример номер раз:
G>
G>var query = from x in db.Table
G>            select new Projection {
G>                X1 = x.Y1,
G>                X2 = x.Y2,
G>                X3 = x.Y3 - x.Y1,
G>            }
G>

G>1) Это это можно переписать без свойств?

foreach(var x in db.Table)
{
 var prj = new Projection();
 prj.set_Y1(x.Y1);
 ....  
}



G>2) Как потом оно будет компилироваться в SQL ?


На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.


G>Пример номер два (Blazor)

G>
G>@page "/bind"

G><p>
G>    <input @bind="InputValue" />
G></p>

G>@code {

G>    private string? InputValue { get; set; }
G>}
G>

G>Как сделать проверку типа привязки во время набора кода, если вместо свойства у нас пара функций?

Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.
в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
Кодом людям нужно помогать!
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.02.23 07:17
Оценка:
Здравствуйте, so5team, Вы писали:

S>Могу лишь предположить, что по мнению vsb генерики/шаблоны гораздо в большей степени нужны разработчикам библиотек. Ну, типа, написать обобщенный map или zip без генериков/шаблонов не получится. Придется как в древних версиях Java или Object Pascal оперировать базовым Object-ом, в котором должны быть соответствующие виртуальные методы, либо же в реализации придется вручную делать касты от Object-а к каким специализированным интерфейсам. Так что разработчикам библиотек средства для нормального обобщенного программирования очень нужны.


S>Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.


Это популярное мнение из Го. Но есть аспекты, о которых часто умалчивают.
1) Быстродействие и потребление памяти. Предположим мы создаем необобщенную структуру данных. Тогда каждый элемент у нас — ссылка на объект. Этот объект должен размещаться в куче, под него надо выделить память, он должен быть обработан сборщиком мусора. Даже если размер объекта сопоставим с размером указателя, хранимым в структуре. Генерики позволяют создавать структуры где объекты (структуры) хранятся по месту и не требуют дополнительных аллокаций.
2) Без генериков невозможно функциональное программирование, так как большинство комбинаторов — функций, выполняющих небольшую часть работы, которые можно последовательно применять к результатам вызовов других комбинаторов — невозможно описать без обобщённых типов и лямбда-функций. Без ФП код прикладной программы становится более многословным и повторяющимся. Это касается даже простого кода, который перекладывает JSON туда-сюда.
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 02.02.23 07:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это популярное мнение из Го. Но есть аспекты, о которых часто умалчивают.


Я описал лишь то, как я лично воспринял позицию vsb.
Это не значит, что сам я разделяю подобные взгляды.
Отредактировано 02.02.2023 7:56 so5team . Предыдущая версия .
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Философ Ад http://vk.com/id10256428
Дата: 02.02.23 08:35
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Все, чего нет в Go — оно и не нужно.

LVV>Только усложняет язык.

в Go какой версии?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: Синтаксический сахар vs реально полезные вещи в ЯП
От: LaptevVV Россия  
Дата: 02.02.23 08:55
Оценка:
Ф>в Go какой версии?
До появления шаблонов...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 08:57
Оценка:
Здравствуйте, Sharov, Вы писали:


S>На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.


Угу а как же вызов свойства через рефлекшн?
public static object GetPropValue(object src, string propName)
 {
     return src.GetType().GetProperty(propName).GetValue(src, null);
 }


Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn
Для SourceGenerator
https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

Ну и инлайнинг методов свойства.

Свойства оочень удобны. Особенно после Явы.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 02.02.2023 9:00 Serginio1 . Предыдущая версия .
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 11:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>На уровне clr нету никаких св-в, там есть соотв. методы.

G>В метаданных свойства есть

Да, про это я не знал. Т.е. что генерятся соотв. методы знал, а что они отличаются спец. атрибутами не знал.
Но что это меняет? Все равно будут вызываться методы. Т.е. пропертя это своего рода синтаксический сахар,
довольно удачный. Но почему без них невозможно в sql не понятно?

S>>Так и будет компилироватсья в sql.

G>Пока неясно

У меня будут вместо св-в генерироваться, допустим ORM, соотв. методы типа get_X. Дергать их.
Т.е. там, где исп. св-ва, что мешает исп. сгенерированные методы?

S>>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.

G>в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
G>Bind в обе стороны работает.

Да, упустил. Ну опять же, кто-то это дело будет интерпритировать и у соотв. объекты вызывать соотв. методы get\set.


G>Собственно наличие метаданных свойств и позволяет делать всякие привязки и мэппинги. А синтаксис свойств не позволяет написать пару методов на которых мэппинги не сработают. Так что это чуть больше, чем просто синтаксический сахар


Все так. Я не понимаю, если в конце, на уровне clr, один хрен будут вызываться методы, то это просто
способо избавить программиста от лишнего кода или от сгенерированного кода. Т.е. св-ва -- это просто
упрощение, а не концептуальная возможность. В конце концов, как в яве то без св-в живут и сущ. ORM
типа NHibernate?

Т.е. я согласен, что св-ва многое упрощают и т.д. Я не пониманию, почему св-ва делют что-то концептуально
возможным. Блин, это же сахар, в конце концов.
Кодом людям нужно помогать!
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 11:37
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

G>>>2) Как потом оно будет компилироваться в SQL ?

S>>На уровне clr нету никаких св-в
НС>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.

См. выше мой ответ.

НС> Во-вторых этот пример про expression tree, там код не компилируется до IL, а преобразуется в построение AST, которое потом интерпретируется в рантайме. Так что что там знает clr в данном примере совершенно неважно.


Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X. Более того, отвечу от противного --
а как у ява c Hibernate все это дело работает? Как-то же работает.
Кодом людям нужно помогать!
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 11:40
Оценка:
Здравствуйте, Serginio1, Вы писали:


S>>На уровне clr нету никаких св-в, там есть соотв. методы. Так и будет компилироватсья в sql.


S> Угу а как же вызов свойства через рефлекшн?

S>
S>public static object GetPropValue(object src, string propName)
S> {
S>     return src.GetType().GetProperty(propName).GetValue(src, null);
S> }
S>


Ну для спец. методов отдельный интерфейс, ну ок, и?

S> Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn

S>Для SourceGenerator
S>https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

S> Ну и инлайнинг методов свойства.


Не понял.

S>Свойства оочень удобны. Особенно после Явы.


Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает,
а не делает концептуально возможным.
Кодом людям нужно помогать!
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 12:38
Оценка:
Здравствуйте, Sharov, Вы писали:


S>> Тот же Roslyn https://stackoverflow.com/questions/38205773/how-to-create-struct-based-properties-with-roslyn

S>>Для SourceGenerator
S>>https://stackoverflow.com/questions/21316952/using-roslyn-for-c-how-do-i-get-a-list-of-all-properties-that-compose-a-return

S>> Ну и инлайнинг методов свойства.


S>Не понял.


Что именно? Для генерации кода или обработки кода через Roslyn в том же SourceGenerator удобнее оперировать свойствами, чем методами.

А методы свойств по умолчанию инлайнятся. То скорость доступа к полю или свойству одинаков
S>>Свойства оочень удобны. Особенно после Явы.

S>Я не спорю. Просто какую концептуальную возможность они добавили. Сахар просто что-то упрощает,

S>а не делает концептуально возможным.

Ну прежде всего это Reflection и обработка кода через Roslyn или прочие парсеры и модификаторы кода.
Вот например атрибуты это сахар?
и солнце б утром не вставало, когда бы не было меня
Re[4]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 02.02.23 13:18
Оценка:
Здравствуйте, Sharov, Вы писали:

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

S>реализованы через type erasure (1ая ссылка гугля). Т.е. компилятор
S>чего-то там генерил, удалял и т.п. run-time про дженерики ничего не знал. Т.е. вроде бы есть, а вроде бы лучше
S>чтобы и не было. Наверное, это имелось в виду. А по уму они сделаны с C# 2.0, например, когда run-time отменно знал
S>про такое расширение типов и компилятору не надо было приседать.

С этим мнением я не согласен. Мне type erasure даже где-то нравится. Изящное решение. То, что рантайм про генерики не знает — может быть и кажется плохим, но на практике проблемы вызывает только в одном месте — иногда нужно прокидывать Class<T>. Но вот эту проблему прекрасно решает концепция reified generics в Kotlin. Компилятор в нужные места сам прокидывает рантайм тип скрытым параметром.

Не буду утверждать, что type erasure лучше, чем система из C#, у обоих подходов есть свои плюсы и минусы, наверное. Могу только утверждать, что ругают type erasure больше, чем он того заслуживает.

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

Мне не нравится само усложнение системы типов из-за генериков. Я сдавал в своё время сертификат sun и учил каждый нюанс в жаве. И генерики были самой сложной и запутанной темой. Я натыкался когда-то на баг в компиляторе javac. И баг был как раз связан с генериками. Я уверен, что 90% программистов на Java в генериках разбираются плохо. И это проблема языка.
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 14:38
Оценка:
Здравствуйте, Sharov, Вы писали:

НС>>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.

S>См. выше мой ответ.

Это все неверно. Дело не в атрибутах, в метаданных есть прям такая сущность, свойство.

S>Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X.


Можно. Но соответствие между геттером и сеттером компилятором при этом не проверяется. Т.е. свойство это не сахар, как Шимжа утверждал, а важный элемент системы типов. И замену системы типов на рефлекшен полноценной заменой никак нельзя назвать.

S> Более того, отвечу от противного -- а как у ява c Hibernate все это дело работает? Как-то же работает.


Фиговенько. Понадобилось вводить дополнительную сущность, Hibernate mapping types, которую надо отдельно описывать в xml файле. И который потом связывается с джавовским классом при помощи рефлекшен-магии.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 14:41
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Угу а как же вызов свойства через рефлекшн?


Плохой пример. Вызов свойств через рефлекшен это просто сахар, т.е. GetValue() эквивалентен GetGetMethod().Invoke().
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 14:46
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>> Угу а как же вызов свойства через рефлекшн?


НС>Плохой пример. Вызов свойств через рефлекшен это просто сахар, т.е. GetValue() эквивалентен GetGetMethod().Invoke().


Если нет свойства нужно искать GetMethod или SetMethod. Понятно, что в итоге вызовется GetMethod.
Я про то, что в "CLR не используются свойства". В метаданных они есть и соответсвенно их вызов через рефлекшен.
и солнце б утром не вставало, когда бы не было меня
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 14:49
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

S>>А методы свойств по умолчанию инлайнятся.


НС>Простые методы без всяких свойств тоже инлайнятся.

В последних да, а вот например в 64 разрядных не инлайнились свойства на 3.5 или каких там https://stackoverflow.com/questions/646779/does-c-sharp-inline-properties
и солнце б утром не вставало, когда бы не было меня
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 15:40
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Простые методы без всяких свойств тоже инлайнятся.

S>>В последних да,

НС>Не в последних тоже.


Что понимать под последними. Некоторые кстати еще сидят и на 3.5.
public enum MethodImplOptions {
        Unmanaged = 4,
        ForwardRef = 16,
        InternalCall = 4096,
        Synchronized = 32,
        NoInlining = 8,
        PreserveSig = 128,
        NoOptimization = 64,
#if NET_4_5
        AggressiveInlining  = 256,
#endif
    } // MethodImplOptions
и солнце б утром не вставало, когда бы не было меня
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 16:08
Оценка:
Здравствуйте, vsb, Вы писали:


vsb>С этим мнением я не согласен. Мне type erasure даже где-то нравится. Изящное решение. То, что рантайм про генерики не знает — может быть и кажется плохим, но на практике проблемы вызывает только в одном месте — иногда нужно прокидывать Class<T>. Но вот эту проблему прекрасно решает концепция reified generics в Kotlin. Компилятор в нужные места сам прокидывает рантайм тип скрытым параметром.

vsb>Не буду утверждать, что type erasure лучше, чем система из C#, у обоих подходов есть свои плюсы и минусы, наверное. Могу только утверждать, что ругают type erasure больше, чем он того заслуживает.
vsb>Про приседания компилятора я не очень понял. Вся мета-информация в байткоде, конечно же, сохраняется и никаких приседаний особенных там нет. Нюансы есть при взаимодействии старого кода и нового, но тоже ничего особенного нет, думаю и в C# эти же нюансы есть.

Компилятор разве код не переписывает или генерирует новый?

vsb>Мне не нравится само усложнение системы типов из-за генериков. Я сдавал в своё время сертификат sun и учил каждый нюанс в жаве. И генерики были самой сложной и запутанной темой. Я натыкался когда-то на баг в компиляторе javac. И баг был как раз связан с генериками. Я уверен, что 90% программистов на Java в генериках разбираются плохо. И это проблема языка.


Как показал C#, это именно проблема реализации.
Кодом людям нужно помогать!
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 16:13
Оценка:
Здравствуйте, Sharov, Вы писали:

S>S> Вот например атрибуты это сахар?


S>Хороший вопрос -- с одной стороны так проще что-то манефистировать для clr или рефлексии, с др. стороны

S>это можно сделать определенными методами/св-ми и т.п., но тогда надо вводить какие-то договоренности. Атрибуты
S>от этого освобождают.
Кстати как пример PropertyGrid. Он как раз плотно работает с атрибутами и свойствами.
Не забываем и о пользователях. Им проще оперировать как раз свойствами в том же PropertyGrid
и солнце б утром не вставало, когда бы не было меня
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 17:01
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sharov, Вы писали:


НС>>>В-первых кто тебе такую глупость сказал? В метаданных информация о свойствах присутствует.

S>>См. выше мой ответ.
НС>Это все неверно. Дело не в атрибутах, в метаданных есть прям такая сущность, свойство.

Что неверно? Ну есть такая конструкция, ну связывает она методы воедино:

    // Properties
    .property instance int32 Test()
    {
        .get instance int32 C::get_Test()
        .set instance void C::set_Test(int32)
    }


Ну программисту проще, да, можно просто св-во указать, а не методы прописывать. Что еще?

S>>Вопрос хороший, но я опять же не понимаю, почему вместо prop_X нельзя get_X.

НС>Можно. Но соответствие между геттером и сеттером компилятором при этом не проверяется. Т.е. свойство это не сахар, как Шимжа утверждал, а важный элемент системы типов. И замену системы типов на рефлекшен полноценной заменой никак нельзя назвать.

Ну да, тут автоматом подставит соотв. метод, опять же меньше писанины.

S>> Более того, отвечу от противного -- а как у ява c Hibernate все это дело работает? Как-то же работает.

НС>Фиговенько. Понадобилось вводить дополнительную сущность, Hibernate mapping types, которую надо отдельно описывать в xml файле. И который потом связывается с джавовским классом при помощи рефлекшен-магии.

А разве этот xml файл не автоматом генериться? Вроде в ef тоже раньше были подобные xml файлы.
Кодом людям нужно помогать!
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.02.23 18:20
Оценка:
Здравствуйте, Sharov, Вы писали:

S>А разве этот xml файл не автоматом генериться? Вроде в ef тоже раньше были подобные xml файлы.

В ef давно c edmx.
Сейчас перешли на генерацию классов с атрибутами Code First и Linq to EF на примере 1С версии 8.3. Часть II
и солнце б утром не вставало, когда бы не было меня
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Ночной Смотрящий Россия  
Дата: 02.02.23 20:37
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Что неверно?


То что нет никаких атрибутов у методов, а есть специальная сущность в метаданных.

S>Ну программисту проще, да, можно просто св-во указать, а не методы прописывать. Что еще?


Такое ощущение, что ты не читаешь что тебе отвечают. Еще раз — свойство это часть системы типов.

НС>>Можно. Но соответствие между геттером и сеттером компилятором при этом не проверяется. Т.е. свойство это не сахар, как Шимжа утверждал, а важный элемент системы типов. И замену системы типов на рефлекшен полноценной заменой никак нельзя назвать.


S>Ну да, тут автоматом подставит соотв. метод, опять же меньше писанины.


Я выделил жирным в цитате, что ты не заметил при первом прочтении. Дело не в писанине.

S> Вроде в ef тоже раньше были подобные xml файлы.


Нет. В EF это был графический DSL для описания модели данных. И он был опциональным.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 02.02.23 21:02
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Такое ощущение, что ты не читаешь что тебе отвечают. Еще раз — свойство это часть системы типов.


Я это уже понял, что дальше, как это помогает в генерации sql, например? Т.е. что бы было до, и как улучшилось после?

НС>>>Можно. Но соответствие между геттером и сеттером компилятором при этом не проверяется. Т.е. свойство это не сахар, как Шимжа утверждал, а важный элемент системы типов. И замену системы типов на рефлекшен полноценной заменой никак нельзя назвать.

S>>Ну да, тут автоматом подставит соотв. метод, опять же меньше писанины.
НС>Я выделил жирным в цитате, что ты не заметил при первом прочтении. Дело не в писанине.

Я это видел. А почему это так важно, учитывая, что у нас они могут быть и по отдельности?
Ну помечает компилятор в соотв. метаданных сборки, что эти методы явл. спец методами для св-в.

Я сколько не пытался найти концептуальной новизны для св-в, народ в этих ваших пишет,
что св-ва в основном для инкапсуляции и проч. и проч.
https://softwareengineering.stackexchange.com/questions/62383/what-is-the-point-of-properties

Вот интересное оттуда:

Properties in C# were simply syntactic sugar for a very common pattern that made our lives as programmers a bit easier. However, these days, if you want to use data binding you "must" use properties, so they are now a bit more than syntactic sugar. I guess I really just don't agree with any of your points at all and I don't understand why you dislike a language feature that directly supports a common pattern.

https://softwareengineering.stackexchange.com/a/62394/364605

Для меня они сахар, для кого-то -- больше. Я не очень понял, почему без св-в нельзя обойтись для работы с sql.
А для биндинга да, они, видимо, один из ключевых компонентов. Хотя я не понимаю, почему и здесь
нельзя обойтись методами -- один хрен, в конце концов будут вызываться методы, без какой-либо магии.
Просто на уровне типов они действительно многое упрощают, как минимум для биндинга.
Кодом людям нужно помогать!
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 09:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

vsb>>В Go это решается встроенными структурами данных и утверждением, что свои структуры данных нужны достаточно редко, чтобы это не было проблемой.

G>Ага, а спустя 5 лет таки добавили генерики. Что поменялось? Стали структуры часто нужны? Или изначальные утвреждения были ошибочными.

Или добавление генериков было ошибочным

vsb>>Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

G>При таком раскладе лучше сразу в C++ пойти. зачем два языка надо?
G>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?

Какие? Я таких не знаю.

vsb>>По-мне половина функционального кода в той же жаве читается хуже, чем версии на циклах и условиях. Да, есть случаи, когда функциональный подход прям прекрасно ложится на алгоритм, а императивный подход многословен. Но это не то, что помешает писать хорошие программы.

G>Количество кода это не субъективная величина. Если одну и ту же задачу можно решить на языке А в 50 строк, а на языке Б в 20, то всегда стоит выбирать Б, независимо от того кому какой язык нравится.

Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 10:08
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут.

Проблема не только в языке, но и области применения. Для Андроида родной Java плюс долго но уверенно набирает популярность Котлин. А большинство программистов находятся в мобильном сегменте и Вэб фронт где JS и TS
и солнце б утром не вставало, когда бы не было меня
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 10:20
Оценка:
Здравствуйте, Serginio1, Вы писали:

vsb>>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут.

S> Проблема не только в языке, но и области применения. Для Андроида родной Java плюс долго но уверенно набирает популярность Котлин. А большинство программистов находятся в мобильном сегменте и Вэб фронт где JS и TS

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

При этом тот же JS популярность имеет бешеную, и на сервере, и в мобильных телефонах и где только его не встретишь. Не удивлюсь, если для ядра уже модули где-нибудь на нём пишут. И ему область применения расширять ничего не мешает.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 10:31
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>>>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут.

S>> Проблема не только в языке, но и области применения. Для Андроида родной Java плюс долго но уверенно набирает популярность Котлин. А большинство программистов находятся в мобильном сегменте и Вэб фронт где JS и TS

vsb>Котлин набирает популярность на андроиде только потому, что Гугл его объявит языком номер один на своей платформе. На сервере Котлин особую популярность не снискал, к примеру.


vsb>При этом тот же JS популярность имеет бешеную, и на сервере, и в мобильных телефонах и где только его не встретишь. Не удивлюсь, если для ядра уже модули где-нибудь на нём пишут. И ему область применения расширять ничего не мешает.


Ну если ты заметил, то и TS набирает силу. Xamarin для Android тоже немного прибавляет. А так же Блазор для фронта.
Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.
Если, же писать что то монструозное, то выбор JS как языка это ...
А как у JS с многопоточностью?
и солнце б утром не вставало, когда бы не было меня
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 11:40
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Ну если ты заметил, то и TS набирает силу.


Я TS от JS особо не отличаю, они можно сказать в тандеме работают.

S>Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.


А точно — дешевле? По-моему все примерно одинаково стоят.

S>А как у JS с многопоточностью?


Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.
Отредактировано 03.02.2023 11:41 vsb . Предыдущая версия .
Re[13]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 12:04
Оценка:
Здравствуйте, vsb, Вы писали:

S>>Ну если ты заметил, то и TS набирает силу.


vsb>Я TS от JS особо не отличаю, они можно сказать в тандеме работают.

Угу это по сути 2 разных языка. Даже код.
S>>Ну писать то конечно можно где угодно. Суть в том, что JS программистов много и дешевле. Для многих задач это не критично.

vsb>А точно — дешевле? По-моему все примерно одинаково стоят.


S>>А как у JS с многопоточностью?


vsb>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.

Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
Если их в языке нет нет понятия потока?
Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
и солнце б утром не вставало, когда бы не было меня
Re[14]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 12:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Ну если ты заметил, то и TS набирает силу.


vsb>>Я TS от JS особо не отличаю, они можно сказать в тандеме работают.

S> Угу это по сути 2 разных языка. Даже код.

Чего это разных? Любой код на JS является валидным кодом на TS. Более того, преобразователь из TS в JS пишется вообще тривиально — вырезаем типы и всё, остаётся валидный JS. В принципе компилятор tsc примерно так и работает (ну помимо проверки типов на этапе компиляции).

vsb>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.

S> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
S> Если их в языке нет нет понятия потока?
S> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/

Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.
Re[15]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 12:48
Оценка:
Здравствуйте, vsb, Вы писали:

S>>>>Ну если ты заметил, то и TS набирает силу.


vsb>>>Я TS от JS особо не отличаю, они можно сказать в тандеме работают.

S>> Угу это по сути 2 разных языка. Даже код.

vsb>Чего это разных? Любой код на JS является валидным кодом на TS. Более того, преобразователь из TS в JS пишется вообще тривиально — вырезаем типы и всё, остаётся валидный JS. В принципе компилятор tsc примерно так и работает (ну помимо проверки типов на этапе компиляции).

Во во. Еще там приведение типов,дженерики, интерфейсы итд.
В C# то же есть динамики

vsb>>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.

S>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
S>> Если их в языке нет нет понятия потока?
S>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/

vsb>Почему костыли-то? По-мне это все эти мьютексы — костыли. А нормальные потоки должны обмениваться сообщениями и никак иначе. Всё по заветам товарища Армстронга.


Угу, а как блокировать доступ к переменным?
Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?
и солнце б утром не вставало, когда бы не было меня
Re[17]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 12:55
Оценка:
Здравствуйте, vsb, Вы писали:

S>>Угу, а как блокировать доступ к переменным?


vsb>не должно быть никакого доступа к переменным.


S>> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?


vsb>Сообщениями. Вон тут в теме разработчик sobjectizer-а, думаю, расскажет, почему акторы лучше общих переменных.


Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?
Кстати вот и еще один объект синхронизации c# ReaderWriterLockSlim
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.02.2023 13:22 Serginio1 . Предыдущая версия .
Re[17]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 03.02.23 13:08
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Вон тут в теме разработчик sobjectizer-а, думаю, расскажет, почему акторы лучше общих переменных.


Не всегда и не во всем, увы.
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 03.02.23 13:16
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>Но что это меняет? Все равно будут вызываться методы. Т.е. пропертя это своего рода синтаксический сахар,

S>>довольно удачный. Но почему без них невозможно в sql не понятно?
G>Ну предложите вариант как сделать произвольную проекцию типизированной (проверяемой при компиляции) без свойств.

Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе
на каждый чих заводить соотв. тип\класс.


S>>У меня будут вместо св-в генерироваться, допустим ORM, соотв. методы типа get_X. Дергать их.

S>>Т.е. там, где исп. св-ва, что мешает исп. сгенерированные методы?
G>А как их потом перевести в sql?

Блин, также, только там где стоит св-во, исп. соотв. метод. Как в яве-то это делается?


S>>>>Не знаток Blazor, а разве в bind нельзя вызвать ф-ию, т.е.

G>>>в чем проблема вместо InputValue запихнуть get_inputvalue с соотв. типом?
G>>>Bind в обе стороны работает.
S>>Да, упустил. Ну опять же, кто-то это дело будет интерпритировать и у соотв. объекты вызывать соотв. методы get\set.
G>И снова вопрос типизации и проверки при компиляции.

Не знаток Blazor, но в winforms если я исп. класс binding, он может во время исп. стрельнуть, что
нету какого-нибудь сеттера.


S>>Т.е. я согласен, что св-ва многое упрощают и т.д. Я не пониманию, почему св-ва делют что-то концептуально

S>>возможным. Блин, это же сахар, в конце концов.
G>"не верю, докажите мне" не очень разумная позиция.

Я не понял приписываемую магию св-ам в c#, типа без них невозможно создавать sql запросы и т.п. Когда как
пусть неудачный, но пример явы показывет, что все можно. Но св-ва действительно многое упрощают. Особенно биндинг.
Но там генерится соотв. код и если что-то где-то пропустили, то дадут знать на этапе компиляции. Это огромный плюс.
Кодом людям нужно помогать!
Re[18]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 13:17
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?


Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены.
Re[19]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 13:25
Оценка:
Здравствуйте, vsb, Вы писали:


S>> Для примера возьмем ту же БД. Там есть и версионность. Но что делать, если ты читаешь после начавшейся транзакции которая изменяет данные?


vsb>Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены.

А БД это пример доступа к данным и их изменениям из разных потоков. Там все равно применяют блокировки и получают взаимные блокировкаи.
Если все так просто как ты говоришь, почему же до сих пор в БД этого не сделали?

Как правило есть общие данные и они должны изменяться. И как прочитать реальные данные, а не изменяющиеся?
Не всегда оптимально держать такие данные в БД.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.02.2023 13:28 Serginio1 . Предыдущая версия .
Re[20]: Синтаксический сахар vs реально полезные вещи в ЯП
От: vsb Казахстан  
Дата: 03.02.23 13:30
Оценка:
Здравствуйте, Serginio1, Вы писали:

vsb>>Что-то я запутался, какое отношение БД имеет к этой дискуссии. Если отвечать на этот вопрос — то что делать, зависит от БД, от уровня изоляции транзакций, от особенностей реализации этой БД и тд. Можно попасть в блокировку, можно читать "старые" данные, можно читать "свежие" данные, которые даже не были ещё закоммичены.

S> А БД это пример доступа к данным и их изменениям из разных потоков. Там все равно применяют блокировки и получают взаимные блокировкаи.

В БД доступ к данным вообще из разных компьютеров в общем случае.

S>Если все так просто как ты говоришь, почему же до сих пор в БД этого не сделали?


Я не знаю, как сделали в БД, хотя давно хочу исходники постгреса почитать, но как-то случая не представляется.

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

В любом случае пользовательский код и БД это сильно разные сущности. Не думаю, что есть какие-то принципиальные проблемы сделать эксклюзивный доступ к ресурсу через обмен сообщениями.
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 03.02.23 14:04
Оценка:
Здравствуйте, gandjustas, Вы писали:

vsb>>Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

G>При таком раскладе лучше сразу в C++ пойти. зачем два языка надо?
G>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?

Питон, например.
Кодом людям нужно помогать!
Re[21]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 14:31
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>В любом случае пользовательский код и БД это сильно разные сущности. Не думаю, что есть какие-то принципиальные проблемы сделать эксклюзивный доступ к ресурсу через обмен сообщениями.

В большинстве случаев одинаковы. Ну вот твой подход это создание очереди и ожидание ответа.
Но в большинстве случаев не надо ничего посылать. Для этого прекрасно работают ReaderWriterLockSlim. Когда много читателей и редко писатель.
Опять ожидать ответа как будешь? Через постоянный опрос очереди?
Можно конечно еще и через пайпы или Tcp/ip!

Можно конечно через async await TaskCompletionSource<T> c TrySetResult(item);
Если не хочешь использовать эвенты.
Но это нехилые расходы ReaderWriterLockSlim намного экономнее.

Даже обычный lock!
Поэтому выбирают более эффективные объекты синхронизации
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.02.2023 14:38 Serginio1 . Предыдущая версия .
Re[8]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 03.02.23 16:27
Оценка:
G>Ага, а спустя 5 лет таки добавили генерики. Что поменялось?

У разработчиков появилось время на реализацию. Никакой магии
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 03.02.23 16:32
Оценка:
S> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?

Им нужно обмениваться сообщениями (а не "локами" и прочими абстракциями которые не могут работать в распределенных системах).
Re[10]: Eiffel
От: Sharov Россия  
Дата: 03.02.23 17:08
Оценка:
Здравствуйте, so5team, Вы писали:

S>Ada, Eiffel, Rust, D.


Ну кто его кроме Мейера и в исследовательских целях использует?
Кодом людям нужно помогать!
Re[17]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.02.23 18:03
Оценка:
Здравствуйте, SkyDance, Вы писали:

S>> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?


SD>Им нужно обмениваться сообщениями (а не "локами" и прочими абстракциями которые не могут работать в распределенных системах).

Еще раз какой обмен сообщениями в пуле потоков?
Многие используют БД и прочие медленные абстракции с обменом сообщений между процессами.
Можно еще придумать кучу как все замедлить.
Кстати в тех же распределенных системах присутствуют Redis

Redis — это база данных, размещаемая в памяти, которая используется, в основном, в роли кеша, находящегося перед другой, «настоящей» базой данных, вроде MySQL или PostgreSQL. Кеш, основанный на Redis, помогает улучшить производительность приложений. Он эффективно использует скорость работы с данными, характерную для памяти, и смягчает нагрузку центральной базы данных приложения, связанную с обработкой следующих данных:

Данные, которые редко меняются, к которым часто обращается приложение.
Данные, не относящиеся к критически важным, которые часто меняются.

https://habr.com/ru/company/wunderfund/blog/685894/

Но внутри БД так или иначе присутствуют те же мониторы и прочие объекты синхронизации.

Ну и речь, то идет о JS и многопоточности в нём!
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.02.2023 18:09 Serginio1 . Предыдущая версия . Еще …
Отредактировано 03.02.2023 18:08 Serginio1 . Предыдущая версия .
Отредактировано 03.02.2023 18:07 Serginio1 . Предыдущая версия .
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 20:30
Оценка:
Здравствуйте, vsb, Вы писали:

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


vsb>>>В Go это решается встроенными структурами данных и утверждением, что свои структуры данных нужны достаточно редко, чтобы это не было проблемой.

G>>Ага, а спустя 5 лет таки добавили генерики. Что поменялось? Стали структуры часто нужны? Или изначальные утвреждения были ошибочными.

vsb>Или добавление генериков было ошибочным

То есть в C# добавили генерики в версии 2.0, это норм
В java добавили generics в версии 5, тоже норм
А Go такой прекрасный язык без генириков, что добавление их туда было ошибкой? Сомнительно


vsb>>>Если это вопрос жизни и смерти — ну напиши на C этот кусок программы.

G>>При таком раскладе лучше сразу в C++ пойти. зачем два языка надо?
G>>Почему другие языки, даже высокоуровневые, не предлагают пойти в C если надо что-то сделать более оптимальным?

vsb>Какие? Я таких не знаю.

C#, Java, JS (Node)

vsb>>>По-мне половина функционального кода в той же жаве читается хуже, чем версии на циклах и условиях. Да, есть случаи, когда функциональный подход прям прекрасно ложится на алгоритм, а императивный подход многословен. Но это не то, что помешает писать хорошие программы.

G>>Количество кода это не субъективная величина. Если одну и ту же задачу можно решить на языке А в 50 строк, а на языке Б в 20, то всегда стоит выбирать Б, независимо от того кому какой язык нравится.

vsb>Ну тогда весь мир писал бы на C#, он фичами обвешан, как новогодняя ёлка гирляндами. Но — не пишут.

Конечно это не так. Выбор языков и технологий подвержен маркетингу в гораздо большей степени, чем здравому смыслу, даже если вам кажется обратное.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 20:37
Оценка:
Здравствуйте, Sharov, Вы писали:

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



S>Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе

S>на каждый чих заводить соотв. тип\класс.
Ну так если не анонимный тим, то как должно работать? заставлять выставлять филды наружу?

S>Блин, также, только там где стоит св-во, исп. соотв. метод. Как в яве-то это делается?

Никакой типизиации при компиляции. К строковым именам добавляются get_ и set_ префиксы чтобы найти методы.


S>Не знаток Blazor, но в winforms если я исп. класс binding, он может во время исп. стрельнуть, что

S>нету какого-нибудь сеттера.
Может. А может при компиляции подсветить ошибку, что типы не совпадают.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.02.23 20:38
Оценка:
Здравствуйте, SkyDance, Вы писали:

G>>Ага, а спустя 5 лет таки добавили генерики. Что поменялось?


SD>У разработчиков появилось время на реализацию. Никакой магии


То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?
Это, конечно, очень повышает доверие к разработчикам языка
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 03.02.23 21:14
Оценка:
G>То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?

Рассказы — это уже специфика группировок. Есть поддержка и первого варианта ("генерики не нужны"), и второго ("нужны"). Оба мнения имеют право на жизнь, есть обоснования и для того, и для другого.

G>Это, конечно, очень повышает доверие к разработчикам языка


А это вообще могут быть люди, не входящие ни в одну из перечисленых выше группировок
Любой "design by committee" противоречив по определению.
Re[14]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rollcoin  
Дата: 04.02.23 03:46
Оценка:
Здравствуйте, Serginio1, Вы писали:


S>>>А как у JS с многопоточностью?


vsb>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней.

S> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.
S> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/

И чем же фьютексы вам — это не объекты синхронизации, а костыли?
Atomic API — это фьютексы.

S> Если их в языке нет нет понятия потока?

Вы не найдете в стандарте языка Си понятие потока.
Поток — это сущность рантайма. Для Си — рантайм это операционная система. Для js — это движки жс.
Все мейнстрим движки жс имеют потоки.
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
От: SkyDance Земля  
Дата: 04.02.23 04:13
Оценка:
G>Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны. И ФП тоже нужно.

ФП — согласен.

А вот что до генериков, это уже не столь очевидный вопрос. Как и в случае с любой другой опциональной фичей. Это всегда очень легко, добавлять фичи. Это почти всегда громко приветствуется, типа "урааа, теперь еще поддерживается и вот это". Поэтому почти всегда в сражении "добавить сложности vs оставить простым" рано или поздно выигрывает группировка №1. Та что "ну мы же ничего не ломаем, только добавляем новую фичу".

Ровно поэтому любое популярное приложение превращается в Outlook убер-апп, всемогутор. Грааль, так сказать. Бери что угодно, не ошибешься. От WeChat до Telegram. От C++ до, простите, JS.

G>Сначала комитет постановил что "генерики не нужны", потом постановил что нужны.

G>Что изменилось за это время?

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

См. аналогичный пример с Apple, и происходящий сейчас процесс разрастания продуктовых линеек. Сегментирование на все больше и больше кусочков рынка. Вместо созидания — просто охват "еще вот этой категории". Иными словами, кризис идей (наблюдается по всей индустрии, надо отметить). Нет у них больше Джобса с манда-том

Что будет дальше? На примере С++ видно, что дальше будет появление чего-то менее развесистого и backwards compatible, без половины фич старого языка, но зато куда более простое в освоении и использовании. Ну, скажем, Rust. Который тоже начнет разрастаться (если еще не), до тех пор пока не увязнет в собственном наследии. И далее по кругу.
Re[15]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.02.23 08:54
Оценка:
Здравствуйте, rollcoin, Вы писали:

S>> Если их в языке нет нет понятия потока?

R>Вы не найдете в стандарте языка Си понятие потока.
R>Поток — это сущность рантайма. Для Си — рантайм это операционная система. Для js — это движки жс.
R>Все мейнстрим движки жс имеют потоки.
Я не знаток дж движков, но https://stackoverflow.com/questions/59630103/using-worker-thread-in-electron
и солнце б утром не вставало, когда бы не было меня
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rollcoin  
Дата: 04.02.23 11:27
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Я не знаток дж движков, но https://stackoverflow.com/questions/59630103/using-worker-thread-in-electron


https://www.electronjs.org/docs/latest/tutorial/multithreading
Re[17]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.02.23 16:02
Оценка:
Здравствуйте, rollcoin, Вы писали:

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


S>> Я не знаток дж движков, но https://stackoverflow.com/questions/59630103/using-worker-thread-in-electron


R>https://www.electronjs.org/docs/latest/tutorial/multithreading

Угу ты ссылку мою не читал? Туториал то есть, только не работает у них. Вернее в отладке работал, а в реалиях нет. Правда это было в 20 году.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.02.2023 16:03 Serginio1 . Предыдущая версия .
Re[18]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rollcoin  
Дата: 04.02.23 16:24
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Угу ты ссылку мою не читал? Туториал то есть, только не работает у них. Вернее в отладке работал, а в реалиях нет. Правда это было в 20 году.


Я-то читал, а ты похоже нет.
В твоей сслке спрашивают как в электроне использовать worker_threads из Node API, даже ссылку на них дают прямо в вопросе (https://nodejs.org/api/worker_threads.html)

А я тебе показываю ссылку на официальный мануал электрона, в котором черным по белому пишут, что использовать надо не кастомные нодовские worker_threads, а обычные Web Worker API, которые работают во всех браузерах. И снова дают на них ссылку (https://developer.mozilla.org/en/docs/Web/API/Web_Workers_API/Using_web_workers)

А чтобы в них был доступен API ноды (в электроне два слоя апи — web и нодовское, потому как элетктрон это — CEF в котором ванильный v8 заменили на v8 из ноды с его апи сбоку). Так вот чтобы в обычных СТАНДАРТНЫХ воркерах, которые стандартиированны коммитетом, в электроне, стали достпуны нодовские апи, надо выставить флаг при создании процесса (nodeIntegrationInWorker: true).

Нодовские воркеры в электроне не нужны, потому что в электроне внезапно есть нативные обычные веб воркреры.

Все работает. Я на электроне 8 лет пишут. А твой вопрос на SO — типичная ситуация о том, что хочу того, чего мне на самом деле не нужно, а манулы читать не буду.
Re[19]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.02.23 18:06
Оценка:
Здравствуйте, rollcoin, Вы писали:



R>А чтобы в них был доступен API ноды (в электроне два слоя апи — web и нодовское, потому как элетктрон это — CEF в котором ванильный v8 заменили на v8 из ноды с его апи сбоку). Так вот чтобы в обычных СТАНДАРТНЫХ воркерах, которые стандартиированны коммитетом, в электроне, стали достпуны нодовские апи, надо выставить флаг при создании процесса (nodeIntegrationInWorker: true).


R>Нодовские воркеры в электроне не нужны, потому что в электроне внезапно есть нативные обычные веб воркреры.


R>Все работает. Я на электроне 8 лет пишут. А твой вопрос на SO — типичная ситуация о том, что хочу того, чего мне на самом деле не нужно, а манулы читать не буду.


Ну через CEF конечно можно, что угодно. Только вот это ну никак не опция языка. Сам использовал CEF.
И даже .Net встраивал.
CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF
CEF, Angular 2 использование событий классов .Net Core

Там и воркеры никакие не нужны!
и солнце б утром не вставало, когда бы не было меня
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Sharov Россия  
Дата: 04.02.23 18:46
Оценка:
Здравствуйте, gandjustas, Вы писали:

S>>Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе

S>>на каждый чих заводить соотв. тип\класс.
G>Ну так если не анонимный тим, то как должно работать? заставлять выставлять филды наружу?

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

S>>Не знаток Blazor, но в winforms если я исп. класс binding, он может во время исп. стрельнуть, что

S>>нету какого-нибудь сеттера.
G>Может. А может при компиляции подсветить ошибку, что типы не совпадают.

В контексте wf пример взял отсюда, чего компилятор тут подсветит:
  Binding b = new Binding("Text", ds, "customers.custToOrders.OrderAmount")

?
Кодом людям нужно помогать!
Re[20]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rollcoin  
Дата: 04.02.23 18:56
Оценка:
Здравствуйте, Serginio1, Вы писали:


S>Ну через CEF конечно можно, что угодно. Только вот это ну никак не опция языка. Сам использовал CEF.

S>И даже .Net встраивал.
S> Там и воркеры никакие не нужны!

Да что вы такое несете-то.

И POSIX API и Win API — это не опции языка. Внезапно. Выходит у нас теперь и Си и Плюсы и вообще все языки становятся не многопотными, да?

Еще раз — CEF — это рантайм (один из многих) для javascript-кода. Воркеры — это API многопотчности для javascript кода.
API воркеров реализует окружение — точно так же как операционная система предоставляет api для создания потоков и процессов. На нижнем уровне воркеры — это настоящие железные потоки уровня ОС — такие же как в си. Каждый воркер — отдельный поток. Но жс коду это до фонаря. Он не оперирует такими терминами, так же как ими не оперирует например Go, или эрланг.

Web Worker API — это часть спецификаций Web API. Так же, как потоки в операционных системах часть спецификаицй, напрмиер POSIX API или Win API.

Реализуют апи воркеров — окружение. Это браузеры, или нода, или кто угодно еще, куда встраивается жс движок. Так же, как Posix API реализует и UNIX и Linux и PlanB и MacOS и даже Windows когда-то.

Потоки — это не сущость языка программирования — это сущность рантайма.

Рантаймы javascript — многотопочны. Примитивы синхронизации Atomic API — часть стандарта языка.
Re[20]: Синтаксический сахар vs реально полезные вещи в ЯП
От: rollcoin  
Дата: 04.02.23 18:57
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Ну через CEF конечно можно, что угодно


Речь была про многопотность в Электроне, которую ты сам же поднял.
Электрон это и есть CEF.
Re[15]: Синтаксический сахар vs реально полезные вещи в ЯП
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.02.23 19:58
Оценка:
Здравствуйте, rollcoin, Вы писали:

S>> Если их в языке нет нет понятия потока?

R>Вы не найдете в стандарте языка Си понятие потока.

"Да что ж вы такое несёте то". ([rollcoin@])
Рекомендую просветиться.

S>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры.

S>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
R>И чем же фьютексы вам — это не объекты синхронизации, а костыли?

А при чём тут вообще фьютексы к этой статье? Что там под капотом, для неё не важно.

R>Atomic API — это фьютексы.


А завтра это будет что-то другое.
The God is real, unless declared integer.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.02.23 21:44
Оценка:
Здравствуйте, Sharov, Вы писали:

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


S>>>Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе

S>>>на каждый чих заводить соотв. тип\класс.
G>>Ну так если не анонимный тим, то как должно работать? заставлять выставлять филды наружу?

S>А есть особоя разница между классом с одними св-вами и классом с публичными полями, особенно

S>в случае анемичной модели. Инкапсуляция нарушается, но жить можно.
А если людям захочется ричЪ модель?

S>В контексте wf пример взял отсюда, чего компилятор тут подсветит:

S>
S>  Binding b = new Binding("Text", ds, "customers.custToOrders.OrderAmount")
S>

S>?
При чем тут виндовс формы? Речь не о них была.
Re[21]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.02.23 11:13
Оценка:
Здравствуйте, rollcoin, Вы писали:
S>>Ну через CEF конечно можно, что угодно

R>Речь была про многопотность в Электроне, которую ты сам же поднял.

R>Электрон это и есть CEF.
Не в электроне, а в JS. А ты поднял проблему про рантайм.
Я к тому, что использовать JS для саервера, так себе решение. Лучше использовать языки которые ближе к ОС.

У JS (TS) область применения конечно фронт и кроссплатформенный десктоп.
Но вот Блазор вполне себе конкурент и для фронта и для десктопа.
И фронт оооочень долго эволюционирует. И если другие языки эволюционируют, и появляются новые, то JS сильно отстает.
Да и та же разметка.
Вот по сути, что я и хотел сказать.
и солнце б утром не вставало, когда бы не было меня
Re[5]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Flying Dutchman Украина  
Дата: 13.02.23 12:56
Оценка:
Здравствуйте, so5team, Вы писали:


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


S>Тогда как прикладные программисты, которые педалят скучную бизнес-логику, писать обобщенный код особо негде. Поэтому от наличия или отсутствия генериков/шаблонов в языке прикладному программисту, которому нужно написать чтение очередной порции данных из БД и отдать куда-то в JSON-е, ни тепло, ни холодно.


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

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

Я был занят написанием программы, которая на основе данных из БД формирует сообщения в формате XML в соответствии со стандартом STuF для обмена данными с другими системами.

STuF — это голландский правительственный стандарт для создания сообщений в XML-формате для разных предметных областей: юридической, недвижимости и т.д. Часть стандарта, которая описывает объекты недвижимости, имеет объем около 600 страниц и в ней описаны сотни XML-элементов. Стандарт довольно сложен и описывает в том числе темпоральные данные (например, история объекта недвижимости).

Когда я пришел на проект, была уже написана первая версия этой программы. Я полностью переписал ее, применив по-умному генерики. В результате мне удалось уменьшить размер кода в 20-25 раз.

Да, одна голландская компания (конкурент той, в которой работал) потратила на решение той же задачи (обмен сообщениями об объектах недвижимости в формате STuF) несколько сот тысяч евро.
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.02.23 13:12
Оценка:
Здравствуйте, Flying Dutchman, Вы писали:

FD>Когда я пришел на проект, была уже написана первая версия этой программы. Я полностью переписал ее, применив по-умному генерики. В результате мне удалось уменьшить размер кода в 20-25 раз.


А ты, опасный!
Re[2]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.02.23 13:21
Оценка:
Здравствуйте, fk0, Вы писали:

fk0> Все парадигмы программирования применимые в других ЯВУ можно применить и в C. Кроме лямбда-функций и перегруженных функций.


А еще генерики-темплейты, например, сборка мусора и тд. А так же те, которые вплотную завязаны на всё это, то есть, вычеркиваем ФП, ООП, обобщенное программирование и много чего еще

fk0>Но будет крайне неудобном, будет нечитаемый код и т.д. и т.п.


Теоретически, вообще всё можно на си написать, как это будет выглядеть, можно глянуть, если какой хаскел или что навроде скомпилировать в си.
Интересует как раз такой код, который можно будет поддерживать с разумными издержками и бенефитами.
Отредактировано 13.02.2023 15:45 Pauel . Предыдущая версия .
Re[6]: Синтаксический сахар vs реально полезные вещи в ЯП
От: so5team https://stiffstream.com
Дата: 13.02.23 14:38
Оценка:
Здравствуйте, Flying Dutchman, Вы писали:

FD>STuF — это голландский правительственный стандарт для создания сообщений в XML-формате для разных предметных областей: юридической, недвижимости и т.д. Часть стандарта, которая описывает объекты недвижимости, имеет объем около 600 страниц и в ней описаны сотни XML-элементов. Стандарт довольно сложен и описывает в том числе темпоральные данные (например, история объекта недвижимости).


Несколько раз доводилось слышать о ситуациях, подобных вашей, в которых применяли кодогенерацию. В одном из случаев сделали генератор, которому скармливалась спецификация сообщений прямо из стандарта (тупой копипастой), а на выходе получался набор классов для работы с этими сообщениями.
Re[7]: Синтаксический сахар vs реально полезные вещи в ЯП
От: Flying Dutchman Украина  
Дата: 13.02.23 16:58
Оценка:
Здравствуйте, so5team, Вы писали:

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


Кодогенерацию мы в этом проекте использовали. А именно, на основе схем (XSD-файлов), которые были частью стандарта STuF, были сгенерированы C#-классы. Это было сделано при помощи программы xsd.exe, которая является частью Microsoft SDK.

После этого для генерации XML достаточно создать соответствующий C#-объект, а его уже потом можно автоматически сериализовать в XML (обратное тоже возможно: автоматически десериализовать XML-файл в C#-объект).

(без этой кодогенерации все было бы вообще грустно)

По сути дела, я напрямую с XML вообще не работал. Генерики же я применял для создания этих C#-объектов, которые сами по себе имели сложную структуру.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.