Здравствуйте, SkyDance, Вы писали:
S>> Тот же lock{} (Monitor) очень удобен. А учитывая, что как правило есть пул потоков, то что и чем им обмениваться?
SD>Им нужно обмениваться сообщениями (а не "локами" и прочими абстракциями которые не могут работать в распределенных системах).
Еще раз какой обмен сообщениями в пуле потоков?
Многие используют БД и прочие медленные абстракции с обменом сообщений между процессами.
Можно еще придумать кучу как все замедлить.
Кстати в тех же распределенных системах присутствуют Redis
Redis — это база данных, размещаемая в памяти, которая используется, в основном, в роли кеша, находящегося перед другой, «настоящей» базой данных, вроде MySQL или PostgreSQL. Кеш, основанный на Redis, помогает улучшить производительность приложений. Он эффективно использует скорость работы с данными, характерную для памяти, и смягчает нагрузку центральной базы данных приложения, связанную с обработкой следующих данных:
Данные, которые редко меняются, к которым часто обращается приложение.
Данные, не относящиеся к критически важным, которые часто меняются.
Здравствуйте, 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 реально полезные вещи в ЯП
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>Если речь про анонимные типы, то да, св-ва помогают, но можно ведь и public fields. Иначе S>на каждый чих заводить соотв. тип\класс.
Ну так если не анонимный тим, то как должно работать? заставлять выставлять филды наружу?
S>Блин, также, только там где стоит св-во, исп. соотв. метод. Как в яве-то это делается?
Никакой типизиации при компиляции. К строковым именам добавляются get_ и set_ префиксы чтобы найти методы.
S>Не знаток Blazor, но в winforms если я исп. класс binding, он может во время исп. стрельнуть, что S>нету какого-нибудь сеттера.
Может. А может при компиляции подсветить ошибку, что типы не совпадают.
Re[9]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, SkyDance, Вы писали:
G>>Ага, а спустя 5 лет таки добавили генерики. Что поменялось?
SD>У разработчиков появилось время на реализацию. Никакой магии
То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?
Это, конечно, очень повышает доверие к разработчикам языка
Re[10]: Синтаксический сахар vs реально полезные вещи в ЯП
G>То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?
Рассказы — это уже специфика группировок. Есть поддержка и первого варианта ("генерики не нужны"), и второго ("нужны"). Оба мнения имеют право на жизнь, есть обоснования и для того, и для другого.
G>Это, конечно, очень повышает доверие к разработчикам языка
А это вообще могут быть люди, не входящие ни в одну из перечисленых выше группировок
Любой "design by committee" противоречив по определению.
Re[11]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, SkyDance, Вы писали:
G>>То есть все рассказы что "генерики не нужны" это просто оправдание из-за того, что не хватило времени сделать генерики и вам выпаривают сырой продукт?
SD>Рассказы — это уже специфика группировок. Есть поддержка и первого варианта ("генерики не нужны"), и второго ("нужны"). Оба мнения имеют право на жизнь, есть обоснования и для того, и для другого.
Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны. И ФП тоже нужно.
G>>Это, конечно, очень повышает доверие к разработчикам языка SD>А это вообще могут быть люди, не входящие ни в одну из перечисленых выше группировок SD>Любой "design by committee" противоречив по определению.
Честно, не понимаю.
Сначала комитет постановил что "генерики не нужны", потом постановил что нужны.
Что изменилось за это время?
Re[14]: Синтаксический сахар vs реально полезные вещи в ЯП
S>>>А как у JS с многопоточностью?
vsb>>Многопоточность это про рантайм, а не про язык. Ну я рантаймов JS без многопоточности не знаю, вроде везде есть. Хотя не знаю, зачем она нужна. Пока ни разу не было нужды в ней. S> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры. S> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/
И чем же фьютексы вам — это не объекты синхронизации, а костыли?
Atomic API — это фьютексы.
S> Если их в языке нет нет понятия потока?
Вы не найдете в стандарте языка Си понятие потока.
Поток — это сущность рантайма. Для Си — рантайм это операционная система. Для js — это движки жс.
Все мейнстрим движки жс имеют потоки.
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
G>Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны. И ФП тоже нужно.
ФП — согласен.
А вот что до генериков, это уже не столь очевидный вопрос. Как и в случае с любой другой опциональной фичей. Это всегда очень легко, добавлять фичи. Это почти всегда громко приветствуется, типа "урааа, теперь еще поддерживается и вот это". Поэтому почти всегда в сражении "добавить сложности vs оставить простым" рано или поздно выигрывает группировка №1. Та что "ну мы же ничего не ломаем, только добавляем новую фичу".
Ровно поэтому любое популярное приложение превращается в Outlook убер-апп, всемогутор. Грааль, так сказать. Бери что угодно, не ошибешься. От WeChat до Telegram. От C++ до, простите, JS.
G>Сначала комитет постановил что "генерики не нужны", потом постановил что нужны. G>Что изменилось за это время?
Сам комитет изменился. И распределение сил в нем. Нет уже того сильного лидера, который остановил бы раковый рост сложности и охват ниш все меньшего и меньшего размера.
См. аналогичный пример с Apple, и происходящий сейчас процесс разрастания продуктовых линеек. Сегментирование на все больше и больше кусочков рынка. Вместо созидания — просто охват "еще вот этой категории". Иными словами, кризис идей (наблюдается по всей индустрии, надо отметить). Нет у них больше Джобса с манда-том
Что будет дальше? На примере С++ видно, что дальше будет появление чего-то менее развесистого и backwards compatible, без половины фич старого языка, но зато куда более простое в освоении и использовании. Ну, скажем, Rust. Который тоже начнет разрастаться (если еще не), до тех пор пока не увязнет в собственном наследии. И далее по кругу.
Здравствуйте, Sharov, Вы писали:
S>>Ada, Eiffel, Rust, D.
S>Ну кто его кроме Мейера и в исследовательских целях использует?
Как я понимаю, его продолжают использовать крупные компании, которые выбрали Eiffel еще в 1980-х и 1990-х (насколько помню, это транспорт, энергетика, европейская военка).
Тут же еще примечательно, что Eiffel разрабатывается небольшой фирмой EiffelSoftware, которая с этого продукта и живет (продажи EiffelStudio, консалтинг, обучение). Если бы Eiffel не использовался, то они бы не выжили бы, а так все еще существуют и выдают, минимум, по одному большому релизу EiffelStudio в год.
Re[12]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, gandjustas, Вы писали:
G>Ну в целом история развития ЯП за последние 20 лет показывает что генерики нужны.
За последние 40. Ada -- это 1983-й год. И это стал, пожалуй, первый широко применявшийся язык со статической типизацией и поддержкой обобщенного программирования. Шаблоны в C++ через 7 лет появились под сильным влиянием Ada.
И это я еще не знаю историю развития функциональных языков. Не удивлюсь, если в какой-нибудь Miranda обобщенное программирование уже было в 1980-х.
Re[15]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, rollcoin, Вы писали:
S>> Если их в языке нет нет понятия потока? R>Вы не найдете в стандарте языка Си понятие потока. R>Поток — это сущность рантайма. Для Си — рантайм это операционная система. Для js — это движки жс. R>Все мейнстрим движки жс имеют потоки.
Я не знаток дж движков, но https://stackoverflow.com/questions/59630103/using-worker-thread-in-electron
и солнце б утром не вставало, когда бы не было меня
Re[16]: Синтаксический сахар vs реально полезные вещи в ЯП
Здравствуйте, 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 реально полезные вещи в ЯП
R>А чтобы в них был доступен API ноды (в электроне два слоя апи — web и нодовское, потому как элетктрон это — CEF в котором ванильный v8 заменили на v8 из ноды с его апи сбоку). Так вот чтобы в обычных СТАНДАРТНЫХ воркерах, которые стандартиированны коммитетом, в электроне, стали достпуны нодовские апи, надо выставить флаг при создании процесса (nodeIntegrationInWorker: true).
R>Нодовские воркеры в электроне не нужны, потому что в электроне внезапно есть нативные обычные веб воркреры.
R>Все работает. Я на электроне 8 лет пишут. А твой вопрос на SO — типичная ситуация о том, что хочу того, чего мне на самом деле не нужно, а манулы читать не буду.
Здравствуйте, 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 реально полезные вещи в ЯП
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, Вы писали:
S>> Если их в языке нет нет понятия потока? R>Вы не найдете в стандарте языка Си понятие потока.
"Да что ж вы такое несёте то". ([rollcoin@])
Рекомендую просветиться.
S>> Нееее. Нужны объекты синхронизации такие как мьютексы, мониторы, эвенты, семафоры. S>> Конечно есть какие то костыли https://habr.com/ru/company/ruvds/blog/522952/ R>И чем же фьютексы вам — это не объекты синхронизации, а костыли?
А при чём тут вообще фьютексы к этой статье? Что там под капотом, для неё не важно.
R>Atomic API — это фьютексы.
