Здравствуйте, AlexRK, Вы писали:
ARK>Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
То есть мы отлавливаем ошибку отсутствия if(hasRisk) выше по стеку?
Да, изобразить это без буста не удастся. Впрочем, полезность этой процедуры не больше нуля. Забыть сделать проверку выше по стеку ничуть не более вероятно, чем забыть сделать проверку прямо в этой функции. Поэтому в результате мы имеем программу, в которой написаны две проверки на наличие риска — одна статическая на шаблонах, а другая — рантайм.
Ну, либо программист забыл добавить первую из них, и компилятор ничем ему не помог.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[70]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, AlexRK, Вы писали:
ARK>Прошу прощения, здесь я наврал. Этот код действительно скомпилируется, ведь мы предусмотрели возможность передачи в try_to_change_amount невалидного ордера. ARK>А вот если бы потребовали только валидный, как здесь — http://rsdn.ru/forum/philosophy/5967700?tree=tree
— то не скомпилируется. ARK>Боюсь, это вы чего-то не понимаете.
Омг. Кошмар на улице Вязов — 5. "Мы спим! Он завставляет нас бегать по кругу!"
Я вам напомню, что функция, в которую не было предусмотрено передачи невалидного ордера, у нас уже была. Это increase_amount.
Сигнатуру try_to_change_amount пришлось "испортить" из-за того, что есть функция LoadOrder, которая умеет загружать только "неизвестно какие" ордера.
Именно поэтому jazzer в ответ на вопросы про эту функцию пишет много слов и ноль кода
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[72]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, AlexRK, Вы писали:
ещё раз: всё, чего вы добились — это делегирования ответственности за коммуникацию с пользователем на уровень выше.
Т.е. в случае незатейливой increase_amount в ней все требования проверяются динамически, и в случае их нарушения пользователь получает Message Box с объяснением причин.
А вы предлагаете обязать программиста, использующего increase_amount, провести проверки до вызова, чтобы в случае провала проверок пользователь получил MessageBox с объяснением причин.
Единственная проблема, которую ваше "решение" решает — это обеспечение разных текстов ошибок в разных контекстах (ну или, скажем, чтобы вызовы через web получали 400 bad request, а вызовы из rich application показывали MessageBox). Но для этой проблемы есть старое и гораздо более удобное решение — выброс исключений. Обязанность коммуницировать с пользователем делегируется вверх по стеку; а сам набор проверок гарантированно выполняется благодаря инкапсуляции.
От статической типизации ожидают большего — например, сокращения количества рантайм-проверок, путём исключения избыточных.
Пока что в данной задаче ничего подобного продемонстрировано не было.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[77]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>Понятно, что — О УЖАС — кто-то может передать сюда не массив, а что-то страшное, например объект. Но вот незадача... В системе, в прошлом году сгенерировавшей миллиард евро оборота, такие пробелмы вылезают — ну, два раза в год
Ну кстати это не аргумент. Может конкретно в вашей системе огромное количество денег, сил и времени тратится на написание тестов, которые можно было б не тратить в статических языках?
Иными словами это всего-лишь один пример, а надо говорить про статистику.
Здравствуйте, Mamut, Вы писали:
M>Я не понимаю, AlexRK, что ты лыбишься. Ты ныл, что тебе не задают внятных вопросов. Вот тебе был внятный вопрос: M>
M>Как ты собираешься проверять, что все эти ифы и предикаты расставлены правильно? То есть каким образом ты будешь проверять, что все проверки сделаны правильно и в нужном порядке?
M>Где на него ответ? Ты написал простыню текста, которая к моему вопросу вообще не имеет никакого отношения. А потом еще удивляешься, когда я вас называю словоблудами и демагогами, неспособными ответить на простейшие вопросы
очевидно, проверять ровно так же как и в любом другом языке. Никакая типизация и никакой язык программирования не поможет тебе если ты неправильно перенес логику из требований в код. Непонятно почему у тебя вообще возник такой вопрос.
G>очевидно, проверять ровно так же как и в любом другом языке. Никакая типизация и никакой язык программирования не поможет тебе если ты неправильно перенес логику из требований в код. Непонятно почему у тебя вообще возник такой вопрос.
Он у меня не возник, он просто есть Я вот все жду ответа
G>Ну кстати это не аргумент. Может конкретно в вашей системе огромное количество денег, сил и времени тратится на написание тестов, которые можно было б не тратить в статических языках?
G>Иными словами это всего-лишь один пример, а надо говорить про статистику.
Ну, статистика, емнип, говорит, что ошибки типизации — в меньшинстве. Найте не найду, потому что гугл в последнее время мне не поддается
Здравствуйте, Mamut, Вы писали:
M>Ну, статистика, емнип, говорит, что ошибки типизации — в меньшинстве. Найте не найду, потому что гугл в последнее время мне не поддается
на фоне ошибок в бизнес-логике скорее всего в меньшинстве. Поэтому никто и не заморачивается со сложной типизацией
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[71]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>Нууу... Сложно сказать. Из того, что я пока видел из предложенного в двух ветках, там на каждое условие придется писать свой тип/параметр типа, которые в некоторых местах вообще непонятно, как будут выглядеть (см. последнюю строчку).
Последняя строчка выглядит так, что она как раз останется частью рантайм-функциональности. Т.е. задача не сводится к тому, чтобы математически доказать, что подобных условий в принципе возникнуть не может. Они могут возникнуть, и штатной функциональностью будет отказ от выполнения операции с возвратом рантайм-ошибки.
А в остальном — да, на каждое статически проверяемое условие будет свой параметр типа.
Это как бы не такая уж проблема в смысле объёма требований. Это в С++ или С# реализация может оказаться крайне громоздкой, а некоторые вещи вообще не взлетят (ну там, где параметр типа не Boolean, а что-то поинтереснее).
M>Если это — камень в мой огород, то это не я, честно-честно Я прекрасно понимаю, когда мне говорят, что типы помогают не складывать апельсины с крокодилами и помогают при рефакторинге
Не совсем в твой огород. В твой огород — камень про то, что ты периодически передёргиваешь в сторону того, что типы должны вообще всё-всё "за тебя" делать.
Вот как раз этого никто не обещал.
Мне нравится сама тема разговора — попытка скрестить "матан" передовиков типизации с "сермягой" прикладных направлений.
И коммуникационные проблемы тут вполне ожидаемы — теоретики не очень внятно представляют себе, что такое обработка заказа, а практики не очень понимают, чего вообще ожидать от типизации в частности и статической верификации контрактов вообще.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[73]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Mamut, Вы писали:
M>>Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).
_>Я тебе ответил в той темке: http://rsdn.ru/forum/philosophy/5971692.1
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>Нууу... Сложно сказать. Из того, что я пока видел из предложенного в двух ветках, там на каждое условие придется писать свой тип/параметр типа, которые в некоторых местах вообще непонятно, как будут выглядеть (см. последнюю строчку). S>Последняя строчка выглядит так, что она как раз останется частью рантайм-функциональности. Т.е. задача не сводится к тому, чтобы математически доказать, что подобных условий в принципе возникнуть не может. Они могут возникнуть, и штатной функциональностью будет отказ от выполнения операции с возвратом рантайм-ошибки. S>А в остальном — да, на каждое статически проверяемое условие будет свой параметр типа.
бинго
S>Это как бы не такая уж проблема в смысле объёма требований. Это в С++ или С# реализация может оказаться крайне громоздкой, а некоторые вещи вообще не взлетят (ну там, где параметр типа не Boolean, а что-то поинтереснее).
Все, что может быть выражено цепочкой if/else — будет работать. Каким бы сложным ни было свойство — ты всегда можешь сделать функцию по его проверке, которая будет возвращать bool — прошла проверка или нет. Свойство не обязано быть булевским само по себе. Скажем, цена заказа — это не булевское свойство. А вот превышает ли она литим, гарантирующий бесплатную доставку — это да/нет.
Или, в моем же примере, есть свойство "можно ли для этого ордера (в его нынешнем состоянии) поднять цену на данную величину". Это уже свойство, объединяющее несколько сущностей и выражающее отношения между ними.
Булевское свойство просто делается проще всего, поэтому я его реализовал напрямую в своем примере. Это не значит, что только булевские свойства возможны.
S>Мне нравится сама тема разговора — попытка скрестить "матан" передовиков типизации с "сермягой" прикладных направлений. S>И коммуникационные проблемы тут вполне ожидаемы — теоретики не очень внятно представляют себе, что такое обработка заказа, а практики не очень понимают, чего вообще ожидать от типизации в частности и статической верификации контрактов вообще.
Вот я — практик до не знаю мозга каких костей, я вообще не программер по образованию И по банкам работаю уже лет 15, так что про ордера (биржевые, правда) я знаю все
S>Тем, что там нету Load, зато есть runtime-проверки.
PROF_IF — это рантайм-проверка и есть.
ARK>>Видите там boost::enable_if? Функция increase_amount определена только в контексте, где на ее аргумент навешено требуемое свойство. C# такими шаблонными возможностями не обладает. S>Дело не в C#. Дело в том, что jazzer приписывает своему коду свойства, которых там и в помине нет. И вы его зачем-то поддерживаете
Какие именно?
ЗЫ Мне вообще удивительно, в одних постах ты пишешь так, что выглядит, будто ты все понял (правда, эти посты обычно Мамуту адресованы), а в других, типа этого — как будто все мимо. Как будто два разных человека пишут.
ЗЗЫ Сайту ощутимо не хватает фичи "упоминаний". В смысле, если где-то твой ник упомянули — ты мог прийти и отписаться. А то я чудом на этот пост попал.
M>>>Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).
_>>Я тебе ответил в той темке: http://rsdn.ru/forum/philosophy/5971692.1
Ну, ты почти прав. Всю задачу в итоге так никто и не осилил, все сдуваются после первого шага, предпочитая отмазываться «дальше и так все понятно». Уж не знаю, почему
Здравствуйте, Mamut, Вы писали:
M>Ну, ты почти прав. Всю задачу в итоге так никто и не осилил, все сдуваются после первого шага, предпочитая отмазываться «дальше и так все понятно». Уж не знаю, почему
M>>Ну, ты почти прав. Всю задачу в итоге так никто и не осилил, все сдуваются после первого шага, предпочитая отмазываться «дальше и так все понятно». Уж не знаю, почему
J>Наверное, потому что дальше и так все понятно?
Здравствуйте, Mamut, Вы писали:
M>>>Ну, ты почти прав. Всю задачу в итоге так никто и не осилил, все сдуваются после первого шага, предпочитая отмазываться «дальше и так все понятно». Уж не знаю, почему
J>>Наверное, потому что дальше и так все понятно?
M>Автору сообщения? Может быть.
А что _конкретно_ непонятно тебе?
Как проверить очередное свойство? Так это, вроде, очевидно.
Как быть, если свойств становится слишком много (если свойство, которое мы хотим гарантировать, слишком сложное, и запаришься выписывать индивидуальные свойства, его составляющие)? Так про это тоже есть в статье, читай после слов "Надеюсь, идея понятна".
Еще что-то?
M>>Автору сообщения? Может быть.
J>А что _конкретно_ непонятно тебе? J>Как проверить очередное свойство? Так это, вроде, очевидно. J>Как быть, если свойств становится слишком много (если свойство, которое мы хотим гарантировать, слишком сложное, и запаришься выписывать индивидуальные свойства, его составляющие)? Так про это тоже есть в статье, читай после слов "Надеюсь, идея понятна". J>Еще что-то?
Можно вместо тонны слов и «статьи, после слов надеюсь понятно» показать как это будет в коде?
Потому что написать «Надеюсь, идея понятна. Дополнительные требования навешиваются аналогично. Если элементарных свойств/требований становится слишком много, то можно их просто упаковать в мета-свойство IncreaseAmountOK» легко. Но почему-то никто так и не осилил больше одного шага
Я хочу увидеть это «метасвойство». Я хочу увидеть, как решается заявленное тобой «типы помогают при ad-hoc дизайне», ведь именно для этого в моей задаче три шага.
Я хочу увидеть, что да, действительно, после реализации «метасвойства», после которого «таким образом мы вернемся к простому первоначальному варианту», мы действительно вернемся к простому варианту, после которого можно будет действительно сказать, что «не сказать, что кода стало на 100500 порядков больше». Потому что тут где-то рядом Sinclair задал наводящий вопрос, и внезапно надо было прописывать еще дополнительные prop_if'ы.
Потому что мне действительно хочется увидеть полное решение моей задачи, в котором используются все громогласные заявления, начиная отсюда
. Этот вопрос я уже задавал, но задам еще раз: почему все приводят короткие, неполные решения с заявлением «ну, дальше все понятно» и не могут осилить одно полное решение? Но после этого я должен поверить, что это все круто будет работать для гораздо более разветвленной
Здравствуйте, Mamut, Вы писали:
M>>>Автору сообщения? Может быть.
J>>А что _конкретно_ непонятно тебе? J>>Как проверить очередное свойство? Так это, вроде, очевидно. J>>Как быть, если свойств становится слишком много (если свойство, которое мы хотим гарантировать, слишком сложное, и запаришься выписывать индивидуальные свойства, его составляющие)? Так про это тоже есть в статье, читай после слов "Надеюсь, идея понятна". J>>Еще что-то?
M>Можно вместо тонны слов и «статьи, после слов надеюсь понятно» показать как это будет в коде?
имей совесть. Там есть пример кода, прямо в статье. Ты почему-то делаешь вид, что его там нет. Наверное, ты просто перепутал форум и решил, что мы в КСВ.
Попробуй все же прочитать и осмыслить то, что написано в статье, не бросаясь отвечать на уровне коленного рефлекса.
M>Потому что написать «Надеюсь, идея понятна. Дополнительные требования навешиваются аналогично. Если элементарных свойств/требований становится слишком много, то можно их просто упаковать в мета-свойство IncreaseAmountOK» легко. Но почему-то никто так и не осилил больше одного шага
Там есть пример кода, прямо в статье.
M>Я хочу увидеть это «метасвойство». Я хочу увидеть, как решается заявленное тобой «типы помогают при ad-hoc дизайне», ведь именно для этого в моей задаче три шага.
просто добавляешь дополнительные проверки внутри can_increase_amount.
M>Я хочу увидеть, что да, действительно, после реализации «метасвойства», после которого «таким образом мы вернемся к простому первоначальному варианту», мы действительно вернемся к простому варианту, после которого можно будет действительно сказать, что «не сказать, что кода стало на 100500 порядков больше». Потому что тут где-то рядом Sinclair задал наводящий вопрос, и внезапно надо было прописывать еще дополнительные prop_if'ы.
Там есть пример кода, прямо в статье.
M>Потому что мне действительно хочется увидеть полное решение моей задачи, в котором используются все громогласные заявления, начиная отсюда
. Этот вопрос я уже задавал, но задам еще раз: почему все приводят короткие, неполные решения с заявлением «ну, дальше все понятно» и не могут осилить одно полное решение? Но после этого я должен поверить, что это все круто будет работать для гораздо более разветвленной
реальности?
просто добавляешь дополнительные проверки внутри can_increase_amount.
M>Хех. Кстати. Перечитал свои условия для шага 1, и понял, что у тебя не реализован даже шаг 1
M>Я умолчу о том, что все, как огня избегают отвечать на вопрос, а как все это тестировать
А как ты тестируешь, что у тебя в int i действительно int, а не строка? Ответ — никак. Это невозможно (если только ты не расстреливаешь память или в компиляторе не водятся баги), и тестировать это смысла нет.
M>Но это отдельный вопрос (хотя он и был, по сути, в самом
J>Булевское свойство просто делается проще всего, поэтому я его реализовал напрямую в своем примере. Это не значит, что только булевские свойства возможны. J>Вот я — практик до не знаю мозга каких костей, я вообще не программер по образованию И по банкам работаю уже лет 15, так что про ордера (биржевые, правда) я знаю все
Ну вот тем не менее мы так и не увидели примера кода, в котором
а) есть загрузка ордера из базы
б) нет функции обработки, которая бросает runtime ошибку для "статически-верифицируемых" свойств.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я вот все жду ответа 
