Haskell нужен! (в Standard Chartered Bank) - Философия программирования

Здравствуйте, jazzer, Вы писали:

J>В твоем случае increase_amount можно вызвать (в смысле, программист может неосторожным/злонамеренным движением вкопипастить вызов) откуда угодно, из любого кода, из любой ветки, для любого ордера в любом состоянии.
Совершенно верно.
J>В моем — только в одном месте, только для ордера, которому разрешено поднимать amount. Все остальные места вызовут ошибку компиляции.
Зато try_change_amount можно вызвать откуда угодно, из любого кода, из любой ветки, для любого ордера в любом состоянии.
Я же говорю — весь эффект от вашей работы, помимо нагрева атмосферы, — это перенос throw из increase_amount в её wrapper.

J>У меня ошибка программиста — ошибка компиляции, в продакшен уйти не может в принципе.
Не надо наделять ваш код волшебными свойствами. Ничего подобного в нём нет.

J>Что есть? есть _уже_ корректно работающая система? так ей ничего не надо уже, она уже написана и уже работает, типы ей никак не помогут и не помешают. А вот при внесении изменений типы могу помочь не допустить ошибок при кодировании. Именно потому, что increase_amount можно вызвать только в одном месте.

J>Если что — типы не о надежности работы кода (типа код не валится на неправильных данных — потому что это вопросы верификации данных), а о надежности процесса разработки (уменьшения вероятности ошибок кодирования).
Совершенно верно. И ваш код не ловит никаких новых ошибок по сравнению с кодом без типов. Грубо говоря, единственная ошибка, которую умеет отлавливать ваш код — это вызов increase_amount вместо try_change_amount; но в "безтиповой" системе такой ошибки в принципе совершить нельзя, т.к. try_change_amount просто не существует.

J>Есть сомнения в том, что программирование с int и float более безопасно в плане ошибок кодирования, чем программирование по нетипизированным адресам?
В этом — сомнений нет. Но ваш пример — это как программирование c int и float, вот только все переменные имеют тип object. Поэтому все формулы выглядят вот так:

object c = (int)a*(int)b; // TypeCastException в случае программистской ошибки.

J>Если нет (ведь нет же, я надеюсь?), то почему есть тут?
Потому, что вы фактически по-прежнему предлагаете программирование в терминах общего класса. Ведь в базе хранится именно он, а никакой попытки описать цепочки workflow, которые бы пересекали границу save/load вы не сделали.
Поэтому ваши утверждения и остаются голословной теорией.

J>На всякий случай еще раз повторю главное, потому что ты валишь все в кучу — и обработку данных, и обработку ошибок программиста, и непринужденно перескакиваешь с одного на другое.
Я не перескакиваю. Это вы наделяете свой код волшебными свойствами, которых нет.

J>Типизация позволяет сделать процесс программирования более безопасным,
Ещё раз прошу: не надо булшита. Я по нему сам мастер спорта. Вам задают конкретный (ещё раз: конкретный) вопрос. Не надо переводить разговор в плоскость абстрактных понятий и моральных ценностей.
Пока что продемонстрированный вами код заведомо не лучше того, который вы предлагаете заменить. И он запросто может оказаться хуже — просто потому, что его гораздо больше, а это означает увеличение площади, на которой можно сделать ошибку. Я не хочу пока копать в эту сторону, потому что это не имеет смысла — зачем обсуждать код, который не решил поставленную задачу. Вот когда мы напишем некий код, который научится решать проблему save/load без рантайм проверок, тогда можно будет искать в нём другие недостатки.

Здравствуйте, Mamut, Вы писали:

M>Ну, как всегда, «hello, world» во все поля.

Просто иллюстрация идеи — зачем это нужно.

M>И опять же ноль ответов на вопрос: вот мы перенесли все эти «толпа кода» в одну функцию. Согласно Евгению, «все это не имеет смысла».

Ну не можем же мы перенести всю систему в одну функцию. У вас же работа с заказами расположена не в одной функции? Заказы ходят по системе туда-сюда. Uипотетические "типизированные заказы" с собой таскают дополнительные свойства ("уже был проверен на валидность"). Важно — свойства таскают _типы_ по _потоку управления_! Речь не о свойствах реальных экземпляров заказов в работающей системе, а о свойствах переменных в программе.

M>на практике все упирается в простейшие «hello, world»ы и «как бы нам не сложить апельсины с огурцами»

С практикой сложнее, пока мейнстримовые языки такие штуки делать не позволяют (ну или позволяют, но через одно место), а языки, где это делать можно, либо маргинальные, либо слишком извращенные.
Поэтому здесь все в основном пытаются проиллюстрировать идею — чем типы хороши в принципе. Ну, а со временем, возможно, и мейнстрим подтянется.

Здравствуйте, Mamut, Вы писали:

J>>У тебя ошибка программиста — исключение в рантайме, если не отловилось тестами — ушло в продакшен.
J>>У меня ошибка программиста — ошибка компиляции, в продакшен уйти не может в принципе.

M>Синклер задает тебе простой вопрос, от которого ты бегаешь, как черт от ладана (ты от него еще в разговоре со мной начал бегать).

M>1. Мы загрузили заказ из базы
M>2. Мы отправляем его на increase amount
M>3. Если нельзя, мы должны показать юзеру осмысленную ошибку
M>4. Если можно, мы увеличиваем

M>Синклер просит показать, как у тебя реализуется пункт 3.

Можно я покажу?

void try_to_change_amount(Order& o)
{
  PROP_IF(o, has_risk(o), HasRisk) {
    show_verbose_error("Осмысленная ошибка");   // показываем осмысленную ошибку
  }
  PROP_ELSE(o) {
    increase_amount(o, 2.71);
  };
}

Здравствуйте, Sinclair, Вы писали:

ARK>>Э... какие фантазии? Исключения там не вылетает, проверок в рантайме нет. Поведение и надежность двух вариантов совершенно разные.

S>"Там" — это где? Код про Load jazzer так и не показал. Единственный код, где есть Load — мой, и в нём рантайм проверки присутствуют независимо от наличия типизации.
S>Если вам понятна идея jazzer, то, наверное, легко будет подправить мой код так, чтобы в нём исчезли рантайм проверки, или написать новый код LoadOrder.

На C# написать такой (безопасный во время компиляции) код — нельзя. На С++ — можно.

Код LoadOrder действительно не имеет значения, в нем ничего нет и не должно быть. Он просто загружает произвольный заказ, с произвольными свойствами.

Здравствуйте, Sinclair, Вы писали:

J>>В твоем случае increase_amount можно вызвать (в смысле, программист может неосторожным/злонамеренным движением вкопипастить вызов) откуда угодно, из любого кода, из любой ветки, для любого ордера в любом состоянии.
S>Совершенно верно.
J>>В моем — только в одном месте, только для ордера, которому разрешено поднимать amount. Все остальные места вызовут ошибку компиляции.
S>Зато try_change_amount можно вызвать откуда угодно, из любого кода, из любой ветки, для любого ордера в любом состоянии.
S>Я же говорю — весь эффект от вашей работы, помимо нагрева атмосферы, — это перенос throw из increase_amount в её wrapper.

Вызов try_change_amount к ошибке не приведет.

ARK>Можно я покажу?

ARK>

ARK>void try_to_change_amount(Order& o)
ARK>{
ARK>  PROP_IF(o, has_risk(o), HasRisk) {
ARK>    show_verbose_error("Осмысленная ошибка");   // показываем осмысленную ошибку
ARK>  }
ARK>  PROP_ELSE(o) {
ARK>    increase_amount(o, 2.71);
ARK>  };
ARK>}
ARK>

Ну то есть ровно то, о чем говорит Синклер

Здравствуйте, Mamut, Вы писали:

M>Ну то есть ровно то, о чем говорит Синклер

Ничего общего. У Синклера нет compile-time запрета на вызов increase_amount в невалидном контексте.

Однако порожденный компилятором исполняемый код, вполне возможно, будет одинаковым (если, конечно, код Синклера не содержит ошибок).

M>>И опять же ноль ответов на вопрос: вот мы перенесли все эти «толпа кода» в одну функцию. Согласно Евгению, «все это не имеет смысла».

ARK>Ну не можем же мы перенести всю систему в одну функцию. У вас же работа с заказами расположена не в одной функции? Заказы ходят по системе туда-сюда. Uипотетические "типизированные заказы" с собой таскают дополнительные свойства ("уже был проверен на валидность"). Важно — свойства таскают _типы_ по _потоку управления_! Речь не о свойствах реальных экземпляров заказов в работающей системе, а о свойствах переменных в программе.

Я вот привел в пример кусок такой системы. Сразу же «не имеет смысла».

И да, нифига они не таскают свойства типа «проверен на валидность». На практике такие проверки — это жгучая смесь из свойств самого заказа, закэшированных результатов в других системах, производных от кучи вещей (от суммы заказа до адреса доставки) и т.п.

Вы тут рассказываете сказки про то, как все это будет прекрасно разруливаться типами, а на практике не можете решить с начала до конца простую задачу, на решение которой без у меня ушло 10 минут. Я боюсь представить, что произойдет, если вам дать действительно приближенную к реальности задачу

M>>на практике все упирается в простейшие «hello, world»ы и «как бы нам не сложить апельсины с огурцами»

ARK>С практикой сложнее, пока мейнстримовые языки такие штуки делать не позволяют (ну или позволяют, но через одно место), а языки, где это делать можно, либо маргинальные, либо слишком извращенные.
ARK>Поэтому здесь все в основном пытаются проиллюстрировать идею — чем типы хороши в принципе. Ну, а со временем, возможно, и мейнстрим подтянется.

Пока что вы не можете объяснить даже принципы

Не говоря уже о том, что все апологеты постоянно противоречат друг другу

Здравствуйте, Mamut, Вы писали:

M>Синклер просит показать, как у тебя реализуется пункт 3.
Похоже, что спасение рук утопающих.
Меня на самом деле интересует не пункт 3, а гарантия того, что пункт 3 у нас заведомо отсутствует. (Я как бы отхожу в сторонку от твоей оригинальной задачи, пытаясь нащупать хоть какой-то путь вперёд).

Ну вот, опять из общей теории: когда мы в С++ пытаемся вызвать private member, нам по рукам даёт компилятор. У нас нет никакой задачи "показать пользователю осмысленную ошибку в случае попытки вызова приватного мембера".

Если рассмотреть отвлечённую задачу, то можно попробовать как-то так.

Предположим, что у нас весь workflow — это цепочка вызовов, описанных в одной функции на псевдоязыке:

processOrder(orderParams)
{
   Order o = createNewOrder(orderParams)

   while(UI.doesUserWantToChangeTheOrder(o))
   {
     OrderChanges changes = UI.requestChanges(o);
     o = o.ApplyChanges(changes);
   }
   do
   {
     Payment payment = requestPayment(o.TotalAmount);
     try {
       checkedPayment = FraudChecker.checkFraud(payment, o);
       processedPayment = PaymentProcessor.Process(payment);
       o = o.ApplyPayment(processedPayment);
     } catch {}
   } while(!order.isPayed && UI.doesUserWantToProvideAnotherPaymentMethod);
   shippedOrder = ShipmentProcessor.SubmitShipment(o);
   deliveredOrder = ShipmentProcessor.WaitForDelivery(shippedOrder);
   if(UI.doesUserWantToReturnOrder(deliveredOrder))
   {
     ... 
   }
}

Пока вроде бы всё неплохо. Workflow — развесистый, на самом деле даже для такого простого сценария его втрое больше за счёт всяких побочных веток, которые в примере проигнорированы.
Разметка типами позволяет нам предотвратить ситуации, когда программист добавил какой-нибудь if и закрыл скобку не там, и мы ухитряемся отправить неоплаченный заказ.
Всё это — вполне достижимо теми самыми средствами, которые нам только что демонстрировали коллеги vdimas и jazzer.

Теперь внимательно посмотрим на фрагмент между SubmitShipment и WaitForDelivery. Типизация позволяет нам гарантировать именно такой порядок вызова этих методов.
Развитая типизация позволяет нам вставлять между ними ещё какие-то манипуляции с ордером, и компилятор будет позволять их, но не позволит переставить вызовы местами.
Развитая система scope-инга позволяет нам обойтись без разнообразия имён типа shippedOrder и deliveredOrder, а везде использовать просто o, которое будет нужного нам типа в каждой точке.

В итоге осталось представить себе то, что в промежутке между SubmitShipment и WaitForDelivery ордер на самом деле сбрасывается в базу.
Но для прикладного программиста это (должно быть!) не более интересно, чем то, что код программа на С++ через кажлые несколько миллисекунд вытесняется из кэша процессора, EIP получает совсем другое значение, контекст потока перезагружается, и "следующая" операция может выполняться совсем другим процессором.
А на С# между вызовами мог сработать уплотняющий GC, и только что записанные байты читаются совсем с другого адреса; тем не менее, безо всяких "проверок флагов" верификатор уже при загрузке программы нам гарантировал, что string мы прочитаем как string.

Здесь — то же самое. Наш гипотетический компилятор workflow должен превратить наше спагетти в развесистый набор отдельных микропроцедурок типа DeliveryComplete(...) — очень похоже на yield return или на await. Внутри них уже не нужно проверять никакие флаги (предположим пока, что у нас нет проблемы десериализации ордера после замены версии кода

), потому что корректность порядка проверил компилятор.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, Sinclair, Вы писали:

ARK>

ARK>void try_to_change_amount(Order& o)
ARK>{
ARK>  PROP_IF(o, has_risk(o), HasRisk) { // что это мы тут имеем? А! Это же... РАНТАЙМ ПРОВЕРКА!!! Которых у вас якобы нету!
ARK>    // а тут??? Мы что, тупо проигнорировали команду - и типа делаем вид, что всё нормально??? 
ARK>    // на самом деле тут, конечно же, будет throw - потому что ничего больше сделать нельзя.

ARK>    // на самом деле тут НЕЛЬЗЯ вызвать increase_amount (компилятор запрещает) и никакого throw не будет
ARK>  }
ARK>  PROP_ELSE(o) {
ARK>    increase_amount(o, 2.71);
ARK>  };
ARK>}
ARK>

Вы что, издеваетесь???? а ЧТО там будет вместо throw? У автора стыдливо написано буквально следующее:

// покажем сообшение об ошибке.

Я, будучи склонен называть вещи своими именами, честно пишу здесь throw — потому что в коде бизнес-логики иного доступа к UI нету.
А если есть возможность позвать здесь MsgBox, то я точно так же позову его изнутри increase_amount.

Здравствуйте, Mamut, Вы писали:

M>Я вот привел в пример кусок такой системы. Сразу же «не имеет смысла».

Ну так иногда это действительно не имеет смысла. Класс заводить на одну int-переменную не имеет смысла. Из этого не следует, что классы не имеют смысла вообще.

M>И да, нифига они не таскают свойства типа «проверен на валидность». На практике такие проверки — это жгучая смесь из свойств самого заказа, закэшированных результатов в других системах, производных от кучи вещей (от суммы заказа до адреса доставки) и т.п.

Пусть так. Это ничему не противоречит.

M>Вы тут рассказываете сказки про то, как все это будет прекрасно разруливаться типами, а на практике не можете решить с начала до конца простую задачу, на решение которой без у меня ушло 10 минут. Я боюсь представить, что произойдет, если вам дать действительно приближенную к реальности задачу

Повторюсь еще раз:

С практикой сложнее, пока мейнстримовые языки такие штуки делать не позволяют (ну или позволяют, но через одно место), а языки, где это делать можно, либо маргинальные, либо слишком извращенные.
Поэтому здесь все в основном пытаются проиллюстрировать идею — чем типы хороши в принципе. Ну, а со временем, возможно, и мейнстрим подтянется.

M>Пока что вы не можете объяснить даже принципы

Скорее вы не хотите понять. Уже 4 человека пытаются объяснить, из них 3 очень умных.

Вам не кажется, что это не просто так, что какой-то смысл за всем этим действительно есть?

Здравствуйте, Sinclair, Вы писали:

S>Вы что, издеваетесь???? а ЧТО там будет вместо throw?

Что угодно, кроме вызова increase_amount.

S>Я, будучи склонен называть вещи своими именами, честно пишу здесь throw — потому что в коде бизнес-логики иного доступа к UI нету.
S>А если есть возможность позвать здесь MsgBox, то я точно так же позову его изнутри increase_amount.

Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.

Здравствуйте, AlexRK, Вы писали:

ARK>На C# написать такой (безопасный во время компиляции) код — нельзя. На С++ — можно.
Пруф в студию.
ARK>Код LoadOrder действительно не имеет значения, в нем ничего нет и не должно быть. Он просто загружает произвольный заказ, с произвольными свойствами.
Это опять бла-бла. Покажите мне код, который хоть чем-то лучше кода с рантайм-проверками.

Здравствуйте, AlexRK, Вы писали:
ARK>Вызов try_change_amount к ошибке не приведет.
А к чему он приведёт?

Здравствуйте, AlexRK, Вы писали:

ARK>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.
Это называется "увиливать", или "юлить".
Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount.
Например — вернём заказ в текущем виде.
Ваш ход?

Здравствуйте, AlexRK, Вы писали:

ARK>Ничего общего. У Синклера нет compile-time запрета на вызов increase_amount в невалидном контексте.
Прекратите бредить, пожалуйста. В вашем коде зато нет compile-time запрета на вызов try_to_change_amount в невалидном контексте.
Вы просто заменили одну небезопасную функцию на другую небезопасную функцию.
Вот вам "код синклера":

void increase_amount(Order& o, Money amt)
{
  if(has_risk(o))
    show_verbose_error("Осмысленная ошибка");   // показываем осмысленную ошибку
  }
  else(o) {
    o.amount += amt;
  };
}

Вот вам пример кода, который приводит к runtime fault в вашем коде:

...
   Order o = create_order();
   o.SetRisk(10000);
   try_to_change_amount(o); 
...

Этот код прекрасно компилируется, и в 100% запусков показывает "осмысленная ошибка".
Каких ещё очевидных вещей вы не понимаете?

M>>Я вот привел в пример кусок такой системы. Сразу же «не имеет смысла».

ARK>Ну так иногда это действительно не имеет смысла. Класс заводить на одну int-переменную не имеет смысла. Из этого не следует, что классы не имеют смысла вообще.

Опять общие слова ни о чем

M>>И да, нифига они не таскают свойства типа «проверен на валидность». На практике такие проверки — это жгучая смесь из свойств самого заказа, закэшированных результатов в других системах, производных от кучи вещей (от суммы заказа до адреса доставки) и т.п.
ARK>Пусть так. Это ничему не противоречит.

Раз не противоречит, решите задачу, наконец

Пока что задачу решило два человека — Кодт и jazzer. При этом, оба решения неполные (из разряда «ну там далее и так понятно»).

M>>Пока что вы не можете объяснить даже принципы

ARK>Скорее вы не хотите понять. Уже 4 человека пытаются объяснить, из них 3 очень умных.

Я вообще-то прекрасно пытаюсь понять. Любой вопрос упирается в демагогию, сказки и прочие мифы древней Греции.

О. Кстати.

К вопросу об этой ветке. Почитай на несколько сообщений выше тут (и следующие 3 сообщения).

Ты с jazzer'ом продолжаете говорить о том, что без типов придется бросать какие-то исключения, а с типами, типа, никаких исключений. Что является явной ложью

И это выясняется при первом же наводящем вопросе. И так — с каждым из «принципов»

Хотя я не спорю, что в идеальной системе в идеальном состоянии что-то из того, что вы рассказываете, может иметь место.

ARK> Вам не кажется, что это не просто так, что какой-то смысл за всем этим действительно есть?

Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).

S>Теперь внимательно посмотрим на фрагмент между SubmitShipment и WaitForDelivery. Типизация позволяет нам гарантировать именно такой порядок вызова этих методов.
S>Развитая типизация позволяет нам вставлять между ними ещё какие-то манипуляции с ордером, и компилятор будет позволять их, но не позволит переставить вызовы местами.
S>Развитая система scope-инга позволяет нам обойтись без разнообразия имён типа shippedOrder и deliveredOrder, а везде использовать просто o, которое будет нужного нам типа в каждой точке.

У меня проблема с развитостью в том, что в итоге для того, чтобы создать непротиворечивую типизацию, которая все это будет отслеживать в (по сути — практически любых) комбинациях, надо нанять всех авторов Хаскеля и загрузить их работой на несколько лет

В это время какой-нибудь очередной Цукерберг на PHP успеет поработить весь мир

От:	Mamut	http://dmitriid.com
Дата:	27.02.15 12:32
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	27.02.15 12:38
Оценка:

	От:	AlexRK
	Дата:	27.02.15 12:38
	Оценка:

	От:	AlexRK
	Дата:	27.02.15 12:42
	Оценка:

	От:	AlexRK
	Дата:	27.02.15 12:48
	Оценка:

	От:	Evgeny.Panasyuk
	Дата:	27.02.15 14:36
	Оценка: