Сообщение Re[13]: Haskell нужен! (в Standard Chartered Bank) от 03.02.2015 13:59
Изменено 03.02.2015 14:21 Mamut [ищите в других сетях]
M>>Это какие-то общие фразы без конкретики.
K>Ок, с конкретикой: нельзя будет сконструировать заказ с состоянием "Отправленный" и "Непроверенный как написано в 4-м пункте" одновременно, так что в случае забывания 4-го пункта будет ошибка компиляции. Ну, как нельзя забыть проверить значение типа Maybe Foo на пустоту и вызвать функцию bar заданную на Foo, потому что она на Maybe Foo не определена.
Легко предание, да не верится вообще нифига.
Сколько условий «Непроверенный как написано в энном пункте» предлагаешь впихивать в тип?
Каким образом это поможет мне не забыть вписать в тип ошибку «Непроверенный как написано в энном пункте»? <- вот это и есть логическая ошибка, от которой все сказки про типы не спасут
Каким образом это мне поможет на этапе компиляции, если вся информация о заказе идет в рантайме (включая такие прекрасные вещи, как конфигурации десятка параметров из базы данных)?
Ты перенес все эти четыре десятка условий в типы, молодца. Как ты собираешься проверять, что ты эти условия описал в типах логически правильно?
K>Ок, с конкретикой: нельзя будет сконструировать заказ с состоянием "Отправленный" и "Непроверенный как написано в 4-м пункте" одновременно, так что в случае забывания 4-го пункта будет ошибка компиляции. Ну, как нельзя забыть проверить значение типа Maybe Foo на пустоту и вызвать функцию bar заданную на Foo, потому что она на Maybe Foo не определена.
Легко предание, да не верится вообще нифига.
Сколько условий «Непроверенный как написано в энном пункте» предлагаешь впихивать в тип?
Каким образом это поможет мне не забыть вписать в тип ошибку «Непроверенный как написано в энном пункте»? <- вот это и есть логическая ошибка, от которой все сказки про типы не спасут
Каким образом это мне поможет на этапе компиляции, если вся информация о заказе идет в рантайме (включая такие прекрасные вещи, как конфигурации десятка параметров из базы данных)?
Ты перенес все эти четыре десятка условий в типы, молодца. Как ты собираешься проверять, что ты эти условия описал в типах логически правильно?
Re[13]: Haskell нужен! (в Standard Chartered Bank)
M>>Это какие-то общие фразы без конкретики.
K>Ок, с конкретикой: нельзя будет сконструировать заказ с состоянием "Отправленный" и "Непроверенный как написано в 4-м пункте" одновременно, так что в случае забывания 4-го пункта будет ошибка компиляции. Ну, как нельзя забыть проверить значение типа Maybe Foo на пустоту и вызвать функцию bar заданную на Foo, потому что она на Maybe Foo не определена.
Легко предание, да не верится вообще нифига.
Сколько условий «Непроверенный как написано в энном пункте» предлагаешь впихивать в тип?
Каким образом это поможет мне не забыть вписать в тип ошибку «Непроверенный как написано в энном пункте»? <- вот это и есть логическая ошибка, от которой все сказки про типы не спасут
Каким образом это мне поможет на этапе компиляции, если вся информация о заказе идет в рантайме (включая такие прекрасные вещи, как конфигурации десятка параметров из базы данных)?
Ты перенес все эти четыре десятка условий в типы, молодца. Как ты собираешься проверять, что ты эти условия описал в типах логически правильно?
[добавлено потом]
Это я еще умолчал о разных веселых сайд-эффектах:
— отсылать e-mail'ы разных типов при разных действиях
— в зависимости от конфигураций и того, что выбрал пользователь, отсылать бумажные письма
— дергать payments/dunning/bookkeeping за разные части в разные моменты
— вызывать risk check и производить разные действия в зависимости от результата. Не на всех этапах, естественно
— обрабатывать случаи нестандартной интеграции (в основном, для очень больших магазинов)
и еще вагон и маленькая тележка
K>Ок, с конкретикой: нельзя будет сконструировать заказ с состоянием "Отправленный" и "Непроверенный как написано в 4-м пункте" одновременно, так что в случае забывания 4-го пункта будет ошибка компиляции. Ну, как нельзя забыть проверить значение типа Maybe Foo на пустоту и вызвать функцию bar заданную на Foo, потому что она на Maybe Foo не определена.
Легко предание, да не верится вообще нифига.
Сколько условий «Непроверенный как написано в энном пункте» предлагаешь впихивать в тип?
Каким образом это поможет мне не забыть вписать в тип ошибку «Непроверенный как написано в энном пункте»? <- вот это и есть логическая ошибка, от которой все сказки про типы не спасут
Каким образом это мне поможет на этапе компиляции, если вся информация о заказе идет в рантайме (включая такие прекрасные вещи, как конфигурации десятка параметров из базы данных)?
Ты перенес все эти четыре десятка условий в типы, молодца. Как ты собираешься проверять, что ты эти условия описал в типах логически правильно?
[добавлено потом]
Это я еще умолчал о разных веселых сайд-эффектах:
— отсылать e-mail'ы разных типов при разных действиях
— в зависимости от конфигураций и того, что выбрал пользователь, отсылать бумажные письма
— дергать payments/dunning/bookkeeping за разные части в разные моменты
— вызывать risk check и производить разные действия в зависимости от результата. Не на всех этапах, естественно
— обрабатывать случаи нестандартной интеграции (в основном, для очень больших магазинов)
и еще вагон и маленькая тележка