Здравствуйте, Sinclair, Вы писали:
S>Из-за этого не получается ничего сэкономить на типах — нету повторного использования. Increase Amount уже вызывается ровно из одного места, и проверить корректность этого места вручную проще, чем навесить какие-то монструозности на её агументы, чтобы эти монструозности "проверили" на корректность три-четыре строки.
я ответил рядом про "ровно из одного места". Имхо, таких программ, в которых функции вызываются ровно из одного места и повторного использования ноль — о-малое, и, мне кажется, ты сильно лукавишь, утверждая, что ничего подобного у тебя в программе нет.
Даже "двинуть на шаг вперед" совершенно не означает, что переход в конкретное состояние будет осуществляться в единственном месте в коде.
Гораздо более вероятно, что будет нечто вроде
void do_one_step()
{
if (...)
// do smthif (...)
// do this
IncreaseAmount()
else// do smth elseif (...)
// do that
IncreaseAmount()
ApplyTax()
else// just apply tax
ApplyTax()
else
ApplyDiscount()
IncreaseAmount()
ApplyTax()
}
Можно, конечно, извратиться и вывернуть этот иф наизнанку, чтобы IncreaseAmount звался ровно из одного места, но это будет жестокий неподдерживаемый изврат типа
if (условие на 55 строчек) ApplyDiscount()
if (условие на 66 строчек) IncreaseAmount()
if (условие на 77 строчек) ApplyTax()
А если логику шага писать естественно, то, внезапно, окажется, что одни и те же функции зовутся из разных веток.
То есть есть твой тезис сводится к "а вот если у нас в программе нет вообще никакого повторного использования, и если вдруг функции и есть, то все равно они зовутся из одного единственного места (т.е. эти функции — чистый синтаксический сахар, просто чтоб главная функция не занимала 50к строк) — то тогда нам все эти пляски с типизацией не нужны" — тут я с тобой, пожалуй, соглашусь. Для такого ограниченного случая — наверное, да, не нужны.
Просто я как-то не предполагал, что ты всю дорогу говоришь о настолько ограниченном случае. Сорри.
S>Нужно научиться отслеживать тип ордера за пределы функций Save и Load.
Опять 25. PROP_IF именно этим и занимается — отслеживает тип.
J>>Ты точно со мной разговариваешь? S>Ну да.
Просто ты, похоже, какие-то вещи взял не из моих постов.
J>>ЗЫ А почему вдруг на вы, если не секрет? S>А я практически со всеми тут на вы.
Ну ладно. Обычно на вы означает ругань. Ничего, если я на ты продолжу?
Здравствуйте, Mamut, Вы писали:
ARK>>Все промежуточные функции будут требовать валидный ордер (неявным образом, просто из-за того, что где-то в глубине сидит increase_amount), кроме одной, где-то наверху, которая PROP_IF и делает. ARK>>try_increase_amount — упрощенный пример. Между PROP_IF и функцией, в которой закодировано требование к HasRisk (increase_amount), может находиться еще куча функций.
M>Можно увидеть это в виде полной реализации моего примера? + что Синклер сказал
Нет, не хочется сейчас писать. Прошу не трактовать это как "вставание в позу" или что-то в этом роде, просто мне лень. Можно считать, что я проиграл в споре.
Re[74]: Haskell нужен! (в Standard Chartered Bank)
ARK>Нет, не хочется сейчас писать. Прошу не трактовать это как "вставание в позу" или что-то в этом роде, просто мне лень. Можно считать, что я проиграл в споре.
Ты знаешь. Я это все же засчитаю проигрышем в споре.
alex_public утверждает, что это — простой пример, а стат. типизация дает «некую помощи в организации сложных рантайм проверок». При этом не осилил ни «простой пример», ни организацию даже четырех проверок.
Evgeny.Panasyuk утверждает, что «пытаться встроить контракт/предусловие в систему типов вполне имеет смысл», «Система типов позволяет энфорсить некоторые предусловия в compile-time» и т.п. При этом не осилил ни решить пример ни проверить в примере предусловия. Евгений, правда, был, по-моему, единственным, который привел еще и доп. примеры
jazzer утверждает, что «[типы] решают задачу бана неправильного кода, где правильность закодирована в определении.», «поможет компилятор — как раз с ad-hoc изменениями требований», при этом не осилил полностью решить пример, несмотря на то, что в него специально добавлена ad-hoc'нусть, а вся «правильность» вылилась в полтора условия, ен решающих пример, и отмазки «далее все очевидно».
Ты там где-то с jazzer'ом согласен, пример ты точно так же не осилил решить
Но все наперебой рассказывают мне, какой я тупой, как я ничего не понимаю, как там все очевидно и как это все прекрасно будет работать
Здравствуйте, Mamut, Вы писали:
M>Ты знаешь. Я это все же засчитаю проигрышем в споре.
Окей, пусть будет так. Я не против. Собственно, спорить у меня вообще цели не было. Просто хотел попробовать донести свою позицию. Не получилось. Ну — бывает.
Re[76]: Haskell нужен! (в Standard Chartered Bank)
M>>Ты знаешь. Я это все же засчитаю проигрышем в споре.
ARK>Окей, пусть будет так. Я не против. Собственно, спорить у меня вообще цели не было. Просто хотел попробовать донести свою позицию. Не получилось. Ну — бывает.
До меня вполне можно донести позицию Так только не доносят Отмахиваются всякими «там же очевидно» и «что там непонятно-то» И крутятся вокруг одного незавершенного куска кода
Здравствуйте, Mamut, Вы писали:
M>Evgeny.Panasyuk утверждает, что «пытаться встроить контракт/предусловие в систему типов вполне имеет смысл», «Система типов позволяет энфорсить некоторые предусловия в compile-time» и т.п. При этом не осилил ни решить пример ни проверить в примере предусловия.
Как сделать подобные проверки я показывал неоднократно: 1
EP>Если же для запуска функции нет необходимости делать проверки, change_amount сама всё что нужно проверяет внутри, и более того её запуск с невыполненными условиями не является ошибкой, а вполне штатным режимом — то пытаться переписать все эти внутренние проверки на типы, не вижу смысла, это никак не отразится на местах вызова этой функции.
И соответственно попытки реализовать часть логики из твоего конкретного примера (а не более общей задачи, в контексте большей системы и т.п) на типах, вызывают у оппонентов вполне резонные вопросы вида:
S>Ещё раз объясню простую вещь, которая до вас никак не хочет дойти: вы написали в два с половиной раза больше кода, при этом не совершив никакой полезной работы.
S>Количество рантайм проверок — такое же; устойчивость кода к ошибкам программиста — такая же.
S>Ну так если нету разницы, то зачем платить больше?
Re[76]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Mamut, Вы писали:
M>>Evgeny.Panasyuk утверждает, что «пытаться встроить контракт/предусловие в систему типов вполне имеет смысл», «Система типов позволяет энфорсить некоторые предусловия в compile-time» и т.п. При этом не осилил ни решить пример ни проверить в примере предусловия.
EP>Как сделать подобные проверки я показывал неоднократно: 1
Слова, слова, слова, цитаты, цитаты и полтора примера, после которых моментально возникает вопрос: как это развить, когда у тебя больше условий? Ответ? Нет, нигде нет ни ответа ни кода.
EP>А вот делать это в том твоём конкретном примере — не имеет смысла, что я и сказал в первом же сообщении:
Да-да. Ты придумал себе, что «не имеет смысла», хотя сам не можешь объяснить, почему не имеет смысла. Извини. Твои продолжающиеся заявления про предусловия меня уже устали.
Предусловия для функции x() никуда не делись, поэтому твои пафосные заявления про «пытаться встроить контракт/предусловие в систему типов вполне имеет смысл», «Система типов позволяет энфорсить некоторые предусловия в compile-time» должны продолжать работать
EP>И соответственно попытки реализовать часть логики из твоего конкретного примера (а не более общей задачи, в контексте большей системы и т.п) на типах, вызывают у оппонентов вполне резонные вопросы вида:
Понимаешь. Вы тут хором неспособны показать преимущества даже на маленькой задаче. Но требуете от нас, чтобы мы верили всем заявлениям про большие задачи
Вот, пожалуйста. У тебя есть предусловия. Если хочешь, притворись, что функция update_amount в моем коде
вызывается из стапятидесяти мест. Ты же этого добиваешься своими «предусловиями»? Ну дык, до этой функции есть еще что проверять и проверять
Ну покажи мастеркласс наконец-то Пока что ты продолжаешь подтверждать мои слова: задачу никто не осилил, все, что осилили — это полтра незаконченных примера с «ну это же очевидно»
Здравствуйте, Mamut, Вы писали:
J>>просто добавляешь дополнительные проверки внутри can_increase_amount.
M>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения
bool can_increase_amount(Order o)
{
if (
если заказ помечен как кредит
если заказ помечен как удаленный
если заказ помечен как пассивный
если заказ помечен как замороженный
если заказ помечен как предоплата
если заказ помечен как оплаченный по предоплате
если в заказе нет товаров, которые можно вернуть
если это аггрегированный заказ с прошедшим сроком оплаты
если это архивный заказ при условии, что он оплачивается через account
если сумма увеличивается, а это запрещено настройками заказа
если сумма увеличивается, а мы уже отослали запрос на оплату в банк клиента
если сумма увеличивается на сумму большую, чем указано в настройках (относительно оригинальной суммы заказа)
если сумма увеличивается, а заказ проведен через новую систему
если мы возвращаем деньги клиенту, заказ находится в одном из трех статусов, не является кредитом, и возвращаемая сумма меньше, чем максимальная разрешенная к возврату сумма
)
return true;
else
return false;
}
Как я говорил, все зависит от того, сколько проверок ты захочешь перенести в типы. Можешь оставить вот так, как есть, а можешь разнести на минипроверки и свойство на каждое.
В любом случае
соответственно, придется писать тесты на правильность реализации can_increase_amount, но не придется дополнительно проверять, что мы не вызываем финальную increase_amount не в том месте.
Как видишь, все есть в статье, если ее прочитать до конца.
Здравствуйте, AlexRK, Вы писали:
ARK>Забыть проверку PROP_IF выше по стеку нельзя, будет ошибка компиляции.
Зато можно забыть добавить требование в сигнатуру increase_amount.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[74]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, AlexRK, Вы писали:
ARK>Как раз избыточные проверки во всех промежуточных слоях и устраняются. Остается один PROP_IF (один PROP_IF на одно свойство, если быть точным) где-то на входе, скорее всего сразу после загрузки ордера, и где-то в глубине системы вызов increase_amount. Весь код между ними свободен от проверок, и в то же время компилятор гарантирует, что increase_amount вызывается в корректном контексте.
Нет никакой "глубины системы". Есть одна функция, которая поднимает заказ из базы и выполняет действие над ним.
Ваша проблема — в том, что вы всё время подразумеваете не тот код, который пишете.
Мамут вам же ясно сказал — пока что никто из участников забега не справился даже с упрощённым примером. Но вы упорно продолжаете ссылаться на "более сложный" пример. Которого нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[73]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, AlexRK, Вы писали: ARK>Да нет никаких "функций-оболочек". В смысле каких-то тонких оболочек над "беззащитными" функциями. Эта "оболочка" покрывает толстый слой кода, а может и всю систему вообще. Внутри этой оболочки производится куча действий.
Это всё бла-бла-бла. Покажите код.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[77]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, jazzer, Вы писали: J>Чем конкретно? Надо все-таки SQL писать?
Тем, что он ухудшает maintainability кода, хотя призван улучшать.
S>>устойчивость кода к ошибкам программиста — такая же. J>Ну конечно же нет
Ну конечно же да. Если вы прекратите воображать себе не тот код, который пишете, то вы сразу же увидите, что никаких преимуществ ваш подход не даёт.
Ещё раз показываю вам код:
public void FailMiserably()
{
var order = CreateNewOrder();
order.SetRisk(true);
try_increase_amount(order, 1000);
}
Этот код — ошибка программиста. Он нечаянно позвал try_increase_amount с невалидным ордером. В 100% случаев этот код приводит к рантайм-ошибке.
То, что внутри try_increase_amount написано вдвое больше кода, не помогает ничем — это всего лишь лишний код, который нужно поддерживать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[73]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, jazzer, Вы писали: J>Отличный ответ "Срезал!" (с) J>О чем дальше тут говорить — хз.
Наверное, надо дальше почитать текст, не?
J>Вот здесь у тебя ошибка в понимании моего кода, имхо. И тут моя вина тоже есть.
Нету у меня никакой ошибки. Код семантически однозначен. Просто я не наделяю его сверхъестественными свойствами. Щас поясню. J>Ты трактуешь increase_amount и try_to_change_amount в моем примере как пару. Типа каждый раз, когда ты хочешь позвать одно, ты должен позвать другое, и это другое — обертка для первого. И поэтому вдвое больше кода и прочая и тлен.
Не, вдвое больше кода — это потому, что без try_increase_amount ничего не работает. Поэтому вам приходится писать try_increase_amount в дополнение к "безопасной" increase_amount.
J>На самом деле никакой связки эти две функции в реальном коде образовывать не будут. Не будет никакого try_to_change_amount, а будет какой-нть process_order (я, кстати, вначале так и написал, но потом переименовал; как выясняется, зря). J>И в process_order будет разветвленная логика (по выполнению одного шага, если тебе так угодно, но мы же не знаем, загрузив ордер из БД, какой именно шаг можно исполнить сейчас), с обработкой рантайм-ошибок, кривых данных и прочего.
С чего бы это? Мы как раз знаем, какой шаг мы хотим исполнить — ордера сами по себе состояние не меняют.
Есть события — типа "действия пользователя", "приход подтверждения платежа", "приход подтверждения от системы доставки".
Даже те действия, которые идут в workflow "подряд", могут быть разрезаны на отдельные части — чтобы гарантировать восстановление workflow в корректном состоянии после сбоев.
J>Этих process_order может быть дофига, вообще говоря — по нажатию одной из кнопок в гуе, по приходу одного из многих сообщений по сети и т.д. и т.п. Будет process_button_a, process_button_b, process_network_message_c. J>В каждом будет какая-то логика.
Логика, в основном, будет сводиться к проверкам состояния ордера, и переводу его в следующее состояние в зависимости от них.
Те самые if(HasRisk).
J>Так вот все эти многоэтажные типы задают правила, по которым может быть написан код всех вот этих process_xxx, чтобы гарантировать, что незаконных переходов в них не будт.
В вашем конкретном подходе все эти многоэтажные типы не помогают никак. Потому, что и без них increase_amount выполнит все необходимые проверки, и откажется двигать ордер вперёд. Будет выброшено исключение, транзакция откачена, пользователь (или внешняя система) получат внятное сообщение о причинах отказа. Проверяются ведь не абстракции (типа указатель!=Null), а бизнес-правила.
J>Если ты уперся и настаиваешь, что у тебя в коде живет ровно один вызов каждой функции — тогда да, наверное, у тебя в коде все это не нужно. Как не нужно типизировать код с интом, если это всего лишь один инт на всю программу.
Воот, теперь вы постепенно начинаете понимать суть задачи. Дело даже не в том, что нет многократно вызываемых функций. Дело в том, что проверки можно проводить только на таком уровне, который вызывается как правило однажды. Нет правила, которое бы запрещало отрицательные суммы в ордерах. Правила обнаруживаются на уровне бизнес-значимых действий, типа "провести возврат". А такие действия очень редко вызываются из многих мест.
Это не означает, что "типы не помогут". Это означает, что нужно отказаться от наивного подхода, и решать задачу с другой стороны.
J>Могу привлечь аналогию с ООП. Если у тебя настолько примитивная (архитектурно) программа, что деление на классы ничего полезного в ней не даст, то, наверное, ООП в ней не нужен — это будет ровно один класс на всю программу, что смотрится маразматично (ну примерно как смотрится Java-программа с классом HelloWorldApp с единственной функцией main). Но стоит программе немножко усложниться — и вдруг ООП становится прекрасным работающим средством. Отличная аналогия. Нет другой такой архитектуры (ну, разве что кроме SOA), которой бы злоупотребляли с таким энтузиазмом, как ООП.
J>Так что да, если у тебя программа настолько примитивна, что каждая функция зовется ровно из одного места программы — тогда да. Ног тогда тебе и функция не нужна, вообще говоря, это чисто синтаксический сахар получается. Но ты, имхо, окажешься в меньшинстве с такой программой.
Подождём Мамута — пусть он скажет, из скольки мест вызывается increase_amount.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[83]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>При этом тикетов у нас в системе скоро будет несколько десятков тысяч. Собственно багов из них — меньше десяти процентов (остальное — требования к изменению функционала). Из этих багов связанные с проблемами в типах? 1-2 в год
Вот тут я хочу прояснить один момент: это утверждение скорее говорит о том, что у вас бедная система типов.
Ход мысли должен быть примерно таким: мы (абстрактное человечество) хотим, чтобы больше багов ловилось системой типов.
Т.е. из тех 10% ещё 8% поймать до того, как они попадут в продакшн.
Сложность — в том, что хорошо заточенный под задачу мозг с трудом видит альтернативы.
Ну, абстрактно — видим NullReferenceException. Придумать систему типов, которая бы поймала попытку отдать за пределы фазы конструирования объект с непроинициализированной ссылкой — значит выйти за пределы "коробки". В чистом C# такая система типов невозможна. Даже если удастся её прикрутить на codeContracts, это может потребовать ещё и перепилить часть уже работающей системы — изменить декомпозицию, и т.п.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[84]: Haskell нужен! (в Standard Chartered Bank)
M>>При этом тикетов у нас в системе скоро будет несколько десятков тысяч. Собственно багов из них — меньше десяти процентов (остальное — требования к изменению функционала). Из этих багов связанные с проблемами в типах? 1-2 в год S>Вот тут я хочу прояснить один момент: это утверждение скорее говорит о том, что у вас бедная система типов. S>Ход мысли должен быть примерно таким: мы (абстрактное человечество) хотим, чтобы больше багов ловилось системой типов. S>Т.е. из тех 10% ещё 8% поймать до того, как они попадут в продакшн. S>Сложность — в том, что хорошо заточенный под задачу мозг с трудом видит альтернативы.
Да, возможно. Проблема в том, что пока никто не может внятно эти альтернативы показать Во многом, вокруг этого весь спор и крутится.
возможно может быть описана типами и возможно ошибки в ней могут стать ошибками типизации, но пока я в упор не вижу, как это можно сделать, не потратив какое-то невменяемое количество времени, выписывая это в типах Может быть, именно поэтому все примеры, что мы видим, реализуют всего два-три условия ля последовательности простейших шагов?
M>>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения J>Как я говорил, все зависит от того, сколько проверок ты захочешь перенести в типы. Можешь оставить вот так, как есть, а можешь разнести на минипроверки и свойство на каждое.
Перенеси, пожалуйста.
Тебе напомнить про то, что ты сюда принес презентацию из банка. Ты так же утверждал, например, «поможет компилятор — как раз с ad-hoc изменениями требований».
Я специально привел типичную для банка задачу. Специально внес в нее условия и ad-hoc изменения.
с двумя условиями. Не решает даже первого пункта из моей задачи. Заканчивается на «ну там все легко/понятно/очевидно». Когда спрашиваешь: «мне не понятнои не очевидно, можно увидеть это развернутее», получаю раз за разом «что тебе там непонятно»
И все хором говорят про простоту задачи, тривиальность и очевидность
J>>Так что да, если у тебя программа настолько примитивна, что каждая функция зовется ровно из одного места программы — тогда да. Ног тогда тебе и функция не нужна, вообще говоря, это чисто синтаксический сахар получается. Но ты, имхо, окажешься в меньшинстве с такой программой. S>Подождём Мамута — пусть он скажет, из скольки мест вызывается increase_amount.
Данный конкретный increae_amount вызывается из двух мест:
— из xml-rpc метода
— из пакетной обработки заказов, которая, по сути, является все тем же xml-rpc вызовом.
Оба места передают в increase_amount банально Order, потому что все нужные проверки проводит собственно increase_amount (зачем проверками заниматься коду, не связанному с этим? Да незачем )
Здравствуйте, Mamut, Вы писали:
M>>>Добавь, пожалуйста. Я же не просто так прошу привести пример законченного решения J>>Как я говорил, все зависит от того, сколько проверок ты захочешь перенести в типы. Можешь оставить вот так, как есть, а можешь разнести на минипроверки и свойство на каждое.
M>Перенеси, пожалуйста.
Да ты мастер стирать ответы, я вижу.
M>Результат?
Результат очень простой — ты просто стираешь то, что тебе не нравится.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Забыть проверку PROP_IF выше по стеку нельзя, будет ошибка компиляции. S>Зато можно забыть добавить требование в сигнатуру increase_amount.
Это будет ошибка соответствия кода требованиям. Она никак автоматически не решается. Даже если требования выразить формально и на их основе сгенерить код программы — всегда останется открытым вопрос соответствия формального описацию тому, что имел в виду заказчик.
Отмахиваются всякими «там же очевидно» и «что там непонятно-то» 
"Срезал!" (с)
