Иван Кузьмицкий писал(а):
Пишут, что существует математический аппарат, призванный бороться с многообразием и сложностью. Более того, есть ненулевая вероятность существования софта на базе этого мат.аппарата...
Если говорить о борьбе со сложностью в области программирования, особенно а-ля мэйнстрим, то здесь ещё непаханое поле, причём для методик пока более чем достаточно начальной школьной элементарной математики и немного здравого смысла. Например, возьмём вот эту
Р-программу для вычисления корней уравнения (из книги Вельбицкого,
здесь). В качестве одного из вариантов на приемлемом ЯП она может быть задана примерно так:
Код:
type Результат(a) = ДРВК a, a | ДКК a, a | ДРК a | КО а | КН | КБМ
алгоритм = (a, b, c) ->
| a != 0 => x = -b/2a
d = x^2 - c/a
дрвк(d, x)
| b != 0 => KO(-c/b)
| c != 0 => КН
| _ => КБМ
where дрвк = (d, x) ->
| d > 0 => d' = sqrt(d)
x1 = x + d'
x2 = x - d'
ДРВК(x1, x2)
| d < 0 => x2 = sqrt(-d)
ДКК(x, x2)
| _ => ДРК(x)
do ->
a = 12
b = 34
c = 56
рез: Результат(float64) = алгоритм(a, b, c)
case рез of
ДРВК(x1, x2) => writeln "два различных вещественных корня: $x1, $x2"
ДКК(x1, x2) => writeln "два комплексных корня: $x1, $x2"
ДРК(x) => writeln "два равных корня: $x"
КО(x) => writeln "корень один: $x"
КН => writeln "корней нет"
КБМ => writeln "корней бесконечно много"
Причём это строго типизированный полиморфный код, во время вызова "алгоритм"-а все типы будут установлены, причём явно указана требуемая точность (float64), что предопределяет тип для всех переменных ф-ции. Что ещё можно сказать..., в подобных языках, как и в школьной математике, количество аргументов ф-ции более четырёх уже считается признаком плохого тона, как и много уровней вложенности...
И, кстати, если ещё использовать нормальный текстовый редактор, где есть возможность расположить код в нескольких окошках, то, фактически, с текстом можно работать как с Р-схемами: "where"-часть функции свернуть ("fold") и открыть справа (примерно по
таким мотивам,
отсюда) - наглядно, как и Р-схемы, чему ещё способствуют сегодняшние широкие экраны благодаря Голливуду.
Теперь подход мэйнстрима, скажем, Java. Конечно, всё должно быть в классах, никаких там "алгоритмов". Тот же тип "Результат" будет выстроен в цепочку наследования, введены "свойства", сплошные методы "Get"/"Set" и т.д. Сразу же написаны "тесты" и успешно "пройдены". Более того, должен же быть полиморфизм (!!!, мы же современны !), срочно нужны ещё "интерфейсы" и их "реализации" (написаны "тесты" и успешно "пройдены"). А как же Dependency injection ? Срочно ваяем "фабрики", ваяем XML-конфигурации (матерясь на этот XML) или втыкаем "аннотации" в код, и т.д. и т.п. (нужны или нет здесь "фабрики" - думать нельзя, так промстандарты постановили, обо всём уже подумали за тебя ...)
В результате, "уравнение" размазывается на кучу методов и классов, и на разные файлы, в коде технических слов (сплошной мусор, "организованный" далеко не самым оптимальным образом) больше, чем "решения".
Блин, сложно... Так ведь же нужен UML... Рисуют квадратики с лесом линий, смотрят на них..., между собой молча договариваются, что это якобы помогает, начальство отстало... Множатся диссертации про неимоверные успехи UML(ОПП)-методологии...
Всё-равно, сложно... Куча книг про "паттерны", диссертаций про метрики кода..., якобы разобраны все алго- и ООП-связи с точность до граммов. Мэйнстрим-строители "посчитали" и "взвесили" сложность да ужаснулись? Ага, щаз... Вон в Scala простор для диссертаций чуть ли не каждый день расширяется как Вселенная, новые метрики для оценки "явно неявного" ("implicit"-ы) - блеск! Есть методики, учитывающие плюсовые friend-классы, но почему-то нет метрик, показывающих их абсурдное противоречие самой же ООП-идеологии...
В общем, вся борьба со сложностью - "ништяки" "ништяками" погоняют...