M>>Я тоже на с++ сто лет не писал, и компилятора у меня под рукой нет. Но почему-то именно я должен возиться и почему-то мне внезапно хочется взять пример с PROP_IF
G>ну потому что именно ты хочешь получить работающий пример
Да, я действительно хочу увидеть работающий пример с больше, чем двумя условиями. Ты уж извини, но это я не я постоянно говорю о «форсироании программистов», «помощи при ад-хок изменении требований» и прочая и прочая и прочая. Но почему-то за полтора месяца разговоров я вижу только разговоры
Здравствуйте, Mamut, Вы писали:
M>Это было третьего февраля. С тех пор все крутится вокруг одного и того же, что я описал (не в первый раз, опять же) тут
Если ты внимательно перечитаешь топик, то увидишь ответы на все вопросы. Тебе поэтому никто пример и не приводит, потому что все узнали все, что хотели и дальше возиться лень.
M>ЗЫ. Интересно, что вначале ты, по сути, говорил
Я и сейчас так говорю. Ты похоже просто уже запутался в том, кто, что утверждает. Идет обсуждение сразу нескольких вопросов, теоретической возможности и практической применимости. Твои оппоненты о теории, ты о практике. Если ты пройдешься по сообщениям, то увидишь, что:
— Некоторый класс ошибок отловить можно (1.eur + 1.usd)
— Заставить программиста сделать необходимые проверки можно (Optional и PROP_IF)
— Лично я считаю, что PROP_IF в банковском софте себя не окупит. А вот что-то типа Optional и типизированных валют/счетов вполне может быть полезно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[99]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>>>Мамуту надо. В частности, понять и увидеть как все пафосные заявления работают на полноценном примере, где больше, чем два условия.
ARK>>Раз надо Мамуту, значит Мамут и должен приложить усилия. Вроде так.
M>Я уже полтора месяца прикладываю усилия.
M>>>Но да, я, видимо, должен проникнуться и поверить, что все это прекрасно работает на гораздо более сложных примерах, ага. ARK>>Абсолютно не должен. Но должен понимать, что из того факта, что никто не привел "полноценный пример", ничего не следует.
M>То, что за полтора месяца мне рассказали тучу офигительных историй, и ничего больше, можно сделать много выводов.
Да как бы вывод-то один — статика решает в первую очередь проблемы статики. Любые условия, которые определяются в рантайме будут валить программу так же как и валили. Да, мы можем наворотить типов на каждый случай заказа, но тогда добавление дополнительных условий потребует перекапывать систему типов.
То есть из наборов условий мы получим портянки преобразований типов в духе RawOrder -> CheckedOrder -> PaidOrder -> CompletedOrder. Лучше ли это? А черт его знает.
G>Я и сейчас так говорю. Ты похоже просто уже запутался в том, кто, что утверждает. Идет обсуждение сразу нескольких вопросов, теоретической возможности и практической применимости. Твои оппоненты о теории, ты о практике. Если ты пройдешься по сообщениям, то увидишь, что:
В том-то и дело, что мои оппоненты говорят строго и сугубо о теории. Об этом я тоже не раз говорил. Как только переходим к практике (а теория без практики мертва, не так ли?), как все — тишина, и мертвые с косами стоят
G>- Некоторый класс ошибок отловить можно (1.eur + 1.usd) G>- Заставить программиста сделать необходимые проверки можно (Optional и PROP_IF) G>- Лично я считаю, что PROP_IF в банковском софте себя не окупит. А вот что-то типа Optional и типизированных валют/счетов вполне может быть полезно.
Можно это наконец-то увидеть на реальных примерах? Ну, достаточно полноценных, и чтобы там было больше двух условий?
Здравствуйте, Mamut, Вы писали:
G>>- Некоторый класс ошибок отловить можно (1.eur + 1.usd) G>>- Заставить программиста сделать необходимые проверки можно (Optional и PROP_IF) G>>- Лично я считаю, что PROP_IF в банковском софте себя не окупит. А вот что-то типа Optional и типизированных валют/счетов вполне может быть полезно.
M>Можно это наконец-то увидеть на реальных примерах? Ну, достаточно полноценных, и чтобы там было больше двух условий?
нет. предлагаю считать, что это все невозможно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[100]: Haskell нужен! (в Standard Chartered Bank)
MA>То есть из наборов условий мы получим портянки преобразований типов в духе RawOrder -> CheckedOrder -> PaidOrder -> CompletedOrder. Лучше ли это? А черт его знает.
А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд?
Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать?
Базовая проблема в том, что в программе в явном виде отсутствует ЖЦ ордера, поэтому компилятор не может ничем помочь.
Re[101]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, m.aksenov, Вы писали:
MA>>То есть из наборов условий мы получим портянки преобразований типов в духе RawOrder -> CheckedOrder -> PaidOrder -> CompletedOrder. Лучше ли это? А черт его знает. G>А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд? G>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать?
G>Базовая проблема в том, что в программе в явном виде отсутствует ЖЦ ордера, поэтому компилятор не может ничем помочь.
Можно попробовать сделать миксины, но по сути это будет то же самое. Еще интересно как персистентность в таком случае организовывать. То есть, как определять состояние заказа: по атрибутам или по тегу типа в реляционной модели? Если по атрибутам, то нужен будет код, который возвращает по набору атрибутов корректный тип заказа, а значит и выполняет все проверки, прогоняя цепочку преобразований снова. Если по тегу типа, то такой проблемы нет, но модель будет загрязняться дополнительным отношением. А если правила изменились с момента сохранения правила в базу? Например, какая-то базовая ставка повысилась? В общем, больше вопросов, чем ответов.
Дело вот в чем — имея мощные инструменты метапрограммирования можно нагенерировать кода и на динамике, так как кодогенерация типизации ортогональна. То есть я могу взять ту же Clojure, написать макры и eDSL, который в кложе получается естественным образом, и работать. Сложность проверок уйдет просто на другой уровень — на создание макроописаний. Более того, можно подцепить интересные штуки типа clara для описания бизнес-логики (примеры).
Re[101]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, gandjustas, Вы писали:
G>А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд?
G>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать?
У меня именно это и реализовано: http://rsdn.ru/forum/philosophy/5949645.1
Здравствуйте, gandjustas, Вы писали:
G>А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд? G>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать?
Да всё без проблем реализуется. Тут вопрос в другом. Если мы возьмём исключительно задачу вида "загрузить из БД, сделать одну элементарную операцию, сохранить в БД" (а именно на таком случае стал настаивать Mamut после того, как ему продемонстрировали эффективность работы для других случаев), то смысла в этом особого не будет. Потому как это получится просто перекидывание проверок в другое место исходников. Более того, такой код может даже хуже получиться (но всё равно без проблем реализуемо! Только вот зачем...) из-за большей многословности и размазывания проверок по разным местам, вместо одной компактной функции. И совсем другая ситуация получается, если в нашей задаче будет не одна элементарная операция, а некая последовательность операций. В этом случае проверки останутся только на входе в цепочку операций, а дальше корректность обеспечит система типов (причём с гарантией). В этом случае использование статической типизации может принести сразу несколько бонусов: и гарантированная корректность и уменьшение числа проверок в рантайме. Однако Mamut (да и Sinclair вслед за ними) уже не хотят рассматривать такую задачу, а настаивают на демонстрации преимуществ статической типизации исключительно для ситуации "одна элементарная операций (с кучей предусловий) в транзакции". )))
Re[102]: Haskell нужен! (в Standard Chartered Bank)
_>Да всё без проблем реализуется. Тут вопрос в другом. Если мы возьмём исключительно задачу вида "загрузить из БД, сделать одну элементарную операцию, сохранить в БД" (а именно на таком случае стал настаивать Mamut после того, как ему продемонстрировали эффективность работы для других случаев)
Для каких «других» случаев? Никто ничего не продемонстрировал
_>И совсем другая ситуация получается, если в нашей задаче будет не одна элементарная операция, а некая последовательность операций.
Ой. Ты не поверишь. В моей задачи есть таки последовательность операций.
_>В этом случае проверки останутся только на входе в цепочку операций, а дальше корректность обеспечит система типов (причём с гарантией).
Ну, примеры, примеры где?
_>В этом случае использование статической типизации может принести сразу несколько бонусов: и гарантированная корректность и уменьшение числа проверок в рантайме. Однако Mamut (да и Sinclair вслед за ними) уже не хотят рассматривать такую задачу, а настаивают на демонстрации преимуществ статической типизации исключительно для ситуации "одна элементарная операций (с кучей предусловий) в транзакции". )))
Ну покажи пример неэлементарной операции Мы готовы рассматривать любые случаи, любые операции. Только вот никто не показывает Все упирается в два условия и «а дальше все понятно»
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд? G>>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать?
_>Да всё без проблем реализуется. Тут вопрос в другом. Если мы возьмём исключительно задачу вида "загрузить из БД, сделать одну элементарную операцию, сохранить в БД" (а именно на таком случае стал настаивать Mamut после того, как ему продемонстрировали эффективность работы для других случаев), то смысла в этом особого не будет. Потому как это получится просто перекидывание проверок в другое место исходников. Более того, такой код может даже хуже получиться (но всё равно без проблем реализуемо! Только вот зачем...) из-за большей многословности и размазывания проверок по разным местам, вместо одной компактной функции. И совсем другая ситуация получается, если в нашей задаче будет не одна элементарная операция, а некая последовательность операций. В этом случае проверки останутся только на входе в цепочку операций, а дальше корректность обеспечит система типов (причём с гарантией). В этом случае использование статической типизации может принести сразу несколько бонусов: и гарантированная корректность и уменьшение числа проверок в рантайме. Однако Mamut (да и Sinclair вслед за ними) уже не хотят рассматривать такую задачу, а настаивают на демонстрации преимуществ статической типизации исключительно для ситуации "одна элементарная операций (с кучей предусловий) в транзакции". )))
А можно пример цепочки преобразований, где это реально поможет? Ну, то есть я примерн представляю развесистый бизнес-процесс с кучей шагов, но это ж на каждом шаге будет новый тип (для гарантированных проверок). А это для одной (логически) сущности мы создаем десятки типов на _каждый_ сложный бизнес-процесс. Стоит оно того? Для тех самых "сложных" случаев.
Re[102]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>А если это будут mixins, типа Order<Order.Raw> -> Order<Order.Checked> итд?
G>>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать? J>У меня именно это и реализовано: http://rsdn.ru/forum/philosophy/5949645.1
Это далеко не то, что надо.
G>>Базовая проблема в том, что в программе в явном виде отсутствует ЖЦ ордера, поэтому компилятор не может ничем помочь. J>Это о чем?
О том, что надо дать компилятору информацию о состояниях Order, чтобы эта информация была доступна в compile time. В большинстве языков это можно сделать только руками наплодив типы OrderRaw, OrderChecked, OrderShipped и OrderCompleted со своим набором методов. А в языках метапрограммированием и\или mixin_ами можно такие типы нагенерировать.
Как нужный тип ордера поднимать из базы — не вопрос. Мы по сценарию знаем что нам нужен OrderChecked и запрашиваем из хранилища именно этот тип, а ORM проверяет атрибуты и кидает уже runtime exception.
Re[103]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, gandjustas, Вы писали:
G>>>Писать такое руками гемор еще тот, но нагенерить по метаинформации можно. Списки типов в C++ или продвинутые макросы не помогут такое реализовать? J>>У меня именно это и реализовано: http://rsdn.ru/forum/philosophy/5949645.1
Здравствуйте, Mamut, Вы писали:
M>Для каких «других» случаев? Никто ничего не продемонстрировал
Не продемонстрировал? ) Совсем? ))) А как же ты тогда писал мне такое?
Это они видны в твоем примере, потому что тебе так удобно. На практике SendOrder запишет в заказе поле is_sent=true и запишет в базу. Изменение суммы заказа, повторю, может произойти через неделю после того, как заказ отправился. И никаким переведением в «OnlyDecrease» SendOrder не будет заниматься, потому что это не ее область ответственности.
Т.е. ты прекрасно увидел и понял демонстрацию работы статической типизации в моём примере. Но у меня там шли подряд 3 элементарные операции подряд, а не одна. И ты сразу начал требовать демонстрации именно для случая одной операции на транзакцию.
M>Ну покажи пример неэлементарной операции Мы готовы рассматривать любые случаи, любые операции. Только вот никто не показывает Все упирается в два условия и «а дальше все понятно»
Здравствуйте, m.aksenov, Вы писали:
MA>А можно пример цепочки преобразований, где это реально поможет? Ну, то есть я примерн представляю развесистый бизнес-процесс с кучей шагов, но это ж на каждом шаге будет новый тип (для гарантированных проверок). А это для одной (логически) сущности мы создаем десятки типов на _каждый_ сложный бизнес-процесс. Стоит оно того? Для тех самых "сложных" случаев.
Если добавлять новые типы например с помощью параметра шаблона, то добавление новых типов не требует никаких условий. Я уже показывал здесь пример на эту тему: http://rsdn.ru/forum/philosophy/5971692
M>>Ну покажи пример неэлементарной операции Мы готовы рассматривать любые случаи, любые операции. Только вот никто не показывает Все упирается в два условия и «а дальше все понятно»
_>Ты уже совсем забыл этот http://rsdn.ru/forum/philosophy/5971692
«простейший пример с предусловиями» и все таки попробуй его реализовать своей статической типизацией. Благо, у меня там есть «подряд идут три элементарные операции, а не одна».
Вы все решаете какие-то свои простейшие примеры уровня «hello, world», но при этом уверены, что они сложнее, чем моя задача. Ты сделай усилие и почитай мою задачу. Там есть и предусловия, и последовательность действий, зависящая от этих предусловий (надо сделать risk check, auth запрос, capture запрос, увеличить сумму), и ad-hoc изменения требований... Ну то есть ровным счетом все то, в чем, согласно вашим многочисленным заявлениям, стат. типизация прекрасно помогает.
«простейший пример с предусловиями» и все таки попробуй его реализовать своей статической типизацией. Благо, у меня там есть «подряд идут три элементарные операции, а не одна».
M>Вы все решаете какие-то свои простейшие примеры уровня «hello, world», но при этом уверены, что они сложнее, чем моя задача. Ты сделай усилие и почитай мою задачу. Там есть и предусловия, и последовательность действий, зависящая от этих предусловий (надо сделать risk check, auth запрос, capture запрос, увеличить сумму), и ad-hoc изменения требований... Ну то есть ровным счетом все то, в чем, согласно вашим многочисленным заявлениям, стат. типизация прекрасно помогает.
M>Но, почему-то, никто так и не родил решения
ОК, тогда я твою задачу неправильно понял (а ты меня ни разу не поправил).
Раз это всё действия, а не просто проверки, ты можешь добавить в описание свой задачи список действий и предусловий на них?
Потому что я предполагал, что это все — просто огромная толпа предусловий к increase_amount.
Я правильно понял, что, помимо increase_amount, еще есть действия risk check, auth запрос, capture запрос?
Если да, то в каких случаях каждое из них можно звать, а в каких — нельзя?
J>ОК, тогда я твою задачу неправильно понял (а ты меня ни разу не поправил).
Как ее можно не понять, если она написана прямым текстом простейшими предложениями?
J>Раз это всё действия, а не просто проверки, ты можешь добавить в описание свой задачи список действий и предусловий на них? J>Потому что я предполагал, что это все — просто огромная толпа предусловий к increase_amount.
А сделать усилие и прочитать?
J>Я правильно понял, что, помимо increase_amount, еще есть действия risk check, auth запрос, capture запрос?
Прочти задачу
J>Если да, то в каких случаях каждое из них можно звать, а в каких — нельзя?
Здравствуйте, Mamut, Вы писали:
J>>Давай я еще раз задам вопросы, котрые ты стер — у тебя не займет много времени на них ответить: J>>
J>>Непонятно, как я добавлял второе свойство? Если так, то с этого надо было начинать. Что конкретно непонятно?
M>Я пять раз задал тебе один и тот же вопрос. Ты так и не осилил ни ответить на него, ни привести свое решение.
То есть даже да/нет не можешь ответить? ОК, уровень конструктивности понятен. Sapienti sat.
J>>Ну и до кучи J>>
M>>>Пока что ты продолжаешь называть меня тупым
J>>ссылку или извинись.
M>Все твои отсылки к своей «статье», в которой якобы все описано, в ответ на любые мои вопросы.
То есть ссылки не будет, извинений тоже.
Ну что ж, по крайней мере, будь так добр впредь не выкладывать оскорбительную отсебятину под видом цитирования моих слов.
Хотя, я думаю, ты это также проигнорируешь.
Но должен понимать, что из того факта, что никто не привел "полноценный пример", ничего не следует.
