Здравствуйте, Mamut, Вы писали:
J>>>>Без типов — придется просматривать руками все вызовы change_amount по всему проекту и пытаться понять, где у нас processed, где не processed, а где рыбу заворачивали. M>>>Что мешает вставить ровно одну проверку на is_processed собственно в change_amount? Тем более, что везде, где «заворачивали рыбу» известно, что смена суммы может и не пройти. EP>>Так ты определись какие preconditions у change_amount.
M>ЧТо значит pre_conditions?
Это те условия, которые должны быть выполнены перед запуском change_amount. Если эти условия не выполнены, то она имеет полное право делать что угодно. Это может быть попытка обнаружить нарушение предусловия, а-ля defensive programming, а может быть и фейерверк.
M>Я не знаю, что такое предусловия, постусловия и прочая. У нас есть условия, при которых мы можем изменить сумму заказа. Мне тут рассказывают, как все прекрасно можно решить типами. Показывают, как «можно решить», только все эти примеры валятся, как карточные домики, при простейшем рассмотрении
Например были показаны примеры как ограничить применение change_amount только отправленными заказами. В чём конкретно они валятся?
Re[37]: Haskell нужен! (в Standard Chartered Bank)
EP>Например были показаны примеры как ограничить применение change_amount только отправленными заказами. В чём конкретно они валятся?
Потому что как только оказывается, что есть не только отправленные заказы, как оказывается, что надо или тип превращать в непонятную мешанину или «ой, да, надо таки проверки в рантайме делать».
Здравствуйте, Mamut, Вы писали:
EP>>Например были показаны примеры как ограничить применение change_amount только отправленными заказами. В чём конкретно они валятся? M>Потому что как только оказывается, что есть не только отправленные заказы, как оказывается, что надо или тип превращать в непонятную мешанину или «ой, да, надо таки проверки в рантайме делать».
А какие ещё? Отправленные, предоплаченные, рискованные? Я же уже показал подобное
Здравствуйте, jazzer, Вы писали:
G>>Вот это все настолько красиво звучит, что было бы здорово увидеть пример, как запросто отразить это в определении типа. А то пока что в моем понимании это будет "переколбасить всю систему типов и огрести по полной".
J>Ну да, огрести по полной, именно так, от компилятора, ты все правильно понял.
Нет, есть ощущение, что при малейшем изменении в требованиях придется переписывать чуть ли не всю систему типов. Там где при рантайм проверках добавится пара ифов в случае с типами придется пройтись и подправить по огромное количество мест . Разве нет?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[36]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, genre, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
G>>>Вот это все настолько красиво звучит, что было бы здорово увидеть пример, как запросто отразить это в определении типа. А то пока что в моем понимании это будет "переколбасить всю систему типов и огрести по полной".
J>>Ну да, огрести по полной, именно так, от компилятора, ты все правильно понял.
G>Нет, есть ощущение, что при малейшем изменении в требованиях придется переписывать чуть ли не всю систему типов. Там где при рантайм проверках добавится пара ифов в случае с типами придется пройтись и подправить по огромное количество мест . Разве нет?
Да. А как иначе? Вот в обычной программе у тебя можно было с processed-ордером делать все, что угодно, а потом стало нельзя — тебе _в любой программе_ надо будет пройтись по всем 1024 местам использования ордера и посмотреть, что конкретно ты с ним делаешь и можно ли с ним это делать. Согласен? И от этого никуда не уйти в любом случае.
А разница проявляется в том, что, посещая эти 1024 места, ты легко можно 24 из них тупо пропустить, а еще в 128 — накосячить с изменениями. А если ты новое требование закодируешь в типе, то за тем, что ты посетил все 1024 места, проследит компилятор, и он просто не скомпилирует твою программу, пока ты не разберешься со всеми 1024 местами, причем пока не разберешься так, что компилятор будет удовлетворен.
Собственно, в этом весь смысл.
Типы не делают программирование легче и короче, они делают его надежнее и безопаснее.
Здравствуйте, jazzer, Вы писали:
J>А разница проявляется в том, что, посещая эти 1024 места, ты легко можно 24 из них тупо пропустить, а еще в 128 — накосячить с изменениями. А если ты новое требование закодируешь в типе, то за тем, что ты посетил все 1024 места, проследит компилятор, и он просто не скомпилирует твою программу, пока ты не разберешься со всеми 1024 местами, причем пока не разберешься так, что компилятор будет удовлетворен. J>Собственно, в этом весь смысл.
Это с одной стороны правда, но ты как-то пропустил в моем вопросе слово "переписать систему типов". Есть подозрение, что в одном варианте придется пройтись по 1024 местам и подкрутить какую-то часть из них, а во второй пройтись вообще по всем местам использования ордера (система типов же поменялась) и подкрутить уже не 1024, а сильно больше.
Вот я и попросил пример опровергующий это ощущение.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[38]: Haskell нужен! (в Standard Chartered Bank)
J>>А разница проявляется в том, что, посещая эти 1024 места, ты легко можно 24 из них тупо пропустить, а еще в 128 — накосячить с изменениями. А если ты новое требование закодируешь в типе, то за тем, что ты посетил все 1024 места, проследит компилятор, и он просто не скомпилирует твою программу, пока ты не разберешься со всеми 1024 местами, причем пока не разберешься так, что компилятор будет удовлетворен. J>>Собственно, в этом весь смысл.
G>Это с одной стороны правда, но ты как-то пропустил в моем вопросе слово "переписать систему типов". Есть подозрение, что в одном варианте придется пройтись по 1024 местам и подкрутить какую-то часть из них, а во второй пройтись вообще по всем местам использования ордера (система типов же поменялась) и подкрутить уже не 1024, а сильно больше.
Более того, постоянно пропускается тот момент, что обычно все упаковано в API, и вызывается именно API, никто не делает стопятьсот проверок в 1024 местах. Обычно это просто 1024 места, где вызывается этот API
Здравствуйте, genre, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>А разница проявляется в том, что, посещая эти 1024 места, ты легко можно 24 из них тупо пропустить, а еще в 128 — накосячить с изменениями. А если ты новое требование закодируешь в типе, то за тем, что ты посетил все 1024 места, проследит компилятор, и он просто не скомпилирует твою программу, пока ты не разберешься со всеми 1024 местами, причем пока не разберешься так, что компилятор будет удовлетворен. J>>Собственно, в этом весь смысл.
G>Это с одной стороны правда, но ты как-то пропустил в моем вопросе слово "переписать систему типов".
Признаться, я вообще с этим термином не знаком.
G>Есть подозрение, что в одном варианте придется пройтись по 1024 местам и подкрутить какую-то часть из них, а во второй пройтись вообще по всем местам использования ордера (система типов же поменялась) и подкрутить уже не 1024, а сильно больше.
G>Вот я и попросил пример опровергующий это ощущение.
В смысле? было increase_amount(Order), стало increase_amount(ProcessedOrder) — откуда "сильно больше"?
Здравствуйте, jazzer, Вы писали:
J>В смысле? было increase_amount(Order), стало increase_amount(ProcessedOrder) — откуда "сильно больше"?
было Order -> ProcessedOrder -> ClosedOrder
стало Order -> PartialProcessedOrder -> ProcessedOrder -> ClosedOrder
те придется переписать все что а) возвращало ордер, б) все что принимало ProcessedOrder
а если форкфлоу у тебя нелинейный, то все, расходимся.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[40]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, genre, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>В смысле? было increase_amount(Order), стало increase_amount(ProcessedOrder) — откуда "сильно больше"?
G>было Order -> ProcessedOrder -> ClosedOrder
G>стало Order -> PartialProcessedOrder -> ProcessedOrder -> ClosedOrder G>те придется переписать все что а) возвращало ордер, б) все что принимало ProcessedOrder G>а если форкфлоу у тебя нелинейный, то все, расходимся.
Пока что не видно, где "сильно больше".
Была пачка функций, принимавших ProcessedOrder. Надо просто пройтись по ним и решить, они по-прежнему должны работать только на ProcessedOrder, или им достаточно и PartialProcessedOrder. И поменять тип аргумента.
Но пройтись в любом случае надо было бы.
Аналогично, везде, где раньше создавался ProcessedOrder, надо посмотреть, должен создаваться он или же надо создавать PartialProcessedOrder (а как иначе? в этом же суть добавлений, собственно, это тоже пришлось бы делать в любом случае)
Здравствуйте, genre, Вы писали:
G>ну так минимум в два раза больше. и это в случае линейного воркфлоу. а если нелинейное? умножаем на количество входов-выходов из стейта.
Ну так это же надо в любом случае делать. Если требования меняются на таком уровне, то очевидно, что переколбашивать придется все. Что с типами, что без них. Просто с типами компилятор носом ткнет — где надо исправлять, а без них будем просто пребывать в счастливой уверенности, что все хорошо.
Re[20]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>Если все эти проверки спрятаны в банальном API-вызове order:update_amount, то смысл? Вот у нас эта проверка существует уже лет шесть. Менялась один раз, весной. Второй раз будет меняться вот буквально через неделю.
Вы спросили как проверить — я ответил. Теперь вы мне заявляете, что не нужно ничего проверять, писать, менять и вообще все тлен и суета сует. Естественно, проверка "стыкуемости" функций имеет смысл если она происходит сколько-то там раз и в нетривиальных сочетаниях.
M>Главная проблема — не в мифических проблемах с типами, а в логике: на каком именно этапе сделать проверку, и какую именно проверку. Ну и написать тесты, проверяющие, что логика работает правильно
Не понимаю, что за "мифические проблемы с типами". В обсуждаемом случае типы — это инструмент делегирования ответственности за проверку пользователю функции (другому программисту или себе в будущем, например). Т.е. функция требует того, что ей передают уже проверенные данные, если нет — получается ошибка во время компиляции. Т.е. это как раз относится к тому, что вы "главной проблемой" называете. Ну и это проверка лучше всякого теста в том плане про проверяет для целых пространств, а не каких то единичных точек в этих пространствах.
M>Я не разбушевался. Я прошу простых внятных ответов на мои вопросы.
Вы разбушевались. Обвиняете ваших оппонентов в том, что они как-то не так с вами поступают. Ответы игнорируете.
K>> сказки не рассказывал и не обещал, что "все будет зашибись".
M>Да неужели? Процитирую тебя: M>
M>Чтоб испортить этот бесплатный праздник [внезапно появившийся на пустом месте — М.] нужно уже какие-то усилия по обходу/затиранию типов прилагать, строково-ориентированным программированием, всякими кастами, реинтерпретацией памяти, рефлексией и другими веселыми вещами. Т.е. программист уже должен быть не просто ленивым, а активно злонамеренным.
M>Для типов есть легковесная верификация
M>Она не перестает быть логикой, она представляется в форме, которая хорошо подходит для автоматической проверки.
M>И т.п.
Ну и где в процитированном обещания того, что "все будет зашибись"? Получается, что все ваши заявления о том, что я вам это говорил оказались обычной неправдой.
M>На практике, когда начинаешь говорить с людьми, которые дают внятные ответы с примерами того, что они имеют в виду, ВНЕЗАПНО оказывается, что нет: или типы становятся слишком сложными, или часть проверок все равно в рантайме и т.п.
То, что нужно проверить в рантайме, естественно проверяется в рантайме. Типы "принуждают" вставить проверку в рантайме там где она нужна, передать полученную при такой проверке информацию туда, где нужна эта информация чтоб избежать избыточных проверок в рантайме, или даже автоматически получить код который что-то делает на основании этой информации (в том числе и проверяет в рантайме, где нужно). То, что вообще никаких проверок в рантайме не будет я и не обещал.
M>Если ответ состоит из расказов и сказок про то, как все будет великолепно, то да, я это проигнорирую.
Постарайтесь читать что вам пишут а не продолжать спорить с соломенным человеком. Или хотя бы не спихивать вину за это на других.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[18]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Mamut, Вы писали:
M>Опиши, как ты это себе представляешь, учитывая, что состяние «Отправленный и непроверенный как написано в 4-м пункте» — это только одно из условий, после чего этот заказ будет использоваться в следующей проверке, для которого нужен другой набор состояний.
Ну так в чем проблема? Всякий раз ваша система обработки заказов находится в некотором состоянии, которое представлено неким значением. Нужно сделать так, чтоб некорректные состояния были непредставимы ы виде значения, населяющего тип. Состояние системы не обязано на всех стадиях обработки представляться одни и тем же множеством значений. Скорее наоборот, если будет — то можно будет и некорректные состояния конструировать.
Ну так что конкретно тут веры требует? Тут веры нужно столько же, сколько для сложения чисел или дифференцирования, например — нисколько.
M>То есть ты ожидаешь, что так не будет?
Именно так. И чем больше спецификации будет в типах — тем больше оснований этого ожидать.
M>Эти стопятосот условий описаны в одном API Вызывается оно из трех или четырех мест. Грубо говоря, order:set_amount(Order, Amount). Этот вызов возвращает или обновленный заказ или {error, Reason}.
Речь идет об имплементации этого order:set_amount(Order, Amount) и других функций, определенных на Order. Если условий 100500, то проверок этих условий будет никак не меньше 100500, а скорее всего больше.
M>С какого перепугу что-то надо править в 1024 местах вместо одного, известно только тебе одному.
Потому, что обычно, применение функции определенной на каком-то типе встречается в коде несколько раз.
И уж точно встречаются применения всех функций определенных на типе хотя-бы один раз, если эти функции не мертвый код, конечно.
M>Ты пока не смог показать, как ты собираешься городить осмыслицу
Ну так задайте вопросы по существу, а не повторяйте раз за разом, что я вам ничего не могу показать.
K>>Тайпчек — это процесс нахождения логических ошибок. M>С какого перепугу? Тайпчек — это проверка, что все типы сходятся. К логическим ошибкам он не имеет никакого отношения.
Тайпчек — это проверка того, что код является конструктивным доказательством теоремы — типа. Если это не имеет отношения к логическим ошибкам, то что тогда имеет?
M>Ну ты лично написал с полдесятка сообщений, рассказывая, как все прекрасно
Не юродствуйте, "рассказами о том как все прекрасно" вы называете объяснения когда и при каких условиях типы будут приносить пользу и насколько много или мало будет этой пользы.
M>Ой. Уже внезапно не «проверка логики» и не «условия не будут противоречить», а «некоторый класс ошибок». Внезапно, да.
Вы говорите неправду, это вовсе не "внезапно", про "некоторые классы ошибок" я говорил и раньше.
И тут нет никакого отхода от "проверки логики". Какую часть спецификации вы выразите в типах — та и будет проверяться. Всю спецификацию выразите — всю проверите. Ничего не выразите — ничего не проверите.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
vsb>>Хаскель отличный язык, было бы здорово, если бы он взлетел хотя бы до уровня скалы.
K>А какие есть признаки того, что между хаскелем и скалой в смысле "взлетания" есть какая-то заметная разница?
Количество вакансий, количество обсуждений, вопросов в тех местах, которые я читаю.
Здравствуйте, vsb, Вы писали:
vsb>Количество вакансий, количество обсуждений, вопросов в тех местах, которые я читаю.
Кол-во вакансий — это еще может быть, хотя там количества и для скалы следовые. А кол-во обсуждений/вопросов чем отличается? Кол-во вопросов на стековерфлоу сопоставимо, число подписчиков в каком-нибудь реддите сопоставимо, объем правок на гитхабе сопоставим. И соответственно одинаково несопоставим со всеми этими показателями для яваскрипта и сиплюсплюса.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[19]: Haskell нужен! (в Standard Chartered Bank)
M>>Эти стопятосот условий описаны в одном API Вызывается оно из трех или четырех мест. Грубо говоря, order:set_amount(Order, Amount). Этот вызов возвращает или обновленный заказ или {error, Reason}.
K>Речь идет об имплементации этого order:set_amount(Order, Amount) и других функций, определенных на Order. Если условий 100500, то проверок этих условий будет никак не меньше 100500, а скорее всего больше.
K>Ну так задайте вопросы по существу, а не повторяйте раз за разом, что я вам ничего не могу показать.
Можно получить на него внятный ответ с примером решения без заумных фраз типа «Тайпчек — это проверка того, что код является конструктивным доказательством теоремы — типа.»,
Здравствуйте, genre, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>Пока что не видно, где "сильно больше".
G>ну так минимум в два раза больше. и это в случае линейного воркфлоу. а если нелинейное? умножаем на количество входов-выходов из стейта.
Нет. Я так понял, что мы
а) вводим новый тип — PartiallyProcessedOrder.
б) меняем какую-то из функций, порождающих ордера — например, функция PerformDelivery(Order) теперь возвращает не ProcessedOrder, а PartiallyProcessedOrder, а для получения ProcessedOrder нужно позвать ещё и CollectFeedback(PartiallyProcessedOrder).
в) компилируем, получаем X ошибок при попытках использования PartiallyProcessedOrder вместо ProcessedOrder.
г) вычитываем каждую из них и меняем всё как надо — если функция реально требует ProcessedOrder, то надо обеспечить, чтобы до её вызова был вызван CollectFeedback. Если функции этого реально не надо, а достаточно иметь PartiallyProcessedOrder, то меняем её сигнатуру.
После завершения у нас есть гарантия, что мы рассмотрели все переходы.
Это имеет смысл, если X достаточно велико. Если X = 1, что очень часто бывает в бизнес логике, то никакого выигрыша не будет.
Если X = 1000, то шансы забыть поставить if во всех 100 местах, где он реально нужен, весьма высоки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
S>Это имеет смысл, если X достаточно велико. Если X = 1, что очень часто бывает в бизнес логике, то никакого выигрыша не будет. S>Если X = 1000, то шансы забыть поставить if во всех 100 местах, где он реально нужен, весьма высоки.
Это все как-бы да. Я там выше с подобного примера и начал. Но как только я начинаю пытаться представлять как это все будет работать при воркфлоу сложнее линейного, а особенно если есть циклы, то сам выпадаю по StackOverflow.
Тем более, что везде, где «заворачивали рыбу» известно, что смена суммы может и не пройти.
