Я так скажу - если кто-то на форуме рыбаков будет рассуждать о влиянии цены лески на нюансы вкуса карася, реакция будет примерно такой же, как и на аудиофилов.
А что если вам нужно две библиотеки, libabc и libdef, при этом разработчикам libabc хватает libfoo версии 1.6, а разработчики libdef перешли на libfoo версии 1.9 , и эти версии несовместимы?
Просто представьте себе сценарий - вы исправляете уязвимость в какой-то общей библиотеке. Как вам а) убедиться, что этот фикс не вызывает новых проблем в других проектах; б) доставить этот фикс на другие проекты (и не когда-нибудь, а поскорее).
Поищите, в Гугл не раз рассказывали, почему у них монорепа и чем это для них хорошо.
Гораздо меньше возни с зависимостями, исправление багов в библиотеках сразу распространяется на все проекты, но если где-то в другом проекте что-то сломали, то автотесты это сразу покажут и так далее.
Подход хороший, но должно соблюдаться много условий для этого.
А почему вы думаете, что в фразе "истинный ГСЧ" истинный относится к генератору, а не к числам? :)
Русский язык штука такая - в нем понятно, что к чему относится.
Абстрагируясь, это можно рассматривать как функцию, которая выдает всегда не детерминированные данные и в принципе не может быть чистой.
Функция чтения данных с мыши/клавиатуры точно такая же нечистая. Абстрагироваться надо по-другому - ГСЧ это устройство ввода данных в программу, не более того. И исходное утверждение, что при одних и тех же входных данных программы выдают один и тот же результат остается верным.
Девайс не живет в вакууме, но для программ это всего лишь устройство ввода, и детерменированность алгоритмов никуда не исчезает. ГСЧ - это источник входных данных для других алгоритмов, не более того.
То, что вы называете "истинным ГСЧ" - это в первую очередь аппаратный датчик истинно случайных процессов. Алгоритмов генерации истинных случайных чисел не существует.
Square вполне себе является Rectangle, и если его сделать иммутабельным (ну хотя бы не давать менять ему размер), то можно и LSP соблюсти.
Always has been
По дороге видно. До исправления освещена левая часть дороги, после исправления - правая.
Открыл обе картинки в новых вкладках, переключаюсь между ними - разница заметная.
Но вот когда они рядом на странице - видно очень плохо ;)
А какой общественный вред от езды с непристегнутыми ремнями? От езды на мотоцикле без шлема?
Ближайшая и ярчайшая - после Млечного пути.
Я так скажу - если кто-то на форуме рыбаков будет рассуждать о влиянии цены лески на нюансы вкуса карася, реакция будет примерно такой же, как и на аудиофилов.
Сравнивать аудиофилов с вечно брешущими рыбаками - это мне нравится, это красиво.
-- Я в Волге выловил белую акулу!
-- Брешешь, они там не водятся!
-- У кого руки есть, тот ловит, только блесна нужна золотая, с графеновой леской.
Пофиг. Пока он не начинает рассказывать, что отличает на слух японских девственниц от китайских.
Из того, что libfoo разрабатывается кем-то в нашей же компании и всегда лежит рядышком в монорепе.
В монорепе не будет такой ситуации, ведь libfoo всегда и у всех одной версии. Для того монорепу и заводят.
А что если вам нужно две библиотеки, libabc и libdef, при этом разработчикам libabc хватает libfoo версии 1.6, а разработчики libdef перешли на libfoo версии 1.9 , и эти версии несовместимы?
Нет, в git коммит не принадлежит ветке.
...а во второй не стали обновлять зависимость, потому что и так все работает. Уязвимость? Производительность? Неважно.
Или хуже - не обновляют, потому что фиксили один баг, внесли другой, и теперь второй проект обновить нельзя.
git submodule update обновляет зависимости моего проекта. Мне нужно выкатить в другие, о которых я не знаю.
Ни капельки.
Просто представьте себе сценарий - вы исправляете уязвимость в какой-то общей библиотеке. Как вам а) убедиться, что этот фикс не вызывает новых проблем в других проектах; б) доставить этот фикс на другие проекты (и не когда-нибудь, а поскорее).
Поищите, в Гугл не раз рассказывали, почему у них монорепа и чем это для них хорошо.
Гораздо меньше возни с зависимостями, исправление багов в библиотеках сразу распространяется на все проекты, но если где-то в другом проекте что-то сломали, то автотесты это сразу покажут и так далее.
Подход хороший, но должно соблюдаться много условий для этого.
Русский язык штука такая - в нем понятно, что к чему относится.
Функция чтения данных с мыши/клавиатуры точно такая же нечистая. Абстрагироваться надо по-другому - ГСЧ это устройство ввода данных в программу, не более того. И исходное утверждение, что при одних и тех же входных данных программы выдают один и тот же результат остается верным.
true - относится к number, а не к generator
Девайс не живет в вакууме, но для программ это всего лишь устройство ввода, и детерменированность алгоритмов никуда не исчезает. ГСЧ - это источник входных данных для других алгоритмов, не более того.
true random number generator - это не истинный ГСЧ, это генератор истинно случайных чисел. И это не алгоритм, а девайс )
То, что вы называете "истинным ГСЧ" - это в первую очередь аппаратный датчик истинно случайных процессов. Алгоритмов генерации истинных случайных чисел не существует.