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

M>Сколько условий «Непроверенный как написано в энном пункте» предлагаешь впихивать в тип?

Для начала в конструктор значения этого типа.

M>Каким образом это поможет мне не забыть вписать в тип ошибку «Непроверенный как написано в энном пункте»? <- вот это и есть логическая ошибка, от которой все сказки про типы не спасут

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

M>Каким образом это мне поможет на этапе компиляции, если вся информация о заказе идет в рантайме (включая такие прекрасные вещи, как конфигурации десятка параметров из базы данных)?

Это не является ограничением для статической проверки типов, но тут и этого не требуется.

M>Ты перенес все эти четыре десятка условий в типы, молодца. Как ты собираешься проверять, что ты эти условия описал в типах логически правильно?

Проще искать ошибки с трансляцией спецификации в тип в одном месте, чем с ее выполнением в 1024-х местах в коде.