Здравствуйте, Sinclair, Вы писали:
S>Не, вдвое больше кода — это потому, что без try_increase_amount ничего не работает. Поэтому вам приходится писать try_increase_amount в дополнение к "безопасной" increase_amount.
Вот я для кого написал "Не будет никакого try_to_change_amount, а будет какой-нть process_order", интересно?
J>>Воот, теперь вы постепенно начинаете понимать суть задачи. Дело даже не в том, что нет многократно вызываемых функций.
Дело именно в этом. Ты придумал одну единственную формулировку задачи, где подход не сработает, и вместо того, чтоб сразу сказать, что вот ты тут придумал такой граничный случай (и я бы с тобой согласился, что да, в этом случае оверкилл), ты это выдаешь за общее место и на этом основании размазываешь подход в целом. Как ты там сказал выше — у тебя черный пояс по этому делу?
J>>Так что да, если у тебя программа настолько примитивна, что каждая функция зовется ровно из одного места программы — тогда да. Но тогда тебе и функция не нужна, вообще говоря, это чисто синтаксический сахар получается. Но ты, имхо, окажешься в меньшинстве с такой программой.
S>Подождём Мамута — пусть он скажет, из скольки мест вызывается increase_amount.
А чего его ждать, если он задачу изначально сформулировал в терминах кучи условий на один единственный вызов increase_amount.
Он нигде не давал задачу вида: а закодируйте мне вот такую логику.
Он (ну я грешным делом так подумал) просил просто продемонстрировать общий подход.
Подход был продемонстрирован.
Кто ж знал, что это вся задача и есть (ну или, по крайней мере, ты ее представляешь таковой)
В общем, тема скатилась в классическое КСВ, увы А обещала быть интересной.
ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
M>>>>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения J>>>Как я говорил, все зависит от того, сколько проверок ты захочешь перенести в типы. Можешь оставить вот так, как есть, а можешь разнести на минипроверки и свойство на каждое.
M>>Перенеси, пожалуйста.
J>Да ты мастер стирать ответы, я вижу.
Что именно в твоем ответе я не должен был стирать? Твою шутку про «реализацию кода»? Она нерелевантна, я ее стер. Сразу за этой шуткой идет текст, который я оставил.
M>>Результат?
J>Результат очень простой — ты просто стираешь то, что тебе не нравится.
Я стираю много текста ни о чем. Я прошу от тебя одного: покажи мне пожалуйста в коде. Законченном. Как это будет выглядеть.
Ты уже в десятый раз говоришь о том, что, мол, в статье все написано. Заметь, я уже несколько раз тебе пишу:
Покажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать.
Покажи мне пошагово, как и где твой код, реализующий шаг 1 легким движением руки превращается в код, реализующий шаг два (напомню: именно ты говорил о том, что типы позволяют легко справляться с ad-hoc изменениями). Почему у тебя все заканчивается строго и исключительно на «там дальше просто/очевидно/поянтно»?
Вот мне не просто, не очевидно и не понятно Поэтому я прошу, чтобы мне показали что-нибудь более полное, чем незаконченный код, который «ну дальше очевидно»
Ну и кто из нас занимается стиранием неудобных ответов/вопросов? Точно не я. Заметь: при всем твоем пафосе ты так и не осилил полноценно решить даже первый шаг моей задачи. Но оскорблять меня и других собеседников — о да, это ты умеешь
J>А чего его ждать, если он задачу изначально сформулировал в терминах кучи условий на один единственный вызов increase_amount.
Ты притащил сюда презентацию из банка. Я тебе дал задачу из банка. ВНЕЗАПНО «задача не такая»
J>Он нигде не давал задачу вида: а закодируйте мне вот такую логику.
Хорошо: закодируй мне такую логику. От начала до конца. Безо всяких «ну там дальше все очевидно». Мне не очевидно
J>Он (ну я грешным делом так подумал) просил просто продемонстрировать общий подход. J>Подход был продемонстрирован.
«Общий подход» — это сферовакуумный конь.
J>ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
Ну вот покажи полноценное решение такой задачи со своим подходом на типах. Безо всякого «вот тут очевидно» и «вы тупые, статьи не читаете»
Здравствуйте, Mamut, Вы писали:
M>>>>>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения J>>>>Как я говорил, все зависит от того, сколько проверок ты захочешь перенести в типы. Можешь оставить вот так, как есть, а можешь разнести на минипроверки и свойство на каждое.
M>>>Перенеси, пожалуйста.
J>>Да ты мастер стирать ответы, я вижу.
M>Что именно в твоем ответе я не должен был стирать? Твою шутку про «реализацию кода»? Она нерелевантна, я ее стер. Сразу за этой шуткой идет текст, который я оставил.
А это, внезапно, не шутка была. Помедитируй над этим. Соотнеси с текстом статьи.
M>>>Результат?
J>>Результат очень простой — ты просто стираешь то, что тебе не нравится.
M>Я стираю много текста ни о чем. Я прошу от тебя одного: покажи мне пожалуйста в коде. Законченном. Как это будет выглядеть.
У меня нет твоей задачи, "законченной". Есть только вызов increase_amount. Это задача ни о чем, это и не задача даже. Ее можно решить как одним мега-свойством IncreaseAmountOK, так и кучей элементарных свойств или какой-то их комбинации.
Я не знаю, какие из элементарных условий, составляющие can_increase_amount, тебе могут понадобиться в других местах — поэтому не могу предложить адекватного разбиения. Без разбиения это будет просто то, что я показал выше, но ты почему-то считаешь это шуткой.
M>Покажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать.
я показал, ты стер
M>Покажи мне пошагово, как и где твой код, реализующий шаг 1 легким движением руки превращается в код, реализующий шаг два (напомню: именно ты говорил о том, что типы позволяют легко справляться с ad-hoc изменениями). Почему у тебя все заканчивается строго и исключительно на «там дальше просто/очевидно/поянтно»?
Потому что у тебя там штук 20 условий, мне их кодировать тупо в лом. Тем более если они не нужны по-одному, а только все скопом, что упаковывается в can_increase_amount (то, что я показал выше, то, что ты назвал шуткой).
M>Ну и кто из нас занимается стиранием неудобных ответов/вопросов? Точно не я. Заметь: при всем твоем пафосе ты так и не осилил полноценно решить даже первый шаг моей задачи. Но оскорблять меня и других собеседников — о да, это ты умеешь
Словоблудами и сказочниками (и прочая, лень искать эпитеты) тут всех вокруг называешь именно ты. Причем я не вижу, чтоб ты делал какие-то усилия, чтоб разобраться, если честно. Больше выглядит как "я вас тут размажу, как вы ни упирайтесь". Не особо конструктивная позиция.
А, да, еще "пафос". Вместо того, чтобы разобраться, ты просто обзываешься. Легче легкого назвать все, что пишет собеседник, пафосом и сказками. Только вот странно потом удивляться тому, что собеседник почему-то не горит желанием выкатить на-гора кучу кода, чтоб получить очередную порцию издевательств. Спасибо.
Здравствуйте, Mamut, Вы писали:
J>>А чего его ждать, если он задачу изначально сформулировал в терминах кучи условий на один единственный вызов increase_amount.
M>Ты притащил сюда презентацию из банка. Я тебе дал задачу из банка. ВНЕЗАПНО «задача не такая»
Я притащил презентацию не из своего банка. Я не видел их кода, не знаю, какие конкретно у них задачи были решены на типах. Такчто хватит с меня спрашивать за содержание этой презентации. Не я ее писал.
Если ты лично считаешь, что там все вранье, несмотря на то, что их система уже лет 8 работает — твое право
J>>Он нигде не давал задачу вида: а закодируйте мне вот такую логику.
M>Хорошо: закодируй мне такую логику. От начала до конца. Безо всяких «ну там дальше все очевидно». Мне не очевидно
какую логику? Где логика? Есть миллион условий на то, когда можно увеличивать amount. Это ты называешь логикой?
J>>Он (ну я грешным делом так подумал) просил просто продемонстрировать общий подход. J>>Подход был продемонстрирован. M>«Общий подход» — это сферовакуумный конь.
Ну конечно же, как же иначе. Общих подходов не бывает, их демонстрировать не надо. Любой подход должен доказать совю полезность в задаче увеличения amount-а (ну или расстановки 8 ферзей, по вкусу), иначе он не имеет смысла и объявляется пафосным сфероконем, а код, который демонстрирует работу подхода на двух условиях, ничего не значит, потому что не показана работа на 20 условиях.
Я боюсь представить, как бы ты читал про циклы. Тебя наверняка обычное описание циклов из книжки не устроило бы. Тебе понадобился бы либо цикл по 20 счетчикам сразу, либо 20 вложенных циклов, а лучше — и то, и другое. И пока тебе не продемонстрируют код с 20 счетчиками и 20 уровнями вложенности — ты будешь говорить, что циклы — это вакуумный сфероконь, сказки, пафос и словоблудие.
J>>ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
M>Ну вот покажи полноценное решение такой задачи со своим подходом на типах. Безо всякого «вот тут очевидно» и «вы тупые, статьи не читаете»
Какой задачи? Где она? Миллион условий на то, когда можно увеличивать amount? Ну и тупым я тебя нигде не обзывал, впредь воздержись от подобных "цитат", если только не планируешь окончательно потерять лицо.
M>>Я стираю много текста ни о чем. Я прошу от тебя одного: покажи мне пожалуйста в коде. Законченном. Как это будет выглядеть.
J>У меня нет твоей задачи, "законченной". Есть только вызов increase_amount. Это задача ни о чем, это и не задача даже.
Это задача из банка. Ты же тут притащил презенетацию из банка про типы. Ты думаешь у них что-то сильно другое?
J>Ее можно решить как одним мега-свойством IncreaseAmountOK, так и кучей элементарных свойств или какой-то их комбинации.
Можно наконец-то увидеть это решение? Хоть мегасвойством хоть комбинацией? Я слышу много разговоров о том, как это можно решить и ноль решений
Да. Мне непонятно, как это решить, несмотря на тот кусок кода, что ты привел ПОтому что твой кусок кода не отвечает на вопросы:
— что будет, когда условий больше двух
— как реализовать то самое «мета-свойство»
J>Потому что у тебя там штук 20 условий, мне их кодировать тупо в лом. Тем более если они не нужны по-одному, а только все скопом, что упаковывается в can_increase_amount (то, что я показал выше, то, что ты назвал шуткой).
Давай я тебя процитирую тебя снова:
Надеюсь, идея понятна. Дополнительные требования навешиваются аналогично. Если элементарных свойств/требований становится слишком много, то можно их просто упаковать в мета-свойство IncreaseAmountOK, которое
И снова задам свой вопрос:
окажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать.
Покажи мне пошагово, как и где твой код, реализующий шаг 1 легким движением руки превращается в код, реализующий шаг два (напомню: именно ты говорил о том, что типы позволяют легко справляться с ad-hoc изменениями). Почему у тебя все заканчивается строго и исключительно на «там дальше просто/очевидно/поянтно»?
Вот мне не просто, не очевидно и не понятно Поэтому я прошу, чтобы мне показали что-нибудь более полное, чем незаконченный код, который «ну дальше очевидно»
Что тебе не нравится в этом вопросе? Что в этом вопросе неконструктивного, и что именно ты тут считаешь «стиранием неудобных ответов» и «нежеланием конструктивного спора»? Я многого прошу?
M>>Покажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать. J>я показал, ты стер
Это называется не показал. Это называется послал на три буквы.
M>>Ну и кто из нас занимается стиранием неудобных ответов/вопросов? Точно не я. Заметь: при всем твоем пафосе ты так и не осилил полноценно решить даже первый шаг моей задачи. Но оскорблять меня и других собеседников — о да, это ты умеешь
J>Словоблудами и сказочниками (и прочая, лень искать эпитеты) тут всех вокруг называешь именно ты. Причем я не вижу, чтоб ты делал какие-то усилия, чтоб разобраться, если честно.
Я пытаюсь Я постоянно задаю вопросы типа: что будет, если условий будет не одно, не два, а три-пять-десять. Твои ответы показать? Я задаю вопросы типа: у нас нет никакого SendOrder перед increase_amount, у нас заказ приходит как есть, из базы, и с ним надо работать. Ответы показать? Я задаю вопросы типа: у нас требования меняются, ты говоришь, типы помогут в этом, покажи на примере. Ответ хоть один появился? Я говорю: я не представляю, как реализуется свойство IncreaseAmountOK, можно увидеть, как оно реализуется и связывается со всем остальным кодом. Где хоть один ответ?
Ну и т.п.
J>А, да, еще "пафос". Вместо того, чтобы разобраться, ты просто обзываешься.
Я пытаюсь разобраться. Я тебя не даром прошу сделать простейшее:
— решить хотя бы первый пункт моей задачи
— показать, как типы хорошо помогают при с ad-hoc программировании (твое утверждение, поэтому оно есть в здаче)
— если ни то н идругое, показать мне тот самое «понятноочевидное мета-свойство IncreaseAmountOK», потому что мне не понятно и не очевидно, как оно пишется.
Пока что ты продолжаешь называть меня тупым и постоянно тыкаешь своим сообшщением, в котором нет ни первого ни второго ни третьего. Ну и да, несмотря на понятность и очевидность, тебе уже внезапно писать «20 условий», хотя в задаче их далеко не 20. 20 их в реальной задаче, и я не устану повторять, что реальную задачу вы всем скопом вообще не осилите решить. Несмотря на громкие заявления про «можно решить мега-свойством или комбинацией элементарных свойств»
J>>>Он нигде не давал задачу вида: а закодируйте мне вот такую логику. M>>Хорошо: закодируй мне такую логику. От начала до конца. Безо всяких «ну там дальше все очевидно». Мне не очевидно J>какую логику? Где логика? Есть миллион условий на то, когда можно увеличивать amount. Это ты называешь логикой?
Ага. Внезапно тебе уже не нравится логика. Что ты подразумеваешь под словом «логика»?
J>>>ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
M>>Ну вот покажи полноценное решение такой задачи со своим подходом на типах. Безо всякого «вот тут очевидно» и «вы тупые, статьи не читаете»
J>Какой задачи? Где она?
Выделенное.
J>Миллион условий на то, когда можно увеличивать amount?
Не миллион. Всего четыре (если не ошибаюсь) в моей изначальной задаче.
Здравствуйте, jazzer, Вы писали:
J>Это будет ошибка соответствия кода требованиям. Она никак автоматически не решается. Даже если требования выразить формально и на их основе сгенерить код программы — всегда останется открытым вопрос соответствия формального описацию тому, что имел в виду заказчик.
Ещё раз: внося требование в сигнатуру функции, вы просто делаете "заметку на память": "не забыть проверить значение аргумента перед вызовом и выкинуть исключение".
А Мамут вместо этой "заметки" просто пишет проверку и выброс исключения. Что это означает? Что ни один из вас не забыл выполнить эту проверку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[75]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, jazzer, Вы писали:
J>Вот я для кого написал "Не будет никакого try_to_change_amount, а будет какой-нть process_order", интересно?
Понятия не имею. Наверное, для тех, кто никогда в жизни не писал системы обработки заказов, и может поверить в эту смелую фантазию.
J>Дело именно в этом. Ты придумал одну единственную формулировку задачи, где подход не сработает, и вместо того, чтоб сразу сказать, что вот ты тут придумал такой граничный случай (и я бы с тобой согласился, что да, в этом случае оверкилл), ты это выдаешь за общее место и на этом основании размазываешь подход в целом.
Вы что-то путаете. Формулировка задачи была дана выше в топике. За общее место я ничего не выдаю — я вам уже тридцать сообщений пишу, что для этой задачи этот подход неприемлем.
Это вы почему-то всё время съезжаете с задачи процессинга ордеров на какой-то вымышленный "общий случай".
J>А чего его ждать, если он задачу изначально сформулировал в терминах кучи условий на один единственный вызов increase_amount.
J>Он нигде не давал задачу вида: а закодируйте мне вот такую логику.
Да ладно! А я вот вижу, что он попросил закодировать именно такую логику. И даже привёл своё решение. J>Он (ну я грешным делом так подумал) просил просто продемонстрировать общий подход.
Нет. Он уже раз семьдесят написал, что "общий подход" ему известен. И про то, что он не даёт складывать метры с килограммами, мы с ним тоже в курсе.
Вопрос был про решение конкретных задач по программированию бизнес-логики. J>Подход был продемонстрирован. J>ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
Ок, из разных мест. Хорошо. Наверное, тогда вы можете продемонстрировать свой пример, в котором от всех этих украшательств есть какая-то польза?
Ну, кроме творческого разнообразия — типа, что в одном месте при проверке бросается исключение, во втором возвращается код ошибки, а в третьем ветка else просто не содержит никакого кода?
В приведённых вами примерах ровно никакой пользы нет — код бросает те же исключения в тех же ситуациях. И те ошибки, которые может "отловить" ваш код, в безтиповом коде вообще не возникают от слова "никак".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[76]: Haskell нужен! (в Standard Chartered Bank)
J>>Он нигде не давал задачу вида: а закодируйте мне вот такую логику. S>Да ладно! А я вот вижу, что он попросил закодировать именно такую логику. И даже привёл своё решение.
Здравствуйте, Mamut, Вы писали:
J>>>>Он нигде не давал задачу вида: а закодируйте мне вот такую логику. M>>>Хорошо: закодируй мне такую логику. От начала до конца. Безо всяких «ну там дальше все очевидно». Мне не очевидно J>>какую логику? Где логика? Есть миллион условий на то, когда можно увеличивать amount. Это ты называешь логикой?
M>Ага. Внезапно тебе уже не нравится логика. Что ты подразумеваешь под словом «логика»?
Какие-то действия. Типа "если а, то делаем б и в, а если г и д — то е". При этом у действий есть конкретные предусловия, которые нарушать нельзя. А у тебя всего одно действие — увеличить amount. На нем можно продемонстрировать подход в общем, но тебя это не устроило
J>>>>ЗЫ Я вот по системе, которую пишу на работе, могу сказать, что различные операции над ордерами (типа изменить цену, убить, вставить другой ордер рядом и т.д.) вызываются из кучи разных мест, в зависимости от того, что стратегии в данном месте почудилось.
M>>>Ну вот покажи полноценное решение такой задачи со своим подходом на типах. Безо всякого «вот тут очевидно» и «вы тупые, статьи не читаете»
я не смогу ничего большого написать до апреля (а то и до середины апреля), сорри. Много дел на работе и отпуск. Надеюсь, ты готов ждать.
J>>Миллион условий на то, когда можно увеличивать amount?
M>Не миллион. Всего четыре (если не ошибаюсь) в моей изначальной задаче.
Ну там же усложнение идет просто за счет добавления условий, навешенных на то же самое действие increase_amount, разве не так?
ЗЫ Насчет "вы тупые" — будь добр, приведи линк на такое моё высказывание или извинись.
Здравствуйте, Mamut, Вы писали:
M>>>Я стираю много текста ни о чем. Я прошу от тебя одного: покажи мне пожалуйста в коде. Законченном. Как это будет выглядеть.
J>>У меня нет твоей задачи, "законченной". Есть только вызов increase_amount. Это задача ни о чем, это и не задача даже.
M>Это задача из банка. Ты же тут притащил презенетацию из банка про типы. Ты думаешь у них что-то сильно другое?
Уверен. Они риск пишут, а не ордер-процессинг, там же написано.
Что конкретно у них в типах, я не знаю — я их кода не видел.
То, о чем я писал в своем примере — это имеет отношение скорее к зависимым типам, и может совершенно не иметь отношения к тому, что у них на Хаскеле.
J>>Ее можно решить как одним мега-свойством IncreaseAmountOK, так и кучей элементарных свойств или какой-то их комбинации. M>Можно наконец-то увидеть это решение? Хоть мегасвойством хоть комбинацией? Я слышу много разговоров о том, как это можно решить и ноль решений
сорри, не раньше апреля (отпуск, работа). До тех пор могу только односложно отвечать по сути.
M>Да. Мне непонятно, как это решить, несмотря на тот кусок кода, что ты привел ПОтому что твой кусок кода не отвечает на вопросы: M>- что будет, когда условий больше двух
Я показал, как добавить к одному свойству второе. Третье, четвертое и т.д. добавляются аналогично. Не будешь же ты говорить, что не понимаешь, как добавить третье свойство?
M>- показать, как типы хорошо помогают при с ad-hoc программировании (твое утверждение, поэтому оно есть в здаче)
Я показал, как это происходит при добавлении второго свойства (оно было добавлено ad-hoc, изначально его не было). При добавлении третьего, четвертого и т.д. будет ровно то же самое (хотя если свойства добавляются пачкой, можно и в одну функцию упаковать, чтобы не было леса из PROP_IF, особенно если в других ветках ничего не будет).
Ты ведь понял, как я добавил второе свойство? Сможешь ведь по аналогии добавить третье, четвертое?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, jazzer, Вы писали:
J>>Вот я для кого написал "Не будет никакого try_to_change_amount, а будет какой-нть process_order", интересно? S>Понятия не имею. Наверное, для тех, кто никогда в жизни не писал системы обработки заказов, и может поверить в эту смелую фантазию.
хм. Это я никогда не писал, видимо
S>В приведённых вами примерах ровно никакой пользы нет — код бросает те же исключения в тех же ситуациях. И те ошибки, которые может "отловить" ваш код, в безтиповом коде вообще не возникают от слова "никак".
В моем коде (на работе, в смысле) вообще исключений нет, в принципе (кроме момента старта приложения, когда всякие конфиги читаются).
Если что-то запрещено делать — код просто не должен пытаться это сделать (в смысле, должен быть так написан), а не бросаться исключениями на попытку вызвать не то. В HFT исключения на каждый чих — непозволительная роскошь.
M>>Это задача из банка. Ты же тут притащил презенетацию из банка про типы. Ты думаешь у них что-то сильно другое? J>Уверен. Они риск пишут, а не ордер-процессинг, там же написано.
Это значит, что у них точно такие же задачи. Ты думаешь, мы риск не пишем? Ты сильно ошибаешься.
J>>>Ее можно решить как одним мега-свойством IncreaseAmountOK, так и кучей элементарных свойств или какой-то их комбинации. J>сорри, не раньше апреля (отпуск, работа). До тех пор могу только односложно отвечать по сути.
Хорошо, в апреле напомню
M>>Да. Мне непонятно, как это решить, несмотря на тот кусок кода, что ты привел ПОтому что твой кусок кода не отвечает на вопросы: M>>- что будет, когда условий больше двух M>>- показать, как типы хорошо помогают при с ad-hoc программировании (твое утверждение, поэтому оно есть в здаче)
J>Ты ведь понял, как я добавил второе свойство? Сможешь ведь по аналогии добавить третье, четвертое?
Да. Мне непонятно. Я вижу распухающий от этих типов и PROP_IF'ов код, за которым не видно не то, что леса, но даже того, что вообще в коде происходит. Я зотел бы увидеть законченный код То есть где не только «добавлено третье-четвертое свойство» в тип, но и есть код, который с этими типами работает
M>>Ага. Внезапно тебе уже не нравится логика. Что ты подразумеваешь под словом «логика»?
J>Какие-то действия. Типа "если а, то делаем б и в, а если г и д — то е". При этом у действий есть конкретные предусловия, которые нарушать нельзя. А у тебя всего одно действие — увеличить amount. На нем можно продемонстрировать подход в общем, но тебя это не устроило
У меня есть действие increase_amount, у которого есть конкретные предусловия
J>>>Миллион условий на то, когда можно увеличивать amount? M>>Не миллион. Всего четыре (если не ошибаюсь) в моей изначальной задаче. J>Ну там же усложнение идет просто за счет добавления условий, навешенных на то же самое действие increase_amount, разве не так?
у действий есть конкретные предусловия, которые нарушать нельзя.
Заменяем «действий» на increase_amount, и что принципиально меняется? Ничего.
Здравствуйте, jazzer, Вы писали: J>хм. Это я никогда не писал, видимо
Ну, я так понял, что приведённый код — это не из продакшн-системы, а фантазии на тему "как бы выглядела бабушка, в случае, если ...".
Если у вас есть какой-то практический опыт — расскажите. Как вам удаётся написать "развесистую логику" в обработке одного шага workflow? Или вам удалось одной функцией с развесистой логикой описать workflow, который исполняется несколько недель?
С моей точки зрения, максимум, на что можно рассчитывать в order processing при помощи традиционной типизации — это заставить программиста явно обработать все статусы ордеров. Чтобы не получилось так, что ордер в неожиданном статусе при попытке изменить ему amount ни ошибки не выдаёт, ни amount не меняет.
J>В моем коде (на работе, в смысле) вообще исключений нет, в принципе (кроме момента старта приложения, когда всякие конфиги читаются). J>Если что-то запрещено делать — код просто не должен пытаться это сделать (в смысле, должен быть так написан), а не бросаться исключениями на попытку вызвать не то. В HFT исключения на каждый чих — непозволительная роскошь.
Золотые слова. Именно это и хочется обеспечить при помощи системы типов.
К сожалению, пока пути это сделать не видно — по крайней мере, убедительного примера так и не было приведено.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[80]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали: M>У меня есть действие increase_amount, у которого есть конкретные предусловия
По такому описанию реально ничего не напишешь.
В том смысле, что хотелось бы понять — а что предшествует этому increase_amount?
Это есть такой API, который выставлен наружу, и внешняя система может в произвольный момент времени запросить увеличение amount?
Или есть какой-то (какие-то) сценарий типа "объединить два ордера", в рамках которого происходит косвенное увеличение amount?
Или есть workflow для ордеров, который реализован внутри вашей системы, и в рамках этого workflow есть какие-то действия, когда можно увеличить amount?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[78]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
S>Как вам удаётся написать "развесистую логику" в обработке одного шага workflow? Или вам удалось одной функцией с развесистой логикой описать workflow, который исполняется несколько недель?
Ну как-то так:
void next_step(Order& o)
{
if (order.state1 == 1)
do_action1(o);
else
if (order.state2 == 2)
do_action2(o);
else
{
do_action3(o);
if (o.state3 == 3)
do_action1(o);
}
}
А как иначе, собственно? Ордер пришел из БД (или по сети), ты не знаешь, куда его можно двинуть дальше, пока не проанализируешь различные его свойства. Где тут место исключениям? Где тут место рантайм-ошибкам, кроме ошибок программиста?
Ну и да, если workflow исполняется несколько недель, все эти недели функция просто заходит в разные ветки.
Здравствуйте, Mamut, Вы писали:
M>>>Это задача из банка. Ты же тут притащил презенетацию из банка про типы. Ты думаешь у них что-то сильно другое? J>>Уверен. Они риск пишут, а не ордер-процессинг, там же написано. M>Это значит, что у них точно такие же задачи. Ты думаешь, мы риск не пишем? Ты сильно ошибаешься.
Риск — это просто математика же (если мы одно и то же имеем в виду под ним)
M>>>Да. Мне непонятно, как это решить, несмотря на тот кусок кода, что ты привел ПОтому что твой кусок кода не отвечает на вопросы: M>>>- что будет, когда условий больше двух M>>>- показать, как типы хорошо помогают при с ad-hoc программировании (твое утверждение, поэтому оно есть в здаче)
J>>Ты ведь понял, как я добавил второе свойство? Сможешь ведь по аналогии добавить третье, четвертое?
M>Да. Мне непонятно.
Непонятно, как я добавлял второе свойство? Если так, то с этого надо было начинать. Что конкретно непонятно?
M>Я вижу распухающий от этих типов и PROP_IF'ов код, за которым не видно не то, что леса, но даже того, что вообще в коде происходит. Я зотел бы увидеть законченный код То есть где не только «добавлено третье-четвертое свойство» в тип, но и есть код, который с этими типами работает
распухание ровно такое же, как в случае обычных if. Я специально сделал синтаксис максимально похожим на обычный if.
Давай так, просто ради смеха и если у тебя есть время, ты возьмешь и добавишь по образцу третье свойство в мой код. Любое, на свой вкус. Что там у нас есть сейчас — HasRisk и Shipped? Вот добавь по аналогии Prepaid (в самом ордере это свойство уже есть: o.prepaid()). А потом расскажешь, что именно показалось трудным.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Sinclair, Вы писали:
S>>Как вам удаётся написать "развесистую логику" в обработке одного шага workflow? Или вам удалось одной функцией с развесистой логикой описать workflow, который исполняется несколько недель?
J>Ну как-то так: J>
Очень странно. Кто вызывает этот "next_step"? По какому событию? J>А как иначе, собственно? Ордер пришел из БД (или по сети), ты не знаешь, куда его можно двинуть дальше, пока не проанализируешь различные его свойства.
Все системы, которые видел я, устроены так, что абстрактного глагола "вперёд" нету. Есть конкретные события: например, pay_order — привязать оплату к ордеру. Это событие переводит ордер в другой статус и, быть может, триггерит другие события. Например, если всё остальное готово, то заказ отправляется в delivery. И спит в этом статусе до тех пор, пока не придёт событие о результатах доставки. Никаким next_step не опишешь разнообразие событий, которые могут произойти после отправки:
— уведомление от транспортной компании о сбое доставки
— уведомление от клиента о получении товара
— отказ клиента от заказа
— оповещение от банка об отзыве платежа
Каждое из этих событий влияет на ордер по-разному.
J> Где тут место исключениям? Где тут место рантайм-ошибкам, кроме ошибок программиста?
Например, попытка сделать pay_order повторно на уже оплаченный ордер. Если это внешняя система — то байт им судья, могли что угодно накосячить. Но ведь может так оказаться, что мы сами накосячили. У нас в workflow попало два шага request_payment. А из-за асинхронности они попали в разные обработчики событий. То есть эта "рантайм-ошибка" статически неизбежна.
Именно такие вещи мы и хотим ловить при помощи системы типов.
J>Ну и да, если workflow исполняется несколько недель, все эти недели функция просто заходит в разные ветки.
К сожалению, эту функцию обсуждать серъёзно невозможно — она не описывает никакой workflow. В ней действительно нет места исключениям — ровно потому, что они не предусмотрены.
Если вы замените next_step на обработчик конкретного события, например pay_order(Order &o, Payment &p), то сразу появится и место исключениям — потому что помимо проверок на состояние ордера придётся как-то рапортовать и о том, что оплаченный заказ нельзя оплатить повторно.
Но в функции pay_order вы вряд ли найдёте развесистую логику, в которой из разных веток вызываются методы, к которым можно придумать нетривиальные предусловия.
Поэтому банальные проверки бизнес-правил в начале функции, и выброс исключения в случае их нарушения прекрасно сработают и без ввода сложной системы типов.
Система типов могла бы нам помочь, если бы она обнаруживала такие вещи, как задвоение шага request_payment в какой-то из веток жизненного цикла заказа.
Но ваша реализация до этого не дотягивает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А обещала быть интересной.
