Пределы применения статической типизации

[metaclass]

Очевидно, что статическая типизация не панацея, но все равно интересно натыкаться на места, где она никак не поможет гарантировать отсутствие ошибок.
Например, когда мы пишем предикат для фильтра для списка - если мы ошибемся в условии, это в compile time никак не отловишь, хоть тресни.
В этом плане хороши предметные области, где есть свои способы проверки, типа бухгалтерии. Там большинство отчетов можно проверить несколькими способами(если конечно, архитектура нормальная, а не "мы не можем сделать по-человечески, поэтому будем дублировать проводки в таблице два раза и отфильтровывать везде ненужные")

Comments

[berezovsky.livejournal.com]

метод двойной записи-2

[gds.livejournal.com]

любая алгоритмика, например. a+b vs a-b. Да много где статическая типизация уже ничего не гарантирует.

[deni-ok.livejournal.com]

ну, если включать в тип "разумный" набор пред- и постусловий, то гарантии будут. Например, если на выходе алгоритма сортировки требовать sortedSequence, то если алгоритм не сортирует, то будет ошибка типизации. Правде пока никто не знает, как это удобно реализовать :(

[gds.livejournal.com]

не совсем в тему, но написа лося.

[nivanych.livejournal.com]

В пред-пост-условиях тоже можно обшибиться.
То есть, можно обшибиться в спецификации, если на неё не накладывать дополнительных условий (что тоже не гарантия).
Пример - DNS, в котором пару лет назад обнаружили дыру.
Правда, технология с около-Хоаровыми-тройками уже очень от многого бы избавила.

[nivanych.livejournal.com]

Ещё и есть сертификаты на сертификаты.
Это называют культурой бозопасности.
Многое можно делать, несмотря на очень жёсткую спецификацию.
Но если есть некие (проверенные?) требования более высокого уровня, то и действия в пределах свободных будут более осторожными.