Здравствуйте, Mamut, Вы писали:
M>У меня проблема с развитостью в том, что в итоге для того, чтобы создать непротиворечивую типизацию, которая все это будет отслеживать в (по сути — практически любых) комбинациях, надо нанять всех авторов Хаскеля и загрузить их работой на несколько лет
C простыми флаг-предикатами прекрасно подойдёт решение vdimas.
Оно вполне лаконично в подготовке (т.е. добавить новый флаг не очень трудно), и позволяет нам избежать экспоненциального взрыва количества типов.
Просто описываем нужные нам требования в видe Order<Risk.Any, Payment.Applied, Delivery.NotStarted> — и поехали.
Я вообще подозреваю, что даже придуманная мной утопия реализуется на соврменном шарпе в виде этого решения + await + кастомный шедулинг.
Сложности начинаются, уже когда нужна не логика, а арифметика — даже целочисленная. В рантайме сравнить (текущий amount / 5) с increase_amount — легко.
А вот статически доказать, что у нас в принципе не бывает ситуаций, когда мы увеличиваем amount больше чем на 20% — уже, как я понял, за пределами теоретической мощности.
Я имею в виду что-то менее тривиальное, чем требование провести проверку немедленно перед вызовом — а когда компилятор может отследить все пути исполнения и сказать "спокойно чувак — переплаты не будет, я горантирую это".
Ну и с многословными именами и разнотипностью o в разных ветках исполнения, как я понимаю, всё приемлемо только в функциональных языках.
Не знаю, можно ли к ним приклеить вот этот вот "прозрачный persistence" и откат на шаг назад в случае сбоя транзакции.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[68]: Haskell нужен! (в Standard Chartered Bank)
M>>В это время какой-нибудь очередной Цукерберг на PHP успеет поработить весь мир
EP>При этом сделав статически типизированный PHP
Они взлетели до того, как сделали статически типизированный PHP, если что.
Более того:
Traditionally, dynamically typed languages allow for rapid development but sacrifice the ability to catch errors early and introspect code quickly, particularly on larger codebases. Conversely, statically typed languages provide more of a safety net, but often at the cost of quick iteration. We believed there had to be a sweet spot.
Thus, Hack was born. We believe that it offers the best of both dynamically typed and statically typed languages, and that it will be valuable to projects of all sizes.
Type checking is incremental, such that even within a single file some code can be converted to Hack while the rest remains dynamically typed. Technically speaking, Hack is a “gradually typed*”* language: dynamically typed code interoperates seamlessly with statically typed code.
Run-time enforcement of return types and parameter types (including scalar types like int and string) provides safety beyond what can be checked statically while type annotations are being gradually added to a codebase.
S>Сложности начинаются, уже когда нужна не логика, а арифметика — даже целочисленная. В рантайме сравнить (текущий amount / 5) с increase_amount — легко. S>А вот статически доказать, что у нас в принципе не бывает ситуаций, когда мы увеличиваем amount больше чем на 20% — уже, как я понял, за пределами теоретической мощности. S>Я имею в виду что-то менее тривиальное, чем требование провести проверку немедленно перед вызовом — а когда компилятор может отследить все пути исполнения и сказать "спокойно чувак — переплаты не будет, я горантирую это".
По сути, вся моя ветка выше была как раз про это Но почему-то оно все скатывалось к «не дать возможности сложить апельсины с крокодилами — это тоже логика» :D
А так да — я бы тоже хотел гарантированных проверок бизнес-логики любого уровня
Здравствуйте, Mamut, Вы писали:
S>>Просто описываем нужные нам требования в видe Order<Risk.Any, Payment.Applied, Delivery.NotStarted> — и поехали.
M>Хммм....http://rsdn.ru/forum/philosophy/5946213.1
Ничего особенно страшного. Реально интересных нам типов будет немного, и для них мы введём синонимы типа PaidOrder = Order<*.Any, *.Any, *.Any, Payment.Applied, *.Any, ...>.
И функция ApplyPayment будет требовать UnpaidOrder, а возвращать — PaidOrder.
M>По сути, вся моя ветка выше была как раз про это Но почему-то оно все скатывалось к «не дать возможности сложить апельсины с крокодилами — это тоже логика» :D
Ну это же форумный спор — никому не интересно спорить с реальным оппонентом. Лучше сдвинуть его на идиотскую позицию (вроде "типы вообще не нужны"), с блеском её опровергнуть, а на неудобные вопросы пространно отвечать удобными ответами.
M>А так да — я бы тоже хотел гарантированных проверок бизнес-логики любого уровня
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[69]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>>>В это время какой-нибудь очередной Цукерберг на PHP успеет поработить весь мир EP>>При этом сделав статически типизированный PHP M>Они взлетели до того, как сделали статически типизированный PHP, если что.
И теперь годами выплачивают свой technical debt — то PHP в C++ конвертируют, то делают свою PHP машину, то допиливают статическую типизацию и недостающие фичи. Но в принципе годная бизнес стратегия — где-то стреляет, где-то нет
M>Более того: M>
M>Thus, Hack was born. We believe that it offers the best of both dynamically typed and statically typed languages, and that it will be valuable to projects of all sizes.
Ты не поверишь, но твои оппоненты в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both в необходимых пропорциях
Re[67]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
ARK>>Вызов try_change_amount к ошибке не приведет. S>А к чему он приведёт?
Ну, я не совсем верно выразился. Имелось в виду, что в нем не будет "незапланированной" ошибки. Зависит от реализации этого метода. Если мы руками кинем там исключение, то, конечно, вылетит исключение.
Re[67]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>На C# написать такой (безопасный во время компиляции) код — нельзя. На С++ — можно. S>Пруф в студию. ARK>>Код LoadOrder действительно не имеет значения, в нем ничего нет и не должно быть. Он просто загружает произвольный заказ, с произвольными свойствами. S>Это опять бла-бла. Покажите мне код, который хоть чем-то лучше кода с рантайм-проверками.
Видите там boost::enable_if? Функция increase_amount определена только в контексте, где на ее аргумент навешено требуемое свойство. C# такими шаблонными возможностями не обладает.
Re[74]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде. S>Это называется "увиливать", или "юлить". S>Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount. S>Например — вернём заказ в текущем виде. S>Ваш ход?
Мы можем сделать кое-что поинтереснее. Например, сгенерировать ошибку времени компиляции.
void try_to_change_amount(Order& o)
{
PROP_IF(o, possibly_has_risk(o), HasRisk) {
BOOST_MPL_ASSERT_MSG(false, YOU_CANT_INCREASE_AMOUNT_FOR_SUCH_ORDER, (O));
};
... дальше обычный код
}
Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
Сделайте "ровно то же" у себя. Правда, вряд ли это получится.
Здравствуйте, Sinclair, Вы писали:
S>В вашем коде зато нет compile-time запрета на вызов try_to_change_amount в невалидном контексте.
Есть.
S>Вы просто заменили одну небезопасную функцию на другую небезопасную функцию.
Нет.
S>Вот вам пример кода, который приводит к runtime fault в вашем коде:
...
Order o = create_order();
o.SetRisk(10000);
try_to_change_amount(o);
...
S>Этот код прекрасно компилируется, и в 100% запусков показывает "осмысленная ошибка".
Этот код не скомпилируется. (Впрочем, зависит от реализации SetRisk, если мы там ошибочно забудем навесить на order предикат HasRisk, то действительно скомпилируется.)
Прошу прощения, здесь я наврал. Этот код действительно скомпилируется, ведь мы предусмотрели возможность передачи в try_to_change_amount невалидного ордера.
А вот если бы потребовали только валидный, как здесь — http://rsdn.ru/forum/philosophy/5967700?tree=tree
Здравствуйте, Mamut, Вы писали:
M>Раз не противоречит, решите задачу, наконец Пока что задачу решило два человека — Кодт и jazzer. При этом, оба решения неполные (из разряда «ну там далее и так понятно»).
Это будет объемный кусок кода. Я не готов писать его. Хелло ворлд особых усилий не требует, а решение такой задачи — определенно требует.
Да и не вижу смысла, jazzer вон в своей портянке уж казалось бы все разжевал, ан нет — толку нет все равно.
M>Ты с jazzer'ом продолжаете говорить о том, что без типов придется бросать какие-то исключения, а с типами, типа, никаких исключений. Что является явной ложью И это выясняется при первом же наводящем вопросе
Не знаю про "никаких" исключений, но иногда исключения действительно исчезают — точнее, превращаются в ошибки компиляции. Пример я приводил чуть выше: http://rsdn.ru/forum/philosophy/5967700?tree=tree
M>Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).
Ну вы хотите, чтобы вам написали рабочую версию вашего требования, затратив на это день? ИМХО, жирновато для объяснения на форуме.
Re[70]: Haskell нужен! (в Standard Chartered Bank)
M>>>>В это время какой-нибудь очередной Цукерберг на PHP успеет поработить весь мир EP>>>При этом сделав статически типизированный PHP M>>Они взлетели до того, как сделали статически типизированный PHP, если что.
EP>И теперь годами выплачивают свой technical debt
Охохо. Кого это волнует, кроме акдемотеоретиков от типизации?
EP>Ты не поверишь, но твои оппоненты в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both в необходимых пропорциях
Именно. Пока что мои оппоненты занимаются сугубым теоретизированием и рассказыванием сказок, на практике внезапно оказывается, что на практике это никто не использует.
M>>Раз не противоречит, решите задачу, наконец Пока что задачу решило два человека — Кодт и jazzer. При этом, оба решения неполные (из разряда «ну там далее и так понятно»).
ARK>Это будет объемный кусок кода. Я не готов писать его. Хелло ворлд особых усилий не требует, а решение такой задачи — определенно требует.
Ахахахахахахаха что?
ARK>Да и не вижу смысла, jazzer вон в своей портянке уж казалось бы все разжевал, ан нет — толку нет все равно.
Толк есть, если вы слезете со своей колокольни, перестанете считать оппонентов идиотами и перестанете на простейшие вопросы отвечать простынями про то, как это хорошо или «и тут все понятно».
Вначале я, а теперь и SInclair задают простые и внятные вопросы. Где на них простые внятные ответы?
M>>Ты с jazzer'ом продолжаете говорить о том, что без типов придется бросать какие-то исключения, а с типами, типа, никаких исключений. Что является явной ложью И это выясняется при первом же наводящем вопросе
. И так — с каждым из «принципов»
ARK>Не знаю про "никаких" исключений, но иногда исключения действительно исчезают — точнее, превращаются в ошибки компиляции. Пример я приводил чуть выше: http://rsdn.ru/forum/philosophy/5967700?tree=tree
Нафига мне твои ошибки компиляции, если мне надо информацию об этой ошибке надо сразу вывести пользователю? Это к вопросу о «нет толка», ага. Это мы виноваты, что вы не отвечаете на заданные вопросы?
M>>Может и есть, но пока что практически ни один из пропонентов не смог ни внятно объяснить принцип, ни показать пример сложнее «hello, world». Тут или проблема в том, что все это — сугубо теоретизирование, либо добровольное заблуждение (с ООП тоже что-то похожее было).
ARK>Ну вы хотите, чтобы вам написали рабочую версию вашего требования, затратив на это день? ИМХО, жирновато для объяснения на форуме.
Что?! Вообще-то, «рабочая версия» моего требования пишется за 10 минут
. Я это продемонстрировал. Или ты предпочитаешь и дальше просто разглагольствовать на отвелеченные темы, бегая от реальных примеров, как от огня?
Это вообще реально смешно Простейшая задача на 10 минут на проверку оказывается неподъемной для апологетов типизации задачей, но при этом я должен им поверить на слово, что оно прекрасно работает для сложных задач и в прочие сказки
ARK>>>Вызов try_change_amount к ошибке не приведет. S>>А к чему он приведёт?
ARK>Ну, я не совсем верно выразился. Имелось в виду, что в нем не будет "незапланированной" ошибки. Зависит от реализации этого метода. Если мы руками кинем там исключение, то, конечно, вылетит исключение.
Что значит «незапланированная» ошибка?
Order o = load_order_from_db();
try_change_amount(o)
От того, что в этом месте вылетит runtime type-error, никому легче не станет. Если ты начнешь рассказывать сказки про то, что компилятор не позволит написать неправильный load_error, мы возвращаемся к ветке про load_order
Здравствуйте, Mamut, Вы писали:
M>>>>>В это время какой-нибудь очередной Цукерберг на PHP успеет поработить весь мир EP>>>>При этом сделав статически типизированный PHP M>>>Они взлетели до того, как сделали статически типизированный PHP, если что. EP>И теперь годами выплачивают свой technical debt — то PHP в C++ конвертируют, то делают свою PHP машину, то допиливают статическую типизацию и недостающие фичи. Но в принципе годная бизнес стратегия — где-то стреляет, где-то нет M>Охохо. Кого это волнует, кроме акдемотеоретиков от типизации?
Видимо того кто годами выплачивает этот долг, хотя мог бы пустить эти усилия на создание новых фич — может свой WhatsApp бы успели допилить, а не покупать его за надцать лярдов
EP>>Ты не поверишь, но твои оппоненты в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both в необходимых пропорциях M>Именно. Пока что мои оппоненты занимаются сугубым теоретизированием и рассказыванием сказок, на практике внезапно оказывается, что на практике это никто не использует.
Что "ЭТО"?
Re[72]: Haskell нужен! (в Standard Chartered Bank)
EP>Видимо того кто годами выплачивает этот долг, хотя мог бы пустить эти усилия на создание новых фич — может свой WhatsApp бы успели допилить, а не покупать его за надцать лярдов
Это прекрасно, что ты в качестве примера, якобы подтверждающего твою точку зрения, ты приводишь приложение, написанное на насквозь динамическом Erlang'е
И да. До WhatsApp'а у них уже был свой чатик сопоставимых масштабов, который — внезапно — тоже был написан на Erlang'е (справедливости ради должен сказать, что они перешли на C++[1], но не из-за динамики).
EP>>>Ты не поверишь, но твои оппоненты в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both в необходимых пропорциях M>>Именно. Пока что мои оппоненты занимаются сугубым теоретизированием и рассказыванием сказок, на практике внезапно оказывается, что на практике это никто не использует.
EP>Что "ЭТО"?
Все ващи сказки про стат. типизацию. Я же говорю. Вы все — сугубые теоретики. Как доходит до практики, «это бессмысленно» и «в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both»
S>>>Просто описываем нужные нам требования в видe Order<Risk.Any, Payment.Applied, Delivery.NotStarted> — и поехали. M>>Хммм....http://rsdn.ru/forum/philosophy/5946213.1
S>Ничего особенно страшного. Реально интересных нам типов будет немного, и для них мы введём синонимы типа PaidOrder = Order<*.Any, *.Any, *.Any, Payment.Applied, *.Any, ...>. S>И функция ApplyPayment будет требовать UnpaidOrder, а возвращать — PaidOrder.
Нууу... Сложно сказать. Из того, что я пока видел из предложенного в двух ветках, там на каждое условие придется писать свой тип/параметр типа, которые в некоторых местах вообще непонятно, как будут выглядеть (см. последнюю строчку).
M>>По сути, вся моя ветка выше была как раз про это Но почему-то оно все скатывалось к «не дать возможности сложить апельсины с крокодилами — это тоже логика» :D S>Ну это же форумный спор — никому не интересно спорить с реальным оппонентом. Лучше сдвинуть его на идиотскую позицию (вроде "типы вообще не нужны"), с блеском её опровергнуть, а на неудобные вопросы пространно отвечать удобными ответами.
Если это — камень в мой огород, то это не я, честно-честно Я прекрасно понимаю, когда мне говорят, что типы помогают не складывать апельсины с крокодилами и помогают при рефакторинге
Но эти проблемы сильно преувеличены (не устаю говорить, что с проблемами апельсино-крокодилов мы практически не сталкиваемся). Я тут выступаю против http://rsdn.ru/forum/philosophy/5946930.1
Потому что как только просишь показать это на чем-то более сложном, чем hello, world, все сыпется нафиг Или становится мегапереусложненным настолько, что отказываются даже показывать в виде мастер-класса
Здравствуйте, Mamut, Вы писали:
M>Толк есть, если вы слезете со своей колокольни, перестанете считать оппонентов идиотами и перестанете на простейшие вопросы отвечать простынями про то, как это хорошо или «и тут все понятно». M>Вначале я, а теперь и SInclair задают простые и внятные вопросы. Где на них простые внятные ответы?
Дайте, пожалуйста, ссылку на простой и внятный вопрос. Я постараюсь ответить.
"Реализуй мою кучерявую бизнес-логику" не является ни вопросом, ни простым.
ARK>>Не знаю про "никаких" исключений, но иногда исключения действительно исчезают — точнее, превращаются в ошибки компиляции. Пример я приводил чуть выше: http://rsdn.ru/forum/philosophy/5967700?tree=tree
M>Нафига мне твои ошибки компиляции, если мне надо информацию об этой ошибке надо сразу вывести пользователю? Это к вопросу о «нет толка», ага. Это мы виноваты, что вы не отвечаете на заданные вопросы?
Этой ошибки в программе не будет, показывать пользователю нечего.
Где-то (не в этом месте, скорее всего гораздо выше) будет проверка, удовлетворяет ли ордер условию HasRisk. Возможно (но не факт, зависит от требований) в том месте может быть показано какое-то сообщение пользователю.
M>Что?! Вообще-то, «рабочая версия» моего требования пишется за 10 минут
. Я это продемонстрировал. Или ты предпочитаешь и дальше просто разглагольствовать на отвелеченные темы, бегая от реальных примеров, как от огня? M>Это вообще реально смешно Простейшая задача на 10 минут на проверку оказывается неподъемной для апологетов типизации задачей, но при этом я должен им поверить на слово, что оно прекрасно работает для сложных задач и в прочие сказки
Версия-то рабочая, только не факт, что свободная от ошибок. Так что к ней по хорошему еще килограмм тестов нужен.
Записать это на типах будет, конечно, сложнее.
Re[69]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
ARK>>Ну, я не совсем верно выразился. Имелось в виду, что в нем не будет "незапланированной" ошибки. Зависит от реализации этого метода. Если мы руками кинем там исключение, то, конечно, вылетит исключение.
M>Что значит «незапланированная» ошибка?
Это значит — брошенная рантаймом, а не операцией throw, явно написанной программистом в коде.
M>
M>Order o = load_order_from_db();
M>try_change_amount(o)
M>
M>От того, что в этом месте вылетит runtime type-error, никому легче не станет.
ААААА
Здесь _не вылетит_ ошибка!
M>Если ты начнешь рассказывать сказки про то, что компилятор не позволит написать неправильный load_error, мы возвращаемся к ветке про load_order
Здравствуйте, Mamut, Вы писали:
EP>>Видимо того кто годами выплачивает этот долг, хотя мог бы пустить эти усилия на создание новых фич — может свой WhatsApp бы успели допилить, а не покупать его за надцать лярдов M>Это прекрасно, что ты в качестве примера, якобы подтверждающего твою точку зрения, ты приводишь приложение, написанное на насквозь динамическом Erlang'е
Я и так знал что он написан на Erlang, что это меняет
Мой поинт был о том, что пока они платили свой tech debt, их обскакали конкуренты, хотя казалось бы они были в более выгодных условиях.
EP>>Что "ЭТО"? M>Все ващи сказки про стат. типизацию. Я же говорю.
Статическая типизация позволяет поймать целый класс ошибок на стадии компиляции. Чем программирование более type rich, тем больше багов отлавливается типами. Согласен или считаешь что это сказки?
M>Вы все — сугубые теоретики.
Аргументы?
M>Как доходит до практики, «это бессмысленно»
Surprise, забивать гвозди мультиметром бессмысленно, что никак не отменяет его достоинств. То что для одной конкретной задачи пытаться переложить проверки на типы не имеет смысла — не делает твою экстраполяцию на все задачи сколько-нибудь близкой к реальности.
M>и «в повседневной работе используют и статически и динамически типизированные языки, сочетая the best of both»
Тебя удивляет то что для разных задач подходят разные инструменты? То что у разных инструментов свои плюсы и минусы?
Re[76]: Haskell нужен! (в Standard Chartered Bank)
— это «кучерявая бизнес-логика». Ну-ну.
M>>Нафига мне твои ошибки компиляции, если мне надо информацию об этой ошибке надо сразу вывести пользователю? Это к вопросу о «нет толка», ага. Это мы виноваты, что вы не отвечаете на заданные вопросы?
ARK>Этой ошибки в программе не будет, показывать пользователю нечего.
Вот почему я называю вас сугубо теоретиками. Это не «ошибка» — это вполне штатное условие. Пришел запрос от магазина — повысить сумму заказа. Мы обязаны ему ответить, почему это невозможно (а не «этой ошибки не будет»).
ARK>Где-то (не в этом месте, скорее всего гораздо выше) будет проверка, удовлетворяет ли ордер условию HasRisk. Возможно (но не факт, зависит от требований) в том месте может быть показано какое-то сообщение пользователю.
Где — выше? И да, проверок — не одна. Вот он, кстати. Внятный вопрос. Он выглядит так: покажи мало-мальски полноценное решение, а не отмазывайся общими фразами.
M>>Что?! Вообще-то, «рабочая версия» моего требования пишется за 10 минут
. Я это продемонстрировал. Или ты предпочитаешь и дальше просто разглагольствовать на отвелеченные темы, бегая от реальных примеров, как от огня? M>>Это вообще реально смешно Простейшая задача на 10 минут на проверку оказывается неподъемной для апологетов типизации задачей, но при этом я должен им поверить на слово, что оно прекрасно работает для сложных задач и в прочие сказки
.
ARK>Версия-то рабочая, только не факт, что свободная от ошибок. Так что к ней по хорошему еще килограмм тестов нужен.
Факт, что свободная.
ARK>Записать это на типах будет, конечно, сложнее.
Ну запиши же, ну. Покажи мастер класс. Почему я тебе должен верить на слово, что все великолепие типов раскроется в гораздо более сложном приложении, если вы так и не осилили полноценное решение для трех условий? (ну или четырех, не суть важно)
