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

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

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

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

Здравствуйте, 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>?
При чем тут виндовс формы? Речь не о них была.

Здравствуйте, rollcoin, Вы писали:
S>>Ну через CEF конечно можно, что угодно

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

У JS (TS) область применения конечно фронт и кроссплатформенный десктоп.
Но вот Блазор вполне себе конкурент и для фронта и для десктопа.
И фронт оооочень долго эволюционирует. И если другие языки эволюционируют, и появляются новые, то JS сильно отстает.
Да и та же разметка.
Вот по сути, что я и хотел сказать.

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

S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.
S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.

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


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

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

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

В C# не шаблоны, а кривая паделка студентов. Шаблоны в C++.

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


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

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

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

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

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

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

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

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

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

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

А ты, опасный!

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

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

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

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

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

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

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

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

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

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

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

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

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

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