Даже не знаю, то ли у вас тогда спросить «как вы тройное резервирование в исходном коде делать предлагаете?», то ли предложить попробовать глючность программы по количеству опкодов в .exe считать.
Ну если в маразм впадать, то да, можно и опкоды считать.
А вообще люди придумали кластеры, рейд массивы, зоопарки всякие, облака с динамическим масштабированием — это всё примеры параллелизации вашего кода с целью повышения надёжности.
Ну, и банальный
retry 5 (fun () -> saveOnDisk ())
в коде, где saveOnDisk может завалиться с ненулевой вероятностью.
А почему вы думаете что элементы те же самые? Напомню, изначально как раз и шла речь о разных объемах кода на разных языках
Согласен, эту цитату я упустил.
Что не отменяет того что принцип работает. Применение его к очень маленьким элементам (вроде одной строки кода) под вопросом.
Нет, совсем не главное. Сравните что меньше: 1 — 0,93 или 1 — 0,995?
Условия разные, в одном случае 5 в 10 раз более надёжных элементов, а в другом 3 очень ненадёжных.
Очевидно же, что говорить о снижении надёжности системы с увеличением кол-ва элементов в ней можно только при прочих равных условиях, а именно что элементы те же самые.
Аналогия: Как сравнить надёжность 3х строк на C# и 100 строках на asm?
Я думаю надо сравнивать 3 строки на C# и 100 строк на C#
Инженерия делает проще.
Берём тысячу плат и тестируем час. Отказало 2 из 1000? Эмпирическая вероятность отказа одной платы (как целого объекта) в течении часа — 0.2% (а надёжность — 99.8%)
Повторяем с прочими элементами, считаем суммарную надёжность.
С программными продуктами можно сделать похоже.
Выкатываем web application, нагружаем час, считаем кол-во out of service, service deny, timeout, 502 и пр. на общее кол-во запросов.
Абстрактно всё то же самое, программирование та же инженерия.
Правило "Чем больше объектов в группе, тем ниже надежность всей группы" работает только при постоянной вероятности отказа объекта.
Я думаю в этом случае только подсчёт вероятности отказа сложнее — через цепи Маркова (редирект на пдф). Придётся мучаться либо с интегралами по времени, либо измерять вероятность отказа в определённом состоянии (с учётом того как объект попал в это состояние).
Интуитивно должно работать так же: сложнее система (больше последовательных элементов) — надёжность меньше. Дублирование системы (больше параллельных элементов) — повышает надёжность.
Когда вы свой продукт деплоите в 4 инстанса — вы параллельно их соединяете. Повышаете надёжность.
Когда вы пишете код — вы последовательно соединяете блоки — с каждой новой строчкой надёжность падает, даже если вероятность отказа каждой конкретной строчки (бредово, но допустим) равна 0.999999999999999
Вероятность безотказной работы группы объектов равна произведению вероятностей безотказной работы каждого объекта в этой группе.
Чем больше объектов в группе, тем ниже надежность всей группы
На этих самых ваших каналах простейшая задача вида «отменить асинхронную операцию» превращается в такую кашу…
потому что в Go нет примитива синхронизации со встроенным NACK…
Это в огород гошников, что у них самый лучший язык в мире, а там только базовые ченелы завезли, остальное надо руками делать
Ответ ещё страннее, учитывая что GET запросом можно точно так же body передавать.
Это считается антипаттерном и некоторые REST-клиенты (постман вроде) не разрешают body в GET, но тем не менее разница между GET и POST вкладывается человеком, а никак не протоколом.
Работает по смыслу примерно так же как и .ToList() (создаём небольшой контейнер, если не помещается, ресайзим в геометрической прогрессии), поэтому проблем с возвратом массивов из методов нет.
Если не трудно, опишите как выглядит описание потока в теории Категорий
Попробую в силу понимания. Теория категорий супер абстрактна, поэтому конкретное определение "объекта" и "стрелочки" будет зависеть от места приложения.
Любой объект можно наделить функцией. Например, зная те потоки, которые исчезают в теле объекта, и те потоки, которые образуются в нем, мы можем сказать, что функция объекта — преобразование входящих потоков в выходящие (например, у зеркала функция отражать падающий свет).
Объект — некое A.
Потоки объекта A — множество всех морфизмов вида (A -> *) или (* -> A). Т.е. именно те стрелочки, которые не замкнуты относительно A.
Мы можем наделить объект функцией быть самим собой.
Это морфизмы вида (A -> A). Они могут менять состояние объекта или нет (тогда это так называемый тождественный морфизм, уникальный для объекта). Само состояние объекта нас не интересует.
И тогда функция объекта — это поток его состояний (например, функция картины демонстрировать себя). Правда, при этом мы учитываем не все потоки и не все состояния, а только те из них, которые либо желанны, либо необходимы с нашей точки зрения, например, для объяснения причин их возникновения.
Функция объекта в Вашем понимании — это все возможные состояния объекта и переходы между ними. На языке категорий это просто Hom(A,A) — множество всех морфизмов из A в A, включая композиции для быстрого перехода между состояниями (родился -> умер).
И нечего писать, что с++ плох, просто вы х*евый кодер
Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?
Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.
Есть одна область знаний (назовём её Теория Категорий), которая изучает объекты и "стрелочки" между ними… :)
Читая статью, не мог отогнать от себя мысль, что это попытка её пересказать на языке менеджеров.
Это просто незнание "законов". А в терминах ТАУ — этот блок всего лишь система с отрицательной обратной связью.
Added: я не призываю считать надёжность каждой строчки.
Ну если в маразм впадать, то да, можно и опкоды считать.
А вообще люди придумали кластеры, рейд массивы, зоопарки всякие, облака с динамическим масштабированием — это всё примеры параллелизации вашего кода с целью повышения надёжности.
Ну, и банальный
в коде, где
saveOnDiskможет завалиться с ненулевой вероятностью.Согласен, эту цитату я упустил.
Что не отменяет того что принцип работает. Применение его к очень маленьким элементам (вроде одной строки кода) под вопросом.
Условия разные, в одном случае 5 в 10 раз более надёжных элементов, а в другом 3 очень ненадёжных.
Очевидно же, что говорить о снижении надёжности системы с увеличением кол-ва элементов в ней можно только при прочих равных условиях, а именно что элементы те же самые.
Аналогия: Как сравнить надёжность 3х строк на C# и 100 строках на asm?
Я думаю надо сравнивать 3 строки на C# и 100 строк на C#
Инженерия делает проще.
Берём тысячу плат и тестируем час. Отказало 2 из 1000? Эмпирическая вероятность отказа одной платы (как целого объекта) в течении часа — 0.2% (а надёжность — 99.8%)
Повторяем с прочими элементами, считаем суммарную надёжность.
С программными продуктами можно сделать похоже.
Выкатываем web application, нагружаем час, считаем кол-во out of service, service deny, timeout, 502 и пр. на общее кол-во запросов.
Абстрактно всё то же самое, программирование та же инженерия.
Я думаю в этом случае только подсчёт вероятности отказа сложнее — через цепи Маркова (редирект на пдф). Придётся мучаться либо с интегралами по времени, либо измерять вероятность отказа в определённом состоянии (с учётом того как объект попал в это состояние).
Интуитивно должно работать так же: сложнее система (больше последовательных элементов) — надёжность меньше. Дублирование системы (больше параллельных элементов) — повышает надёжность.
Потому что это всего лишь пример. Я ещё считаю что строчек кода всего 5, это не смутило?
По ссылке в книге полная формула приведена для общего случая.
Так это разное. Блоки кода — последовательно соединенные элементы, каждый со своей вероятностью отказа.
P — вероятность отказа системы. p — вероятность отказа узла системы. n — кол-во узлов
Последовательное соединение узлов: P=p^n
Параллельное: P=1-(1-p)^n
Для p=0,99 n = 5,
P последовательного ~= 0.95
P параллельного = 0,9999999999
Последовательное соединение теряет надёжность. Параллельное — приобретает.
http://lib.alnam.ru/book_rdm.php?id=204
Когда вы свой продукт деплоите в 4 инстанса — вы параллельно их соединяете. Повышаете надёжность.
Когда вы пишете код — вы последовательно соединяете блоки — с каждой новой строчкой надёжность падает, даже если вероятность отказа каждой конкретной строчки (бредово, но допустим) равна 0.999999999999999
Ну, ГОСТ 27.002—89 и https://ru.wikipedia.org/wiki/Вероятность_безотказной_работы
Для кода тоже работает.
потому что в Go нет примитива синхронизации со встроенным NACK…
Это в огород гошников, что у них самый лучший язык в мире, а там только базовые ченелы завезли, остальное надо руками делать
Я думаю это Serverless Computing. То есть Azure Functions или AWS Lambda
Ответ ещё страннее, учитывая что GET запросом можно точно так же body передавать.
Это считается антипаттерном и некоторые REST-клиенты (постман вроде) не разрешают body в GET, но тем не менее разница между GET и POST вкладывается человеком, а никак не протоколом.
"Состояние типов" очень уж напоминает обыкновенный union type, а Result<T,Error> с оператором? — монаду maybe
Или я не так понял?
.ToArray()из Linq, который работает черезstruct LargeArrayBuilderРаботает по смыслу примерно так же как и
.ToList()(создаём небольшой контейнер, если не помещается, ресайзим в геометрической прогрессии), поэтому проблем с возвратом массивов из методов нет.T[]будет чуть-чуть полегковеснее. АImmutableArray<T>вообще struct.Так что
List<T>явно не победительВ C# он слабо контролируемый, т.к. он может отключаться JIT-ом.
Если совсем невмоготу, включаем unsafe и поинтерами тычем в элементы массива.
Про Java не знаю, но подозреваю что ситуация похожая.
Попробую в силу понимания. Теория категорий супер абстрактна, поэтому конкретное определение "объекта" и "стрелочки" будет зависеть от места приложения.
Объект — некое
A.Потоки объекта
A— множество всех морфизмов вида(A -> *)или(* -> A). Т.е. именно те стрелочки, которые не замкнуты относительноA.Это морфизмы вида
(A -> A). Они могут менять состояние объекта или нет (тогда это так называемый тождественный морфизм, уникальный для объекта). Само состояние объекта нас не интересует.Функция объекта в Вашем понимании — это все возможные состояния объекта и переходы между ними. На языке категорий это просто
Hom(A,A)— множество всех морфизмов изAвA, включая композиции для быстрого перехода между состояниями (родился -> умер).Интересно зачем автору надо быть хорошим кодером, если ему надо быть хорошим учёным?
Я читаю комментарии и поражаюсь сколько негатива льётся на автора за то что он (внимание, аналогия) отказался от болида формулы-1 и взял рено логан просто чтобы ездить на работу.
Я считаю что автор поступил рационально.
Есть одна область знаний (назовём её Теория Категорий), которая изучает объекты и "стрелочки" между ними… :)
Читая статью, не мог отогнать от себя мысль, что это попытка её пересказать на языке менеджеров.
Пример на F# (но синтаксис у ML подобных языков очень похож)
Глобально объявленный оператор сложения, два значения и результат:
объявлять класс не нужно. идентификаторы
a,b,cи оператор(+)будут доступны всем желающим.