ZOI>>Я бы сказал не хватает пункта 4 — нужно учитывать, что завтра могут поменяться требования и половину продукта придется перелопатить. Это очень печальный пункт, когда люди умудряются размазать логику по всем модулям, так что ее потом замучаешься вытаскивать
HH>Пункт 4 здесь неуместен. Потому что каждый из предыдущих пунктов какбы намекает на решение проблемы.
если этот пункт переформулировать, то он становится уместным:
значительная часть ошибок вызвана тем, что в коде не записывается модель, а записывается лишь решение вытекающее из этой модели, а модель остается в голове разработчика, что:
во-первых: приводит к необходимости восстановления модели из кода при каждом изменении кода (со всеми проблемами из этого вытекающими),
во-вторых: делает невозможным применение автоматизированных средств для управления(верификация, преобразования и т.д.) моделью
Здравствуйте, Undying, Вы писали:
U>При сеттерном подходе если источник меняется из десяти мест, то и изменять состояние объектов зависящих от источника нужно тоже из десяти мест. При геттерном подходе при изменении источника изменять состояние зависящих объектов не нужно в принципе. Соответственно в коде на десять очень сложных сущностей стало меньше.
U> Соответственно в коде появляется столь сложная в понимании и опасная в примении сущность как события и подписка на них.
т.е. падает показатель предсказуемости кода?
о том и речь, что первичная задача — максимизировать предсказуемость, и используется корреляция, что при уменьшение кол-ва сущностей увеличивается предсказуемость (но в общем случае, уменьшение кол-ва сущностей не ведет к увеличению предсказуемости, а переход с push на pull может давать и увеличение кол-ва сущностей, особенно на стыке с внешним окружением: как минимум требуется писать синхронайзер под каждый класс из внешнего окружения)
Здравствуйте, HrorH, Вы писали:
HH>Здравствуйте, Skynin, Вы писали:
HH>Я не знаю, как объяснить, потому что сам еще мало что понимаю.
Во втором и не сомневался. Потому что тогда знали бы как объяснить
HH>Я пишу программы в области документооборота. Вам стало легче?
Мне и не было тяжело. Это вы потроллиться что-ли предлагаете?
Лучше расскажите конкретней, как в своей области вы применяете математические методы
HH>Математика — это всего лишь язык, инструмент, которым можно пользоваться.
Разумеется. И как всякий инструмент его можно применять И неумело, И не к месту.
HH>Я порекомендовал модели, как одно из средств, которое позволяет избежать ошибок уже на этапе продумывания спецификации программы.
А я спросил — на чем основаны эти рекомендации? На каком успешном опыте?
Мало того, указал и на причины почему не только мне, а вообще такой успешный метод массово — неизвестен.
HH>Использовать ли их, и в каких случаев, это дело каждого.
О нет, я могу рекомендовать для написания надежных программ рисовать на стенах в офисе желтые квадраты в синий горошек.
"А использовать ли этот отличный метод — это дело каждого!"
HH>Я не собираюсь их навязывать.
А вы попытайтесь :D
Или хотя бы победите в конкурентной борьбе других разработчиков в области документооборота.
HH>Более того, я хотел бы узнать, какие вообще есть средства, чтобы минимизировать количество ошибок.
Минимальный набор, существующий в отрасли я указал.
Книг, исследований же на эту тему написано немало, как с анализом причин, причем разнообразных, не связанных между собой одной категорией,
так и с методиками уменьшения влияния этих причин на качество конечных программных продуктов.
Извините что так размыто "Формулы" у меня нет, и не встречал у кого она есть.
У вас вот тоже(просто "удивительно"!) тоже — "сам еще мало что понимаю"
Вот о том что Вы, и обычно увлеченные "математики" пока не понимают я и упомянул.
А Вы мне сразу о философии забросили. О нефальсифицируемости математики, как и религии с психологией, при одновременном их огромном значении и влиянии на человеческий интеллект, дух и душу, я рассуждаю на соответствующих форумах.
Здравствуйте, Константин, Вы писали:
vsb>>>Программы без ошибок появятся, когда появится искусственный интеллект. VC>>ИИ не "появится", его создадут. И тоже с ошибками... К>При этом способность совершать ошибки будет заложена в сам ИИ
Просто потому, что иначе не получится. ИИ не сможет ничего осознать, пока не сможет делать ошибок.
Извини, не удержался.
U>> Соответственно в коде появляется столь сложная в понимании и опасная в примении сущность как события и подписка на них.
DG>т.е. падает показатель предсказуемости кода?
К чему это наукообразие? Показатель, функция, корреляция... Можно же выразиться проще: что становится трудно понять, как именно работает код и какие он вызывает побочные эффекты. Всё равно эти "показатели", "функции" и "корреляции" или вовсе нельзя рассчитать, или можно рассчитать только на очень ограниченном множестве переменных, которые не отражают всех факторов.
DG>о том и речь, что первичная задача — максимизировать предсказуемость, и используется корреляция, что при уменьшение кол-ва сущностей увеличивается предсказуемость (но в общем случае, уменьшение кол-ва сущностей не ведет к увеличению предсказуемости, а переход с push на pull может давать и увеличение кол-ва сущностей, особенно на стыке с внешним окружением: как минимум требуется писать синхронайзер под каждый класс из внешнего окружения)
Чтобы продраться через этот абзац пришлось прочесть всё сообщение сверху вниз, снизу вверх и ещё по диагонали. В контексте топика прекрасная иллюстрация того, как наукообразием можно замусорить даже самые простые сведения. По сути ты высказал простейшую мысль, что для реализации pull-модели могут понадобиться дополнительные интерфейсные объекты, но код будет проще читать, поскольку подписчики будут изолированы один от другого. В общем, обе мысли очевидны, но при чём тут "корреляция" и "предсказуемость" — тайна сия велика есть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Попробую намекнуть на один из примеров, просто не хочется палиться.
Сразу станет понятно, что я понимаю слово "математический" несколько широко.
Даже в данном случае можно просто сказать — модель, не произнося слово математический.
Допустим у нас есть дерево объектов, и с этим деревом могут работать одновременно несколько пользователей.
В модели у нас должна быть операция редактирования объекта.
При этом объект должен блокироваться.
Также должна быть операция добавления нового объекта, удаления объекта, перемещения и копирования.
Возникает вопрос, какие блокировки и проверки нужны, чтобы все эти операции бились между собой, и пользователи не портили данных друг друга.
Ответом на этот вопрос и будет модель.
Здесь важно то, что при добавлении каждой новой операции в модель во всех остальных операциях это должно учитываться. Скажем, при добавлении операции удаления, при выполнении остальных операций должна добавиться проверка, что объект не удален.
При добавлении в систему безопасности, в операции редактирования добавляется проверка, есть ли права на редактирование, или только на чтение и т.д.
В операции удалении — что у нас есть права на удаление и т.д.
Тут есть куча подробностей, которые я приводить не буду, скажу только, что то, что я сейчас написал — не совсем корректно, и можно рассматривать только как иллюстрация.
А причем тут мат. модель? -спросите Вы.
Дело в том, что надо рассмотреть все попарные сочетания операций, и учесть все аспекты существующие в системе.
Это пока еще будет просто модель, она станет математической, когда и если появиться необходимость и возможность написать ее в соответсвующей нотации, ведь как я говорил, математика — это всего лишь язык.
Здравствуйте, HrorH, Вы писали:
HH>Более того, я хотел бы узнать, какие вообще есть средства, чтобы минимизировать количество ошибок.
Если уж смотришь в сторону функциональщины то смотри Зависимые типы и такие языки как например:
ATS http://www.ats-lang.org/ это более-менее практичный язык вполне годный для использования в прикладном программировании, но к сожалению еще далек от полноценного релиза.
Можешь также посмотреть Agda, Epigram, но это уже академично по моему.
Ну и если так сильно тянет в математику то посмотри еще Coq
Если же тебе нужны средства для более гражданских языков, то ищи по ключевым "контрактное программирование", "статический анализ".
Кое-что из этого уже пытался смотреть... Правда, пока мало что понял.
А чем помогут зависимые типы, если необходимо сделать корректную спецификацию программы?
DG>>т.е. падает показатель предсказуемости кода?
ГВ>К чему это наукообразие? Показатель, функция, корреляция...
пока задача не сформулирована через показатели, функции, корреляцию и т.д. — ее невозможно решить научным методом, а можно лишь решать методами тыка и взглядами в потолок.
ГВ>По сути ты высказал простейшую мысль, что для реализации pull-модели могут понадобиться дополнительные интерфейсные объекты, но код будет проще читать, поскольку подписчики будут изолированы один от другого.
Здравствуйте, HrorH, Вы писали:
HH>Кое-что из этого уже пытался смотреть... Правда, пока мало что понял. HH>А чем помогут зависимые типы, если необходимо сделать корректную спецификацию программы?
В этом мало помогут, это вообще неформализуемая задача, тут и математика ничем ни поможет.
Помогут в другом если уже формализация есть реализовать ее максимально безошибочно, конечно
помогут не только и не столько зависимые типы, а скажем весь арсенал что есть например в ATS.
Ну и тот же Coq вполне средство построения формальных моделей.
Ну и на фоне того что сама математика уже уперлась в пределы доказуемости я бы особо не надеялся
на то что это будет разрешимо для программирования.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, HrorH, Вы писали:
HH>>Кое-что из этого уже пытался смотреть... Правда, пока мало что понял. HH>>А чем помогут зависимые типы, если необходимо сделать корректную спецификацию программы?
FR>В этом мало помогут, это вообще неформализуемая задача, тут и математика ничем ни поможет.
Я тут уже 2 раза в этой ветке приводил ссылку на то, как это сделано в FRP.
Вот другая ссылка, но из той же области здесь
Люди как-то используют математику для написания спецификаций, а все мне говорят то про неформолизуемость, то про ограниченность самой математики...
Я не въезжаю, причем здесь ограниченность математики.
Почитайте бумаги Conal Elliott, если Вы их еще не читали. Вы то сможете это понять.
И не надо говорить, что это невозможно (неформализуемо), если это уже есть.
Здравствуйте, DarkGray, Вы писали:
DG>>>т.е. падает показатель предсказуемости кода? ГВ>>К чему это наукообразие? Показатель, функция, корреляция...
DG>пока задача не сформулирована через показатели, функции, корреляцию и т.д. — ее невозможно решить научным методом, а можно лишь решать методами тыка и взглядами в потолок.
Сначала нужно показать саму функцию "предсказуемости".
ГВ>>По сути ты высказал простейшую мысль, что для реализации pull-модели могут понадобиться дополнительные интерфейсные объекты, но код будет проще читать, поскольку подписчики будут изолированы один от другого.
DG>что такое "проще читать"?
Молодец! Эту фразу вообще можно выкинуть. Останется: "для реализации pull-модели могут понадобиться дополнительные интерфейсные объекты, но подписчики будут изолированы один от другого". Смысл не поменялся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
FR>>В этом мало помогут, это вообще неформализуемая задача, тут и математика ничем ни поможет.
HH>Я тут уже 2 раза в этой ветке приводил ссылку на то, как это сделано в FRP. HH>Вот другая ссылка, но из той же области HH>здесь
Ссылки не помогут, такие читать целая работа, расскажи вкратце суть.
Что такое FRP я знаю, но не вижу какое отношение имеет к формализации. Это скорее один из
элементов или паттернов проектирования. С таким же успехом можно сказать что с помощью
скажем ОО или монад уже все формализовано.
HH>Люди как-то используют математику для написания спецификаций, а все мне говорят то про неформолизуемость, то про ограниченность самой математики... HH>Я не въезжаю, причем здесь ограниченность математики. HH>Почитайте бумаги Conal Elliott, если Вы их еще не читали. Вы то сможете это понять. HH>И не надо говорить, что это невозможно (неформализуемо), если это уже есть.
DG>>пока задача не сформулирована через показатели, функции, корреляцию и т.д. — ее невозможно решить научным методом, а можно лишь решать методами тыка и взглядами в потолок.
ГВ>Сначала нужно показать саму функцию "предсказуемости".
Предсказуемость'(код K, требование T)=минимального вычислительная сложность алгоритма, который для кода K проверяет требование T.
Предсказуемость = 1/Предсказуемость';
вернемся к примеру который уже был:
for (uint i = items.Length - 1; i >= 0; --i)
{
var item = items[i];
//что-то делаем с item
}
foreach (var item in items.Reverse())
{
//что-то делаем с item
}
для кода вида, как во втором примере, требование "незацикливаться" проверяется простым автоматом за O(кол-во операторов в программе), а чтобы проверить на зацикливание код вида, как в первом варианте, необходим алгоритм со сложностью близкой к O(2^кол-во операторов в программе)
зы
изолированность хороша тем, что при правильной изоляции функция предсказуемости выглядит как:
Предсказуемость'(код, требование)=Sum(Предсказуемость'(изолированная часть кода_i, требование))
для неизолированного кода функция ведет себя много хуже:
Предсказуемость'(код, требование)=Product(Предсказуемость'(неизолированная часть кода_i, требование))
FR>Ну и на фоне того что сама математика уже уперлась в пределы доказуемости я бы особо не надеялся FR>на то что это будет разрешимо для программирования.
основная проблема, что математики хотят всегда точное решение. и в статье по ссылке подразумевается, что теории могут быть только точными. на практике же в большинстве задач достаточно теорий и решений, которые описывают и решают задачу с частичной потерей точности.
Я так понял, что при разработке теории функционального реактивного программирования этому Conal Elliot в голову пришла идея.
Во-первых, надо говорить про денотационную семантику (это то что придумали в 1960)
Denotational semantics is a compositional style for precisely specifying
the meanings of languages, invented by Christopher Strachey
and Dana Scott in the 1960s (Scott and Strachey 1971; Stoy 1977).
The idea is to specify, for each syntactic category C,
a mathematical model [C] of meanings, and
a semantic function [.]C :: C -> [C].
Так, вот тут есть семантическая функция, которая сопоставляет синтаксису в коде его значения в модели (здравствуй, Рабинович).
Так вот, идея была в том, что могут быть законы, которые выполняются для этой семантической функции.
Вот обсуждение этого в блоге Вадлера здесь.
Кстати он там рекомендует посмотреть здесь
Вот эти 2 бумаги кажется основные.
Но меня поразило именно то, что все эти апликативные функторы, монады и т.д. использовались именно для определения семантики программы, а сама реализация по мере развития библиотеки делалась более эффективной, то есть использовались другие конкретные типы, но сама модель оставалась почти неизменной.
Боюсь, что от моего описания лучше не стало, т.к. мне самому в этом еще разбираться и разбираться, поэтому если сможете прочесть, лучше сами потом расскажете
В конце концов Вадлер на ерунду обращать внимание не стал бы
Здравствуйте, DarkGray, Вы писали:
DG>т.е. падает показатель предсказуемости кода?
Падает, но это одно из следствий. А нас интересует причина почему это происходит.
DG> а переход с push на pull может давать и увеличение кол-ва сущностей, особенно на стыке с внешним окружением
С чего это будет увеличение количества сущностей? В общем случае при геттерном подходе любой объект представляется в виде автоматического кэша с несколькими входами, в событийной — в виде объекта подписанного на несколько событий.
Проблемы событийного подхода:
1) Проблема лишних модификаций приемника. Если объект подписан на три события, то может возникнуть ситуация при которой одна логическая транзакция порождает три модификации приемника вместо одной. Причем первые две модификации происходят в невалидном состоянии системы, когда логическая транзакция отработала только частично.
2) Проблема оповещения о изменении инициатора изменений. Если объект подписанный на размер контрола, сам изменяет этот контрол, то контрол порождает событие и в этом объекте. Причем опять же вызов этого события происходит в невалидном состоянии системы, т.е. до завершения логической транзакции.
3) Каждый источник должен знать все объекты от него зависящие (пусть и в виде специализированного интерфейса). Соответственно возникает проблема отписки.
Все перечисленные проблемы обнаруживаются бритвой Оккама, т.е. порождают сущности, которых нет в логическом решении. В первом и втором виде проблем в виде лишних вызовов обработчиков событий в рантайме, в третьем — в виде записи в коде и вызовах в рантайме кода отписки от событий. При этом если в третьей проблеме порождаются просто дополнительные сущности, что еще полбеды, то в первой и второй проблемы — это сущности-вредители, которые не просто лишние, но еще и заставляют работать систему в невалидном состоянии, что и делает событийный код крайне сложным и трудно предсказуемым.
При этом если усложнять код, то для третьей проблемы есть неплохое решение, для второй проблемы — плохое, но работающее, но способа решить первую проблему я не вижу вовсе.
При геттерном подходе таких проблем нет в принципе.
