DG>>которые не имеет запаса прочности вообще, и любая малейшая ошибка может привести к произвольным катастрофическим последствиям.

S>а Вы не могли бы по подробнее?..

запас прочности можно рассматривать как минимизацию функции F, где F — это функция ухудшение работоспособности системы от сбоя (или изменения условий эксплуатации) отдельной части системы.
соответственно, для машины ожидается, что неисправность лампочки или прокол колеса не приводят к разносу двигателя.
для программы на C/C++ такого ожидания гарантировать нельзя, малейшая ошибка в самом некритическом коде может привести к "проезду по памяти" и отказу любого другого узла (сколько угодно критического), находящегося в той же самой памяти.
частично это проблема решается разнесением по отдельным процессам, что часто делается в nix-программах, но это имеет естественный предел: узлы можно разнести по 2-10 процессам(максимум тысячу), но миллион узлов уже друг от друга таким подходом не разнесешь.

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


Тише... Тише... Никому не рассказывай, что можно вообще не делать ошибок. Потому что для того чтобы не делать ошибок нужно реально решать NP-полные задачи. А человек этого сделать не может по определению. А значит это будут машины. А если они решают NP полные задачи, значит они же могут их и ставить, что в свою очередь NP полная задача. И любой холодильник или стиральная машина будет плевать в тебя машинным маслом: "Тупая органика". И любой пылесос тебе скажет: "убери за мной, тряпка недоразвитая". И сгинет человечество, как промежуточный этап эволюции, уже ненужный никому, и отслуживший своё. Так что, программист помни. Делая ошибки ты стоишь на страже человечества.

HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число?

Есть такое, гуглите по словам "defensive development".

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

HH>Хорошо, давайте говорить только о том классе ошибок, которые можно отловить, создав математическую модель и т.д. Ошибки, которые для своего разрешения требуют йогических практик, впадения в нирвану, и непосредственного созерцания Божественной Истины, рассматривать не будем.

Тогда мы автоматически исключаем те ошибки, которые будут связаны с неправильно выбранной математической моделью. То есть мы сузим круг поисков до: "Где светлей".

HH>>>Если серьезно, то каждая ошибка всегда имеет конкретную причину, я попытался выявить список таких причин в первом посте.
ГВ>>Да, только эта причина устанавливается после проявления ошибки. Ошибки могут быть и в матмоделях, и в инвариантах, и во всём остальном. Притом больше того, у каждой ошибки есть не только причина, но ещё и имя с фамилией, и зачастую — не одно.

HH>Устанавливается причина после проявления ошибки, но поняв ее, можно попытаться больше не совершать таких ошибок. И ошибка не в фамилии, а в неверном алгоритме мышления.

Я не вижу в первом предложении ни одного основания для утверждения: "ошибка... в неверном алгоритме мышления". Такие нарушения в логике изложения часто становятся причиной и ошибок, и ненужных затягиваний разработки.

HH>>>То, что сложность задачи, которую может охватить человек, ограничена, почему-то не так мешает в других областях. Тут уже писали про инженера.
ГВ>>Мешает. Только в других областях перед "серийным производством" принято выписывать требования, тщательно верифицировать конструкторские решения и вообще всяко проверять друг друга. Это только в программировании принято уповать на "паттерны" чего бы то ни было — то на паттерны архитектур. то на паттерны мышления

HH>Блин, никто не умеет читать. Я написал "не так мешает". Все почему-то прочли "не мешает". Кстати об ошибках

Плохой писатель обвиняет читателей в неумении читать, а хороший переформулирует мысль. Читать все умеют, просто ты употребил сравнение так, словно хочешь сказать, что в "других" областях пренебрежимо малы помехи, связанные с ограниченным объёмом человеческой головы. Да, это как раз об особенностях восприятия письменного текста: неудачно выбранная лексика создаёт массу сложностей в передаче информации от человека к человеку.

HH>Понятно, что паттерны мышления не всемогущи, но они могли бы помочь совершать меньше ошибок.

Может быть, только здесь придётся касаться очень глубоких индивидуальных вещей. Простейший источник ошибок: подумал, что всё ясно, а оказалось, что понял неправильно. Как предотвратить эту ситуацию? Можно пуститься в метафизику с выяснением градаций сомнений и спектра ощущений, которые сопутствуют той или иной степени уверенности. А можно пойти традиционным и надёжным путём: предписать детализировать всё, чтобы изложенное на бумаге не содержало противоречий и недосказанностей, а документы прогонять по одному-двум дополнительным review. Создать несколько томов типовых требований и способов их воплощений, чтоб не повторяться всякий раз, полученный продукт тщательно оттестировать, подписать акты приёмки... И никаких паттернов в голову заколачивать не надо, всё придумано и обкатано не один десяток лет назад.

HH>>>Пробовать разные варианты, это хорошо в случае, когда надо, чтобы работал хотя бы один вариант. Программа должна работать для всех возможных вариантов использования.

ГВ>>Программа и так всегда работает во всех вариантах использования. Просто в некоторых случаях её работа считается отклоняющейся от спецификации. А некоторые случаи считаются недопустимыми. Эту проблему, в принципе, могут помочь решить языки с автоматической проверкой корректности программы по отношению к формальной спецификации, Но ни один такой язык не защитит от ошибок в самой спецификации.

HH>Да, зато от этих ошибок, по-крайней мере от многих из них можно попытаться защититься другими способами (о которых я попытался написать в первом посте).

Я что-то не увидел в твоём первом посте описания способов защиты от ошибок — это раз. А два — надёжная защита надёжна потому, что работает вне зависимости от субъекта. Этим хороши разнообразные нормированные процедуры с разделением ответственностей: один пишет, другой вычитывает, третий принимает решение о "заходе на второй круг". Несколько специалистов пропустят ошибку с меньшей вероятностью, чем один. При условии, конечно, что они добросовестно выполняют свои обязанности, наделены соответствующими полномочиями и дееспособны в рамках этих полномочий.

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

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

Возможно, что формулировка мат. модели или детальный анализ предметной области окажется сложнее, чем написание программы.
В примитивных случаях: полным перебором можно найти решение, которое после строго обосновать и вывести формулу.
В более сложном: сделать несколько прототипов системы на простом языке.

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

HH>При такой общей постановке технического задания не то что математическую модель, а даже самую кривую программу не написать.
HH>Если же поставить конкретные задачи, то некоторые умные люди уже сейчас для многих из них смогут подобрать полезные модели.
Не могут, потому что таких моделей нет. Как там, в "Фактах и заблуждениях ..."
Бухгалтерские программы пишутся с 70ых годов, но поверьте, что в этот момент, когда вы читаете эти сроки пишутся новые, и с 10ок их уже близки к провалу.

Конкретные задачи имеют хорошие модели разве что вывод в консоль "Hello world"
Остальное — опыт, чутье, по аналогии с успешными.

HH>Наверно не покажу. Хотя бы потому, что не очень понимаю, что есть опердень. И что есть затраты применимости проектирования.
Опердень — банковское ПО "операционный день".

Но вы и складскую программу не спроектируете математике. Вернее — может быть и можно, но выйдет так дорого, причем не избавит от проблем при ее эксплуатации что нет смысла.

Понимаете, те "математики" что мне встречались сплошь говорят о тестировании алгоритмов. Причем простеньких, типа сортировки.
А работающая компьютерная программа есть конечный автомат с весьма приличным числом состояний. Причем на эти состояния влияют нередко — внешний условия.

HH>Я так понимаю, что эти разговоры не мешают рассмативать задачи с конечным числом вариантов, которые очень часто встречаются на практике.
На практике то как раз встречаются редко.
Хотя, пару миллиардов — да, тоже конечное число вариантов.

HH>В этом топике приводили ссылку на доказательтство корректности ядра операционной системы или чего-то такого.
Пропустил. Но пусть вначале драйвера научаться на корректность тестировать.

HH> И что из этого следует? Что нельзя решить никакую задачу?
Из этого следует что математика совсем не панацея если даже свои собственные проблемы не только не решила, а даже пока не придумала с какого боку за них браться.
А "через миллион лет", и "нельзя решить" для меня смертного тождественные выражения.

HH>Философия — это хорошо, когда она на своем месте. "Доктор, я буду жить?" — "А смысл?"
Ну так вы же развели бытовую философию

Я бы тоже лучше о практике послушал.

HH>Да, да. Программирование непознаваемо, закономерности действительного мира изучены неверно, все проблемы неразрешимы.
Я такого не утверждал.

HH>Может быть вернемся к практике, где вполне возможно просчитать и предусмотреть очень многие проблемы, и для этого не хватает только знаний и возможно, желания?
Так я пока ее от вас и не вижу. И за года в программировании много слышал о "математике" как средстве решения проблем, да только на практике как-то мало видел.

Так что повторюсь, вы не пожелания и мечты свои — а практику озвучьте.

HH>Не надо философии, в каждом случае требуется математическая модель, которая решает данные конкретные проблемы, а не все проблемы мира.
Не надо пустых слов, приведите примеры математических моделей для работающих компьютерных программ. Модели, по которым создавались эти программы.
Я вот почитал остальное обсуждение на момент написания этой строчки.
Где там конкретика?

А насчет философии, так вот мое ИМХО что большинство юных мечтателей о математике как решении проблем — как раз ею неумело пытаются подменить конкретную мозговую работу, как математиков так и инженеров.

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

N>Возможно, что формулировка мат. модели или детальный анализ предметной области окажется сложнее, чем написание программы.
Не возможно, а так и будет, поэтому то математиков ушли из отрасли еще в 70ых. Утрировано конечно. Встречается ПО где такой анализ обязателен и доныне — например сервера БД и их алгоритмы обработки данных.

N>В примитивных случаях: полным перебором можно найти решение, которое после строго обосновать и вывести формулу.
Решение — чего? Немногое число программ работает с данными полученными только на старте алгоритма.
А большинство программ в процессе работы запрашивают данные.
И собственно — а текст компьютерной программы разве не та самая конечная формула?

Перебор же собственно и используется при тестировании. Или вообще разработка ведется по TDD.
Так же собственно и математики поступают, когда не могут разрешить общий случай — прибегают к решению частных случаев.

N>В более сложном: сделать несколько прототипов системы на простом языке.
Делаются, как же без них. Только математика тут ни при чем — создание макета давно известно человечеству.

HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число?
HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?

В качестве средства описания мне до сих пор нравятся старые добрые структурно-информационные временные схемы (СИВС)...

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

O>В качестве средства описания мне до сих пор нравятся старые добрые структурно-информационные временные схемы (СИВС)...
И замечу что математики в них нет. Поэтому в таком, или ином виде и рисуются такие схемы. Это можно сказать обязательная часть проектирования.

Правда, до надежно работающей компьютерной программы от них еще весьма далеко.
Например из таких схем плохо видно — а области единых транзакций какие будут?

Мне вот другие картинки вспомнились из недавно встреченных.
Из статьи:
Engineering Management: Why are software development task estimations regularly off by a factor of 2-3?
Знание английского требуется минимальное, там все наглядно.

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

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

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

O>>В качестве средства описания мне до сих пор нравятся старые добрые структурно-информационные временные схемы (СИВС)...
S>И замечу что математики в них нет. Поэтому в таком, или ином виде и рисуются такие схемы. Это можно сказать обязательная часть проектирования.

Не любите Вы математику

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

здесь блог автора реализации
здесь одна из статей по теории

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

Посмотрите также ссылку, которую давали выше, по теории сложности и SRP. Это интересно.

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

DG>второй код более однородный, чем первый.

Неудачный пример. foreach проще for'а не потому что однороднее, а потому что использует меньше сущностей. Однородность это скорее стандартность, т.е. если похожие задачи мы по всему коду будем решать схожим образом, и в плане оформления и в плане построения алгоритма, то вероятность допустить ошибку снизится.

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

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

HH>Не любите Вы математику
Так это Ваше имя?

Я не люблю "математиков", а не математику.
Примерно как Linux уважаю, в вот "форумных линуксоидов" обычно — нет

HH>Если серьезно, то математическая модель у меня появляется (к сожалению) уже ближе к концу разработки программы, когда я уже четко представляю то, о чем пишу. ... Причем я отчетливо понимаю, что данная конкретная нотация может быть полезна только для данного случая (и аналогичных).
Если серьезно, то стоит назвать область в которой пишите программы. Как я вскользь упоминал — вполне представляю такие области, где применение строго математических методов будет эффективным.

HH>Если Вам не нравится математика, то модель не обязана быть строго математической, достаточно того, чтобы она помогала находить ошибки.
Повторюсь — мне не нравятся верующие. Математика не в состоянии помогать ошибки в программировании в подавляющем числе случаев.
В предыдущих постах бегло написал почему.

НЕ отождествяйте себя с математикой, я возражаю не ей, а Вашему ее идеализации

HH>Настоящие же профи могут использовать настоящую математику (алгебру — моноиды, монады, аппликативные функторы и т.п.), причем достаточно сложную.
А что такое настоящие профи, и ненастоящие?

ИМХО — настоящие профи весьма прагматичные ребята. И они используют инструменты что подходят под ситуацию, а не молятся на идеальные методики.

HH>Я смотрю в сторону таких вещей как денотационная семантика, функциональное программирование.
И какое это отношение имеет к природе ошибок в программировании?

HH>Для примера можно привести библиотеку функционального реактивного программирования.
Можно.
А смысл, если Вы не смогли показать "на пальцах" как разрешить основные причины ошибок в программировании своим подходом.

Для примера же могу привести тьму библиотек БЕЗ особой математики, но которые используются в тьме ПО. Замечу — работающего ПО, а не идеального, но которое идеально потому что оно вообще не вышло за стены "лаборатории", а возможно из головы автора.

HH>здесь блог автора реализации
HH>здесь одна из статей по теории

HH>Конечно, это уже высший пилотаж, и от всех людей нельзя требовать, чтобы они даже понимали о чем речь в этой статье.
Понимаете, ролики на ютьюбе с забрасывающими мяч в баскетбольную корзину с удивительных позиций набрали немалое число просмотров.
Только возьмут ли тех ребят в NBA?

"Высший пилотаж" понятие относительное.

HH>Но библиотеку сделали именно по математической модели. Так что вполне возможно делать нетривиальные программы, используя математику.
Я и не утверждал что нельзя.

И утрировано — меня интересуют больше: как писать тривиальное ПО без ошибок

HH>Нам же, кто математику знает плохо, может быть полезна даже не очень строгая формулировка модели,
Нам же, программистам, и строгая без толку.

HH>Посмотрите также ссылку, которую давали выше, по теории сложности и SRP. Это интересно.
На свете много чего интересного. И в программировании тоже.

Но я так и не увидел как математические модели могут помочь отрасли разработки ПО.

Добавлю, что увлечение ими было распространено в 50ые, 60ые, а в 80ые японцы даже провалили создание машин 5го поколения.

Программирование с тех пор стало циничней и скептичней.
Конечно, наработки в сomputer science продолжаются и востребованы. (а то еще может вы себя и с сomputer science отождествляете и скажете что я против)
Но до ошеломляющего успеха науки в практике — ой как далеко.

Более эффективными методами оказываются существующие и их развитие — грамотное управление ведением проектов, харизматичные менеджеры собирающие сплоченные команды, ООП, TDD и просто талант+квалификация программистов.

Математика — одна из самых формализованных дисциплин. И если ее формализация не работает, не помогает кардинально решить проблемы, то вот и возникает вопрос о ее применимости к таким-то проблемам вообще.

U>А принцип минимума сущностей должен идти в твоем списке отдельным пунктом, причем пожалуй самым важным. Т.к. тот же геттерный подход по сравнению с сеттерным

pull-схема(она же геттеры) улучшает предсказуемость кода. фактически при pull-схеме, что написано в коде, то и будет происходить в реальности, при push-схеме — реальное поведение необходимо восстанавливать.

зы
не вижу пока, как ты именно через переход сеттеры -> геттеры уменьшаешь кол-во сущностей.

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

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

Я бы сказал не хватает пункта 4 — нужно учитывать, что завтра могут поменяться требования и половину продукта придется перелопатить. Это очень печальный пункт, когда люди умудряются размазать логику по всем модулям, так что ее потом замучаешься вытаскивать

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

То, что Вы пишите, говорит о том, что Вы не понимаете меня. А я в свою очередь не могу понять Вас.
Я не знаю, как объяснить, потому что сам еще мало что понимаю.
Я пишу программы в области документооборота. Вам стало легче?
Те задачи, которые при этом возникают, не имеют к этому названию никакого отношения.
Математика — это всего лишь язык, инструмент, которым можно пользоваться.
Я порекомендовал модели, как одно из средств, которое позволяет избежать ошибок уже на этапе продумывания спецификации программы.
Использовать ли их, и в каких случаев, это дело каждого.
Я не собираюсь их навязывать.
Более того, я хотел бы узнать, какие вообще есть средства, чтобы минимизировать количество ошибок.

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

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

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

ZOI>Я бы сказал не хватает пункта 4 — нужно учитывать, что завтра могут поменяться требования и половину продукта придется перелопатить. Это очень печальный пункт, когда люди умудряются размазать логику по всем модулям, так что ее потом замучаешься вытаскивать

Пункт 4 здесь неуместен. Потому что каждый из предыдущих пунктов какбы намекает на решение проблемы.
А пункт 4 в применении к математической модели звучит так:
4': при добавлении в модель новой операции выяснилось, что эта операция не бьется с остальными, т.е. фактически разрушает текущую модель, и надо вместо нее придумывать новую.

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

DG>зы
DG>не вижу пока, как ты именно через переход сеттеры -> геттеры уменьшаешь кол-во сущностей.

При сеттерном подходе если источник меняется из десяти мест, то и изменять состояние объектов зависящих от источника нужно тоже из десяти мест. При геттерном подходе при изменении источника изменять состояние зависящих объектов не нужно в принципе. Соответственно в коде на десять очень сложных сущностей стало меньше.

U>При сеттерном подходе если источник меняется из десяти мест, то и изменять состояние объектов зависящих от источника нужно тоже из десяти мест. При геттерном подходе при изменении источника изменять состояние зависящих объектов не нужно в принципе. Соответственно в коде на десять очень сложных сущностей стало меньше.

в первом приближении это может быть реализовано как:

this.X = new_X1;
this.Update_X_Dependencies();
[..]

this.X = new_X2;
this.Update_X_Dependencies();

и так десять раз.
дублирование десять раз this.Update_X_Dependencies() еще не похоже на увеличение кол-ва сущностей

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

DG>и так десять раз.
DG>дублирование десять раз this.Update_X_Dependencies() еще не похоже на увеличение кол-ва сущностей

Это синтаксический сахар, от которого сущности никуда не делись. Как только, к примеру, окажется, что код изменяющий X не знает всех объектов, которые от X зависят, это станет очевидным.

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

DG>и так десять раз.
DG>дублирование десять раз this.Update_X_Dependencies() еще не похоже на увеличение кол-ва сущностей

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