Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…
Это понятно, да. Но возникают сложности, если, к примеру, подписка меняется динамически.
Делать очередь - тоже такое себе. Или она должна быть конечной, и тогда в какой-то момент она всё равно должна начать терять. Или бесконечной, но тогда она может выжрать всю память. Или блокировать отправителя, но есть риск навсегда его заблокировать.
Есть интересный паттерн, я применял его несколько раз в разных проектах.
Представим себе, что есть некоторое состояние, и смысл потока событий уведомить заинтересованных получателей в изменении этого состояния.
Если допустить, что нам достаточно, чтобы состояние с точки зрения отправителя и с точки зрения получателей достаточно, чтобы было eventually consistent, то на стороне отправителя можно хранить его представление о состоянии получателей и присылать только обновления.
Сложность тут растет пропорционально числу подписчиков и нет очереди, которая может переполниться.
Как частный случай, отправитель может просто уведомлять заинтересованные лица, что состояние изменилось, а они могут перечитывать его целиком. Очередь сообщений тут тоже не нужна, нет разницы, сколько таких уведомлений получит получатель, лишь бы последнее получил.
Ну и ничего из перечисленного не является какой-то специфической особенностью именно вот функционального стиля.
Обработка ошибок путём явного возврата их по значению в Rust-е вообще из Go, а в Go из Alef, его прямого предшественника от тег же авторов. А Alef - это диалект Си. Вот уж никогда никто не назвал бы его функциональным языком.
А что до неприменимости ФП для системного программирования, и тут бы я тоже поспорил. Системное программирование - это отнюдь не только про перекладывание байтов из регистра в регистр. Более того, критический, в плане производительности, путь - это процентов 10 общего кода. А остальное - код логически сложный, но без особых притязаний в плане производительности. И писать его в стиле “выжимаем каждый такт из каждого байта” нет никакой необходимости. Скорее, его надо ментально упрощать, пусть даже и за счёт некоторых потерь в скорострельности, потому, что логические ошибки в этом коде слишком дорого обходятся.
Бить током от ноута - кто-то может пояснить КАК? Если от БП идет 110 (220), на разве в цепях питания не будет пробоя?
Очень просто.
Представим себе, от БП должны идти условные 19в. Т.е., в одном проводе 0, в другом +19.
А теперь представим, что из-за пробоя в одном проводе идёт 0 + 110 переменного тока, в другом - 19 + 110 того же переменного тока.
С точки зрения самого ноута ничего не изменилось, как было 19в между входными проводами питания, так и осталось.
Но только вот теперь дополнительно появилось 110в переменного тока на корпусе. Ноуту это не заметно, а вот человеку, который может касаться рукой металлического корпуса а ногой - чего-нибудь заземленного, вломит по полной программе.
Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…
Это понятно, да. Но возникают сложности, если, к примеру, подписка меняется динамически.
Делать очередь - тоже такое себе. Или она должна быть конечной, и тогда в какой-то момент она всё равно должна начать терять. Или бесконечной, но тогда она может выжрать всю память. Или блокировать отправителя, но есть риск навсегда его заблокировать.
Есть интересный паттерн, я применял его несколько раз в разных проектах.
Представим себе, что есть некоторое состояние, и смысл потока событий уведомить заинтересованных получателей в изменении этого состояния.
Если допустить, что нам достаточно, чтобы состояние с точки зрения отправителя и с точки зрения получателей достаточно, чтобы было eventually consistent, то на стороне отправителя можно хранить его представление о состоянии получателей и присылать только обновления.
Сложность тут растет пропорционально числу подписчиков и нет очереди, которая может переполниться.
Как частный случай, отправитель может просто уведомлять заинтересованные лица, что состояние изменилось, а они могут перечитывать его целиком. Очередь сообщений тут тоже не нужна, нет разницы, сколько таких уведомлений получит получатель, лишь бы последнее получил.
А ещё то, что поздноподписавшиеся могут пропустить что-то интересное, что случилось до их прихода
В итоге, такая реализация накладывает определенные ограничения на порядок инициализации, вводя неочевидные зависимости.
В системе с большим количеством компонент это может больно стукнуть в какой-то момент
Да действительно, куда уж им. То ли дела RedHat, представитель высшей цивилизации…
P.S. Содержательно, для меня этот вопрос сводится к тому, отдаёт Астра свои правки в апстрим или не отдаёт.
Я не очень понял, а модель обучалась на этих текстах, которые она так ловко сжимает? Или она обучалась на одних текстах, а сжимает другие?
А RedHat тоже пилит тестирование чужого опенсорса?
Ну и ничего из перечисленного не является какой-то специфической особенностью именно вот функционального стиля.
Обработка ошибок путём явного возврата их по значению в Rust-е вообще из Go, а в Go из Alef, его прямого предшественника от тег же авторов. А Alef - это диалект Си. Вот уж никогда никто не назвал бы его функциональным языком.
А что до неприменимости ФП для системного программирования, и тут бы я тоже поспорил. Системное программирование - это отнюдь не только про перекладывание байтов из регистра в регистр. Более того, критический, в плане производительности, путь - это процентов 10 общего кода. А остальное - код логически сложный, но без особых притязаний в плане производительности. И писать его в стиле “выжимаем каждый такт из каждого байта” нет никакой необходимости. Скорее, его надо ментально упрощать, пусть даже и за счёт некоторых потерь в скорострельности, потому, что логические ошибки в этом коде слишком дорого обходятся.
В каком смысле паразитирует?
Ну щазз!
Смертельной опасности во всей этой конструкции подвергался только я. Меня могли запросто уронить в суматохе и прикожить головой об асфальт.
Я за год спас от своего пёсика десяток котиков, дюжину белок и одну лисицу, которая проживает без прописки в обычном московском дворике.
Так что думаю, свою норму зооблаготворительности я уже выполнил :)
Вот это слово я и хотел узнать. Thanks!
Как же мне её искать в гугле, если тут нет ни названия, ни бренда, ничего?
А если меня эта тётка заинтересовала, и продукция её тоже, можно как-то ссылку на сайт узнать или что-нибудь в этом роде?
Очень просто.
Представим себе, от БП должны идти условные 19в. Т.е., в одном проводе 0, в другом +19.
А теперь представим, что из-за пробоя в одном проводе идёт 0 + 110 переменного тока, в другом - 19 + 110 того же переменного тока.
С точки зрения самого ноута ничего не изменилось, как было 19в между входными проводами питания, так и осталось.
Но только вот теперь дополнительно появилось 110в переменного тока на корпусе. Ноуту это не заметно, а вот человеку, который может касаться рукой металлического корпуса а ногой - чего-нибудь заземленного, вломит по полной программе.
С этим лучше не шутить.
Кому как :)
Я сам начинал с железок всяческих, но постепенно пришёл к чистому программированию
А программа ещё приятнее.
“Банан велик, но кожура - больше”?
RedHat аутсорсит не экспертизу, а ответственность
Заметим, эта ниша занята. Там даже Canonical места не хватило. Canonical пытается создать магазин приложений и стать его оператором
Ну, мальчиком по вызову много не заработаешь.
Это игра где-то в той же лиге, что и всякие там установщики венды…