M>>Можно это увидеть на полноценном примере? Там всего-то несколько усложнений по сравнению с реальностью
_>Да просто добавляешь свои обычные рантайм проверки в функции Decrease и Increase.
Если это так просто, можно наконец увидеть законченный пример?
_>Ничего касающегося статической типизации там больше не видно. К сожалению. ))) Потому как чем больше можно перевести в статику, тем лучше.
Ну так переводи
_>Я тебе уже в который раз говорю, что сложность не увеличится (более моего первого примера). Другое дело, что для твоей задачки польза от всего этого не особо есть и смысл играться с таким есть только ради демонстрации принципа на форуме. Но это в твоей задачке, а есть же много других. )))
Приводи другие задачи
_>>>Максимум, что могут наши современные средства, это свести введение правил до действительно одной точки, с автоматическим расползанием их по всему коду. И как раз в таком статическая типизация очень помогает. M>>Не понял этой фразы и утверждения
_>Если у нас есть какие-то ограничения на бизнес-логику (например как в твоей задачке — "отправленное нельзя увеличивать"), то очевидно лучше чтобы сам код проверки был написан ровно в одной точке программы, вызываясь из всех нужных мест. Статическая типизация отлично подходит для таких стратегий. Более того, она может ещё проконтролировать, чтобы не было мест без вызова проверки. Хотя это естественно не единственный способ реализации.
Ахахахахахахахахаха Вы уже договоритесь между собой, подходит или не подходит. Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию
_>>>Ну в исполняемый файл в итоге попадает или один или ноль if'ов. А в исходнике да, разрастаемся... ))) M>>Ну, вообще-то по большому счету глубоко наплевать на то, что попадает в исполняемый файл. Время программиста, который будет все это писать и разбирать потом, важнее намного.
_>В твоей задаче — конечно. А в других вполне бывает что всё наоборот.
В подавляющем большинстве задач именно так.
M>>Так. Я про это и говорю: данные приходят строго из рантайма. Про «функции перевода состояния» я слышу уже скоро месяц, как, но никто так и не осилил описать эти «функции состояния» до уровня полноценного примера
_>Ну вот прямо в моём примере видны эти функции. Например функция SendOrder переводит из состояния Unknown (ну и не заданного мною Increase&Decrease) в состояние OnlyDecrease.
Это они видны в твоем примере, потому что тебе так удобно. На практике SendOrder запишет в заказе поле is_sent=true и запишет в базу. Изменение суммы заказа, повторю, может произойти через неделю после того, как заказ отправился. И никаким переведением в «OnlyDecrease» SendOrder не будет заниматься, потому что это не ее область ответственности.
M>>И вообще. Что значит «функции состояния»? У нас нет никаких «функций перехода состояния». Изменение суммы заказа может происходить через неделю после того, как заказ создан. При чем тут «функции состояния»? Перед тем, как изменить сумму заказа, заказ будет загружен из базы данных в любом из четырех (из примера) или полутора десятков (в реальности) состояний.
_>И? ) Не пойму с чем ты споришь то? ) Я разве утверждал, что весь твой пример можно покрыть статикой? )
На данный момент я спорю с твоим странным утверждением о «функциях состяний» и прочем, извини, бреде, который при малейшем толчке рассыпается в прах.
Ты взял удобный тебе пример, когда все подряд идет подряд и показываешь, как это мегакруто. Извини. На практике ничего подобного не бывает.
Данные получаются откуда угодно, но только не из этапа компиляции, объекты находятся в сотне изменяемых и неизменяемых состяний, часто противоречащих друг другу, и эти состояния зависят от нескольких десятков разнообразных параметров, половина которых — из базы данных, вторая — из-за конфигурации, а третья — из выставленных где-нибудь в GUI оверрайдов.
В итоге и получается: как только удобные вам примеры уровня hello world'а, то — ура, ура, посмотри какая статика крутая. Как только пытаешься выйти за пределы уютного мирка, где все известно заранее, на этапе компиляции, как все: «не, ну мы тебе ничего не обещали, тут дальше очевидно, достаточно сделать метасвойство» и прочая и прочая
_>Естественно там останется куча рантайм проверок. Я просто поясняю, что статические тоже будут встречаться и не так редко, как ты думаешь. Но всё же наверное недостаточно часто, чтобы делать подобное в твоём случая. А вот в других задачах, где процент повыше, это уже явно имеет смысл.
Так приведи эти задачи. Где они? Ну, такие, не сугубо теоретические, а что-то связанное с тем, чем тут большинство занимается: перекладыванием одних данных в другие. Опять же, рядом где-то на сотой странице обсуждений смогли осилить только boost timer, где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно)
_>Однако тут то у нас форум и вопрос стоял (как я понял) не в несообразности применения данной технологии к конкретной задаче, а в демонстрации самой возможности подобного и механизма действия. С этим вроде как мой пример полностью справляется.
Нет, не справляется. Потому что моментально рассыпается от малейших прикосновений:
— у нас нет прямого перехода от sendorder в decrease и т.п.
— у нас order не создается на этапе компиляции, а из 100% рантайм-данных, после чего кладется в базу
и т.п.
Пока что «примеры, прекрасно показывающие», имеют какие-то сугубо теоретические основы или странные требования.
Здравствуйте, Mamut, Вы писали:
M>Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию
Перенесены в функцию у которой нет соответствующих предусловий.
Если предусловия всё-таки есть, а внутренние проверки это всего лишь defensive programming, а отнюдь не разветвление в соответствии с контрактом функции — то смысл есть.
M>Опять же, рядом где-то на сотой странице обсуждений смогли осилить только boost timer,
std::chrono
M>где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно)
В аффинном пространстве есть точки и векторы. Складывать две точки нельзя, разница двух точек это вектор, сумма точки и вектора — точка, линейная комбинация векторов — вектор. Статическая типизация, помимо всего прочего, позволяет закодировать эту логику и проверять её во время компиляции.
M>>Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию
EP>Перенесены в функцию у которой нет соответствующих предусловий.
EP>Если предусловия всё-таки есть, а внутренние проверки это всего лишь defensive programming, а отнюдь не разветвление в соответствии с контрактом функции — то смысл есть.
Специально для тебя терпеливо, как ребенку объясняю:
У тебя было:
function a(){ | function b(){ |
| |
if | if |
if | if |
if | if |
if | if |
| |
| |
x() | x() |
| |
} | } |
Тут ты говоришь: «ах-ах-ах, предусловия, как стат. типизация помогает-то!»
Делаем простой фокус, следи за руками:
function a(){ | function b(){ | function z(){ |
| | |
z() | z() | if |
| | if |
| | if |
| | if |
| | |
| | |
| | x() |
| | |
} | } | } |
Ой. Ничего не изменилось. Все условия на месте. Но только ВНЕЗАПНО «не, не имеет смысла».
При том, что jazzer и alex_public и AlexRK наперебой утверждают, что нет, имеет смыл
M>>Опять же, рядом где-то на сотой странице обсуждений смогли осилить только boost timer, EP>std::chrono
Не суть важно.
M>>где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно)
EP>В аффинном пространстве есть точки и векторы. Складывать две точки нельзя, разница двух точек это вектор, сумма точки и вектора — точка, линейная комбинация векторов — вектор. Статическая типизация, помимо всего прочего, позволяет закодировать эту логику и проверять её во время компиляции.
Ну в общем это все упирается только в «если у нас все абсолютно доступно во время компиляции». Да, это приятно, не скрою. Но нам, например, от этого ни холодно ни жарко
Здравствуйте, Mamut, Вы писали:
M>Ой. Ничего не изменилось. Все условия на месте. Но только ВНЕЗАПНО «не, не имеет смысла».
Бывают предусловия, бывает необязательный defensive programming для проверки некоторых из предусловий (при этом не являющийся частью контракта), бывают обычные внутренние условия/разветвления соответствующие контракту функции.
Ты понимаешь разницу между предусловием и простым if'ом внутри или снаружи функции? Без согласия в терминологии не вижу смысла продолжать ходить по кругу.
M>>>где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно) EP>>В аффинном пространстве есть точки и векторы. Складывать две точки нельзя, разница двух точек это вектор, сумма точки и вектора — точка, линейная комбинация векторов — вектор. Статическая типизация, помимо всего прочего, позволяет закодировать эту логику и проверять её во время компиляции. M>Ну в общем это все упирается только в «если у нас все абсолютно доступно во время компиляции». Да, это приятно, не скрою. Но нам, например, от этого ни холодно ни жарко
EP>Ты понимаешь разницу между предусловием и простым if'ом внутри или снаружи функции? Без согласия в терминологии не вижу смысла продолжать ходить по кругу.
Я вижу, что ничего не изменилось. И все те же «предусловия» для функции x() никуда не делись. Они становятся «бессмысленными» только у тебя
M>>Ну в общем это все упирается только в «если у нас все абсолютно доступно во время компиляции». Да, это приятно, не скрою. Но нам, например, от этого ни холодно ни жарко
EP>А я уже показывал
Здравствуйте, Mamut, Вы писали:
M>>>Ну в общем это все упирается только в «если у нас все абсолютно доступно во время компиляции». Да, это приятно, не скрою. Но нам, например, от этого ни холодно ни жарко EP>>А я уже показывал
полный рабочий пример в котором N псевдослучайных runtime флагов переводятся в compile-time значения, то есть в значения доступные во время компиляции M>Что именно в этом примере нам дает стат. типизация? Да, я тупой. Я не понимаю, зачем это нужно.
Контекст достаточно прямолинеен:
1. Я показал пример с аффинным пространством.
2. Ты согласился с тем что в этом примере часть логики легко закодировать в типах, так? Но говоришь что это нещитово, так как в этом примере всё доступно во времени компиляции, а тебя интересуют runtime данные.
3. Я привожу пример перевода совершенно случайных runtime значений в значения доступные во время компиляции. Это всего лишь техника.
Здравствуйте, Mamut, Вы писали:
M>Если это так просто, можно наконец увидеть законченный пример?
Подметать двор тоже просто, но мало кто стремиться позаниматься этим. )
_>>Ничего касающегося статической типизации там больше не видно. К сожалению. ))) Потому как чем больше можно перевести в статику, тем лучше. M>Ну так переводи
В смысле? ) Я же говорю, в твоём примере в статику переводится только небольшая часть (и это уже продемонстрировано). Т.е. хотелось бы больше, но не выйдет.
M>Приводи другие задачи
Другие задачи для чего? ) Для демонстрации эффективности статической типизации вообще (тут я прямо даже не знаю за что сразу хвататься, столько вариантов)? Или же ты про что-то конкретное?
M>Ахахахахахахахахаха Вы уже договоритесь между собой, подходит или не подходит. Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию
Объявляться правила должны в одном месте, а использоваться во многих. Именно в такой ситуации задание правил с помощью типов максимально эффективно.
M>В подавляющем большинстве задач именно так.
Ага, ага))) Ну только если не считать задачи типа как у Гугла/Яндекса (т.к. там 1% производительности означает сотни дополнительных серверов), научные числодробилки (кого-то волнуют дополнительные несколько недель вычислений?), задачи для мобильных устройств (т.к. там неэффективный код сжирает аккумулятор), задачи для встроенных устройств (т.к. там может банально не хватить ресурсов на исполнение) и т.п... А так да конечно, время программиста "почти всегда" важнее эффективности кода.
M>Это они видны в твоем примере, потому что тебе так удобно. На практике SendOrder запишет в заказе поле is_sent=true и запишет в базу. Изменение суммы заказа, повторю, может произойти через неделю после того, как заказ отправился. И никаким переведением в «OnlyDecrease» SendOrder не будет заниматься, потому что это не ее область ответственности.
Вообще то все эти состояния существуют только на момент компиляции. ))) Однако в твоём случае это действительно всё не в тему (см. ниже).
M>Так приведи эти задачи. Где они? Ну, такие, не сугубо теоретические, а что-то связанное с тем, чем тут большинство занимается: перекладыванием одних данных в другие. Опять же, рядом где-то на сотой странице обсуждений смогли осилить только boost timer, где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно)
С чего ты взял, что тут большинство занимается перекладыванием одних данных в другие? ) К примеру у меня подобной фигни нигде не наблюдается. Ну разве что в паре мелких серверных скриптов на наших сайтах помню подобный код. )))
Да, и я так и не понял, ты хочешь поговорить о преимуществах статической типизации вообще (странно что у кого-то вообще могут быть сомнения по такому вопросу)??? Или же всё же о каких-то конкретных специфических применения?
_>>Однако тут то у нас форум и вопрос стоял (как я понял) не в несообразности применения данной технологии к конкретной задаче, а в демонстрации самой возможности подобного и механизма действия. С этим вроде как мой пример полностью справляется. M>Нет, не справляется. Потому что моментально рассыпается от малейших прикосновений: M>- у нас нет прямого перехода от sendorder в decrease и т.п.
Т.е. ты ограничиваешь свою задачу строго одной элементарной операцией на шаг (загрузка/сохранение БД)? M>- у нас order не создается на этапе компиляции, а из 100% рантайм-данных, после чего кладется в базу
А это и не требуется для работы.
M>Пока что «примеры, прекрасно показывающие», имеют какие-то сугубо теоретические основы или странные требования.
Да на самом деле проблема в другом. Я тут перечитал твои сообщения и понял, что ты хочешь получить от людей совсем другое. Можно сказать даже более тривиальное. А тебе показывают сложное и из другой области. Тебе продемонстрировали возможности перевода части проверок в статику (а это очень круто по целому ряду причин), причём для сложных алгоритмов. А тебе то хочется совсем другого, более простого — некой помощи в организации сложных рантайм проверок (а не переноса их в статику), причём для тривиальной задачи вида "загрузка из БД, элементарная операция (с проверкой возможности), сохранение в БД". Естественно, что тебя не впечатляют показанные примеры. Надо будет подумать, что может предложить статическая типизация для твоей простенькой проблемы... Возможно есть какие-то варианты со статическом анализом операций (тогда типами будут уже не ордера, а операции), но так с ходу не придумывается. )))
_>Да, и я так и не понял, ты хочешь поговорить о преимуществах статической типизации вообще (странно что у кого-то вообще могут быть сомнения по такому вопросу)??? Или же всё же о каких-то конкретных специфических применения?
Выделенное — это сфероконь. Иначе известный, как теория. Теория без практики мертва.
Мне тут на протяжение двух сотен сообщений заливают баки про это самое «вообще». Можно меньше слов и больше дела?
M>>- у нас нет прямого перехода от sendorder в decrease и т.п. _>Т.е. ты ограничиваешь свою задачу строго одной элементарной операцией на шаг (загрузка/сохранение БД)?
Достаточно ограничить твои рассуждения про состояния этой саомй элементарной операцией, и все твои построения рушатся, как карточный домик
Я умолчу, что краткое описание «всего лишь» SendOrder — это почти 100 пунктов, многие из которых не элементарны.
M>>- у нас order не создается на этапе компиляции, а из 100% рантайм-данных, после чего кладется в базу _>А это и не требуется для работы.
M>>Пока что «примеры, прекрасно показывающие», имеют какие-то сугубо теоретические основы или странные требования.
_>Да на самом деле проблема в другом. Я тут перечитал твои сообщения и понял, что ты хочешь получить от людей совсем другое. Можно сказать даже более тривиальное. А тебе показывают сложное и из другой области.
Мне ничего не показывают Кроме Евгения.
_>Тебе продемонстрировали возможности перевода части проверок в статику (а это очень круто по целому ряду причин), причём для сложных алгоритмов. А тебе то хочется совсем другого, более простого — некой помощи в организации сложных рантайм проверок
Стоп. Вот у меня есть «сложная рантайм проверка». Ее никто не осилил. Но я должен поверить, ага-ага, что будет «некая помощь» в «сложных рантайм проверках» в «нетривиальных примерах».
. Я могу специально для тебя выложить flow нашей функции SendOrder. Да ты и другие пропоненты стат. типизации же просто загнутся решать «организацию сложных рантайм проверок».
_>Естественно, что тебя не впечатляют показанные примеры. Надо будет подумать, что может предложить статическая типизация для твоей простенькой проблемы...
Для начала можно подумать над тем, почему постоянно выдвигаются взимноисключающие параграфы.
И да. Ты и другие не осилили «простенькую проблему», но да, но да. «помогает в организации сложных рантайм проверок». Сказки этажом выше.
_>Возможно есть какие-то варианты со статическом анализом операций (тогда типами будут уже не ордера, а операции), но так с ходу не придумывается. )))
Я и заметил, что «с ходу не придумывается». Причем ни у кого. А пафоса-то! А громких заявлений!
Здравствуйте, Mamut, Вы писали:
_>>Да, и я так и не понял, ты хочешь поговорить о преимуществах статической типизации вообще (странно что у кого-то вообще могут быть сомнения по такому вопросу)??? Или же всё же о каких-то конкретных специфических применения? M>Выделенное — это сфероконь. Иначе известный, как теория. Теория без практики мертва.
Не совсем. Статическая типизация — это настолько глобальная вещь, что у неё есть и соответственно глобальные преимущества (а не только появляющиеся при рассмотрение конкретных случаев). Например, она на корню устраняет целый класс ошибок программиста. Всегда и везде. Конечно ты можешь вспомнить про тесты, как про сомнительную альтернативу... Но во-первых их надо писать (т.е. тратить время на дополнительные ненужные тесты, не относящиеся к функциональности), а во-вторых нет никаких гарантий их полноты. Это так сказать базовое преимущество, даваемое автоматически даже самому новичку в программирование, а не всяческие хитрые извращения (когда мы пытаемся накрутить проверку ещё и своих хитрых правил, а не только вложенных в систему обычных типов), обсуждаемые в данной темке.
M>Мне тут на протяжение двух сотен сообщений заливают баки про это самое «вообще». Можно меньше слов и больше дела?
Я в связи с занятостью по организации нового проекта так и не прочитал соседнюю темку ещё. ) А с чего собственно начался спор? )
_>>Т.е. ты ограничиваешь свою задачу строго одной элементарной операцией на шаг (загрузка/сохранение БД)? M>Достаточно ограничить твои рассуждения про состояния этой саомй элементарной операцией, и все твои построения рушатся, как карточный домик
Ну так достаточно наличия хотя бы двух элементарных операций на одном шаге, чтобы продемонстрированная мною технология заработала.
M>Я умолчу, что краткое описание «всего лишь» SendOrder — это почти 100 пунктов, многие из которых не элементарны.
Ты же вроде сам писал, что SendOrder — это всего лишь sent=true и потом сохранения ордера в базу. Так где истина то у тебя? )
_>>Тебе продемонстрировали возможности перевода части проверок в статику (а это очень круто по целому ряду причин), причём для сложных алгоритмов. А тебе то хочется совсем другого, более простого — некой помощи в организации сложных рантайм проверок M>Стоп. Вот у меня есть «сложная рантайм проверка». Ее никто не осилил. Но я должен поверить, ага-ага, что будет «некая помощь» в «сложных рантайм проверках» в «нетривиальных примерах». M>
Ты как-то криво читаешь мой текст. Здесь под сложностью/простотой задачи подразумевается не размер твоего алгоритма, а то, что мы хотим с ним сделать. Перевести часть его во время компиляции — это сложная задача (вне зависимости от количества проверок). Которая не всегда реализуема (во всяком случае целиком), но приносящая много бонусов в случае успеха. Однако демонстрация этого тебя абсолютно не впечатляет, просто потому, что тебе хочется видоизменить свой алгоритм в совсем другом направление — просто несколько упорядочить его (чтобы не было пропущенных рантайм проверок например), а количество рантайм проверок не важно. Это очевидно задача другого класса, гораздо более простая, выполнимая и скорее относящаяся к культуре проектирования. Другое дело, что не факт что статическая типизация будет иметь какое-то отношения к этому. Хотя не знаю, может и с помощью неё есть какие-то решения. Я не готов с ходу ответить, т.к. не обдумывал ещё данное направление.
M>Пожалуйста. Вот тебе «менее тривиальный» пример
. Я могу специально для тебя выложить flow нашей функции SendOrder. Да ты и другие пропоненты стат. типизации же просто загнутся решать «организацию сложных рантайм проверок».
Вообще то это тривиально реализуется даже прямо на том моём простейшем примере. Потому как у тебя тут не появляется никаких новых состояний (всё тоже самое — можно менять сумму или нельзя). А количество условий для перехода между состояниями вообще не принципиально. Оно же всё равно записывается тем же самым тупым кодом в лоб (без всяких игр с типами), прямо как и у тебя. Просто там в итоге будет не true/false, а тип такой или тип другой.
Однако это я опять же о своём, об интересной задачке переноса вычислений в статику. А тебе то это не интересно, тебе то хочется как-то уменьшить число ошибок в том самом тупом коде рантайм проверки этого множества условий...
M>Для начала можно подумать над тем, почему постоянно выдвигаются взимноисключающие параграфы. M>И да. Ты и другие не осилили «простенькую проблему», но да, но да. «помогает в организации сложных рантайм проверок». Сказки этажом выше.
Надо просто внимательнее читать текст оппонентов (см. выше), тогда не будет недопонимания. )
_>>Возможно есть какие-то варианты со статическом анализом операций (тогда типами будут уже не ордера, а операции), но так с ходу не придумывается. ))) M>Я и заметил, что «с ходу не придумывается». Причем ни у кого. А пафоса-то! А громких заявлений!
Ну я вроде как ничего не заявлял))) Я только показал пример, демонстрирующий перевод части рантайм проверок во время компиляции. Причём не на каком-то своём удобном примере, а на совсем неудобном твоём, показав что и там такое возможно. В начале мне показалась что цель именно в этом (т.к. она более нетривиальная и интересная). Теперь я вижу, что тебя интересовало другое и для твое проблемы (не задачки, а того, что надо с ней сделать!) у меня рецептов завязанных на статическую типизацию (а не на организационно-архитектурные улучшения, например типа перехода на использование некого встроенного DSL) с ходу нет. Но это не значит что их не существует. ))) И возможно даже я сам ещё что-то предложу, если найду время на обдумывание этой проблемы.
_>>>Да, и я так и не понял, ты хочешь поговорить о преимуществах статической типизации вообще (странно что у кого-то вообще могут быть сомнения по такому вопросу)??? Или же всё же о каких-то конкретных специфических применения? M>>Выделенное — это сфероконь. Иначе известный, как теория. Теория без практики мертва.
_>Не совсем. Статическая типизация — это настолько глобальная вещь, что у неё есть и соответственно глобальные преимущества (а не только появляющиеся при рассмотрение конкретных случаев). Например, она на корню устраняет целый класс ошибок программиста. Всегда и везде.
Громогласные заявления и пафос. Да, устраняют. Нет, этот класс ошибок не является самым большим.
_>Конечно ты можешь вспомнить про тесты, как про сомнительную альтернативу... Но во-первых их надо писать
Их все равно надо писать. Реализованная на типах логика автоматически правильной не становится.
M>>Мне тут на протяжение двух сотен сообщений заливают баки про это самое «вообще». Можно меньше слов и больше дела? _>Я в связи с занятостью по организации нового проекта так и не прочитал соседнюю темку ещё. ) А с чего собственно начался спор? )
_>>>Т.е. ты ограничиваешь свою задачу строго одной элементарной операцией на шаг (загрузка/сохранение БД)? M>>Достаточно ограничить твои рассуждения про состояния этой саомй элементарной операцией, и все твои построения рушатся, как карточный домик _>Ну так достаточно наличия хотя бы двух элементарных операций на одном шаге, чтобы продемонстрированная мною технология заработала.
Ну вперед. Продемонстрируй. Пока что много слов и очень мало дела. Забудь про SendOrder. Заказ поднимается из базы данных и над ним надо совершить манипуляции, указанные в моем примере.
M>>Я умолчу, что краткое описание «всего лишь» SendOrder — это почти 100 пунктов, многие из которых не элементарны. _>Ты же вроде сам писал, что SendOrder — это всего лишь sent=true и потом сохранения ордера в базу. Так где истина то у тебя? )
Понимаешь, вы тут скопом не смогли осилить даже маленькую задачу. Зачем вам надо знать, что делает SendOrder? Вам достаточно знать, что мой пример с SendOrder'ом не связан никак. То есть заказ отправлен и положен в базу. Неделю спустя надо изменить сумму заказа.
В примере нигде нет про send_order. Я не знаю, почему вы все так настырно его выдумываете
_>>>Тебе продемонстрировали возможности перевода части проверок в статику (а это очень круто по целому ряду причин), причём для сложных алгоритмов. А тебе то хочется совсем другого, более простого — некой помощи в организации сложных рантайм проверок M>>Стоп. Вот у меня есть «сложная рантайм проверка». Ее никто не осилил. Но я должен поверить, ага-ага, что будет «некая помощь» в «сложных рантайм проверках» в «нетривиальных примерах». M>>
_>Ты как-то криво читаешь мой текст.
Я читаю ровно то, что ты пишешь
_>Здесь под сложностью/простотой задачи подразумевается не размер твоего алгоритма, а то, что мы хотим с ним сделать. Перевести часть его во время компиляции — это сложная задача (вне зависимости от количества проверок). Которая не всегда реализуема (во всяком случае целиком), но приносящая много бонусов в случае успеха. Однако демонстрация этого тебя абсолютно не впечатляет
Потому что мне никто так ничего внятно и не продемонстрировал. Я увижу, наконец, до конца реализованный пример, или все будет так и скатываться в демагогию про «приношение многия бонусов»?
_>, просто потому, что тебе хочется видоизменить свой алгоритм в совсем другом направление — просто несколько упорядочить его (чтобы не было пропущенных рантайм проверок например), а количество рантайм проверок не важно. Это очевидно задача другого класса, гораздо более простая, выполнимая и скорее относящаяся к культуре проектирования. Другое дело, что не факт что статическая типизация будет иметь какое-то отношения к этому. Хотя не знаю, может и с помощью неё есть какие-то решения. Я не готов с ходу ответить, т.к. не обдумывал ещё данное направление.
M>>Пожалуйста. Вот тебе «менее тривиальный» пример
. Я могу специально для тебя выложить flow нашей функции SendOrder. Да ты и другие пропоненты стат. типизации же просто загнутся решать «организацию сложных рантайм проверок».
_>Вообще то это тривиально реализуется даже прямо на том моём простейшем примере.
Вперед. Реализуй это тривиально.
_>Потому как у тебя тут не появляется никаких новых состояний (всё тоже самое — можно менять сумму или нельзя). А количество условий для перехода между состояниями вообще не принципиально. Оно же всё равно записывается тем же самым тупым кодом в лоб (без всяких игр с типами), прямо как и у тебя. Просто там в итоге будет не true/false, а тип такой или тип другой.
Какой тип? Я увижу когда-нибудь полноценный код?
_>Однако это я опять же о своём, об интересной задачке переноса вычислений в статику. А тебе то это не интересно, тебе то хочется как-то уменьшить число ошибок в том самом тупом коде рантайм проверки этого множества условий...
То есть ты хочешь поговорить о сфероваккумных конях. Это мне неинтересно.
_>>>Возможно есть какие-то варианты со статическом анализом операций (тогда типами будут уже не ордера, а операции), но так с ходу не придумывается. ))) M>>Я и заметил, что «с ходу не придумывается». Причем ни у кого. А пафоса-то! А громких заявлений!
_>Ну я вроде как ничего не заявлял))) Я только показал пример, демонстрирующий перевод части рантайм проверок во время компиляции. Причём не на каком-то своём удобном примере, а на совсем неудобном твоём, показав что и там такое возможно.
Об боже? Неужели это возможно? Да ты что? И дальше что?
— Как это можно использовать?
— Где это можно использовать?
— Нетеоретические примеры сложнее hello world'а
_>В начале мне показалась что цель именно в этом (т.к. она более нетривиальная и интересная). Теперь я вижу, что тебя интересовало другое и для твое проблемы (не задачки, а того, что надо с ней сделать!)
Ты не поверишь, но меня ни на грамм не интересуют сугубо теоретические проблемы. Мне платят не за то, что я сижу целыми днями, придумывая, как прекрасно решаются сферовакуумные кони. Я пока что вижу сплошной пафос, громкие заявления и сугубые теоретизирования
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В аффинном пространстве есть точки и векторы. Складывать две точки нельзя, разница двух точек это вектор, сумма точки и вектора — точка, линейная комбинация векторов — вектор. Статическая типизация, помимо всего прочего, позволяет закодировать эту логику и проверять её во время компиляции.
Не совсем ясно, зачем тебе именно афинное пространство. Ты подаёшь это как абсолютное добро. Все что нужно для вычислений — точка отсчета, вектор, матрица + кое какие оптимизации.
Это позволяет упросить вычислительную модель. С другой стороны, если количество депенденсов будет конское, вполне возможно будет сложно контролировать типы и будет проще задавать точку как точкой, а не вектором.
То есть, нужен баланс — не просто "типизация это круто", а смотреть количество депенденсов. Если зависимостей единицы, то в статической типизации смысла большого нет.
Здравствуйте, Ikemefula, Вы писали:
EP>>В аффинном пространстве есть точки и векторы. Складывать две точки нельзя, разница двух точек это вектор, сумма точки и вектора — точка, линейная комбинация векторов — вектор. Статическая типизация, помимо всего прочего, позволяет закодировать эту логику и проверять её во время компиляции. I>Не совсем ясно, зачем тебе именно афинное пространство. Ты подаёшь это как абсолютное добро.
Натуральной точки отсчёта может и не быть для конкретной задачи — это собственно и есть аффинное пространство.
Например std::chrono — сложение двух time_point не имеет смысла, и это кодируется в системе типов: http://en.cppreference.com/w/cpp/chrono/time_point/operator_arith2
I>Все что нужно для вычислений — точка отсчета, вектор, матрица + кое какие оптимизации.
Для вычислений не нужны даже отдельные типы для матриц/векторов, достаточно везде использовать double*. Не говоря уже о том, что вычисления можно проводить вообще без статической типизации
Или чуть менее радикальный пример — в моих задачах часто известны размерности матриц/векторов в compile-time, кодирование этой информации в типах позволяет отлавливать ошибки связанные с размерностью на этапе компиляции.
I>Это позволяет упросить вычислительную модель.
Вообще-то обсуждается проверка части логики задачи статической типизацией — аффинное пространство в std::chrono как раз тому пример.
I>С другой стороны, если количество депенденсов будет конское, вполне возможно будет сложно контролировать типы и будет проще задавать точку как точкой, а не вектором.
Каких "депенденсов"?
I>То есть, нужен баланс — не просто "типизация это круто", а смотреть количество депенденсов. Если зависимостей единицы, то в статической типизации смысла большого нет.
Согласен, везде нужен баланс — для некоторых задач и язык с динамической типизацией более целесообразен. Но речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Не совсем ясно, зачем тебе именно афинное пространство. Ты подаёшь это как абсолютное добро.
EP>Натуральной точки отсчёта может и не быть для конкретной задачи — это собственно и есть аффинное пространство.
Приведи пример реальной задачи, которая наилучшим образом решается через афинное пространство. Я yt спрашиваю, можно ли его реализовать в С++, я спрашиваю где это применяется. Т.е. интересует область, где в наличии профит афинного над векторным.
EP>Согласен, везде нужен баланс — для некоторых задач и язык с динамической типизацией более целесообразен. Но речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности
Здравствуйте, Ikemefula, Вы писали:
I>>>Не совсем ясно, зачем тебе именно афинное пространство. Ты подаёшь это как абсолютное добро. EP>>Натуральной точки отсчёта может и не быть для конкретной задачи — это собственно и есть аффинное пространство. I>Приведи пример реальной задачи, которая наилучшим образом решается через афинное пространство. Я yt спрашиваю, можно ли его реализовать в С++, я спрашиваю где это применяется. Т.е. интересует область, где в наличии профит афинного над векторным.
Работа со временем — например std::chrono. Указатели/Итераторы (std::ptrdiff_t, std::iterator_traits::difference_type). Обработка CAD моделей.
EP>>Согласен, везде нужен баланс — для некоторых задач и язык с динамической типизацией более целесообразен. Но речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности I>То есть, смысл не интересует, так и запишем
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Натуральной точки отсчёта может и не быть для конкретной задачи — это собственно и есть аффинное пространство. I>>Приведи пример реальной задачи, которая наилучшим образом решается через афинное пространство. Я yt спрашиваю, можно ли его реализовать в С++, я спрашиваю где это применяется. Т.е. интересует область, где в наличии профит афинного над векторным.
EP>Работа со временем — например std::chrono. Указатели/Итераторы (std::ptrdiff_t, std::iterator_traits::difference_type). Обработка CAD моделей.
Опять ни о чем. Я просил тебя показать пример использования. "обработка CAD моделей" — здесь я сам могу тебе столько рассказать, что не унесёшь.
Chrono — это библиотечная вещь. Тебе нужно показать вещь, где она применяется и применение дает больше профита, нежели другая реализация.
EP>>>Согласен, везде нужен баланс — для некоторых задач и язык с динамической типизацией более целесообразен. Но речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности I>>То есть, смысл не интересует, так и запишем
EP>Как ты сделал такой вывод?
Из суммы двух слагаемых —
1 речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности
2 ты не показал никакого внятного примера,т.е. все заканчивается на принципиальных возможностях
Здравствуйте, Ikemefula, Вы писали:
I>>>Приведи пример реальной задачи, которая наилучшим образом решается через афинное пространство. Я yt спрашиваю, можно ли его реализовать в С++, я спрашиваю где это применяется. Т.е. интересует область, где в наличии профит афинного над векторным. EP>>Работа со временем — например std::chrono. Указатели/Итераторы (std::ptrdiff_t, std::iterator_traits::difference_type). Обработка CAD моделей. I>Опять ни о чем. Я просил тебя показать пример использования.
Пример использования чего? Указателей? Итераторов? std::chrono? Прикалываешься
I>"обработка CAD моделей" — здесь я сам могу тебе столько рассказать, что не унесёшь.
Да, да, я всё помню, ты сначала пел про то что в одиночку перекодил 40 программистов на задачах линейной алгебры, а потом конечно же подтвердил это знаниями о NaN'ах
.
Так что можешь не стараться, мне не интересно
I>Chrono — это библиотечная вещь. Тебе нужно показать вещь, где она применяется и применение дает больше профита, нежели другая реализация.
Профит в том, что:
1. Часть логических ошибок ловится в compile-time
2. Часть ошибок в перестановках аргументов ловится в compile-time.
3. При описании API нужно меньше документации (меньше мест ошибиться или забыть исправить при рефакторинге) — если в интерфейсе стоит Duration, то сразу ясно что это длительность.
4. Открываются дополнительные возможности перегрузки, и как следствие более удобное API.
I>>>То есть, смысл не интересует, так и запишем EP>>Как ты сделал такой вывод? I>Из суммы двух слагаемых — I>1 речь идёт не о "нужно/не нужно/где и в каких пропорциях", а о принципиальной возможности I>2 ты не показал никакого внятного примера,т.е. все заканчивается на принципиальных возможностях
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Опять ни о чем. Я просил тебя показать пример использования.
EP>Пример использования чего? Указателей? Итераторов? std::chrono? Прикалываешься
А что тебя смущает ? Ты утверждаешь, ни много ни мало, что есть некоторая предметная область, в которой задачи имеет смысл решать с использованием афинного пространства, а не векторного.
Хочется подтверждений.
I>>"обработка CAD моделей" — здесь я сам могу тебе столько рассказать, что не унесёшь.
EP>Да, да, я всё помню, ты сначала пел про то что в одиночку перекодил 40 программистов на задачах линейной алгебры, а потом конечно же подтвердил это
Вообще говоря ты привел свои догадки пополам с вымыслом. Нет и не было задачи `перекодить` 40 человек.
>знаниями о NaN'ах
Ты свою ссылку открывал ? Там про NaN в JS, а не про линейную алгебру. Срыватели покровов такие срыватели
I>>Chrono — это библиотечная вещь. Тебе нужно показать вещь, где она применяется и применение дает больше профита, нежели другая реализация.
EP>Профит в том, что:
Покажи внятный пример использования. Профит есть и у векторного пространства. Твоя задача — показать область, где у афинного профит над векторным.
Пока что ты смог указать chrono.К твоему сведению это не предметная область, а либа.
Чисто логика — косточка от арбуза не является арбузом. Более того, арбуз имеет смысл есть без косточек
Здравствуйте, Ikemefula, Вы писали:
I>>>Опять ни о чем. Я просил тебя показать пример использования. EP>>Пример использования чего? Указателей? Итераторов? std::chrono? Прикалываешься I>А что тебя смущает ?
То что примеры итерации или точек времени очевидны. И я думаю ты их (или нечто подобное) уж точно использовал при решении реальных задач.
EP>>Да, да, я всё помню, ты сначала пел про то что в одиночку перекодил 40 программистов на задачах линейной алгебры, а потом конечно же подтвердил это I>Вообще говоря ты привел свои догадки пополам с вымыслом. Нет и не было задачи `перекодить` 40 человек.
Тем не менее, ты зачем-то этим хвастался
I>>>Chrono — это библиотечная вещь. Тебе нужно показать вещь, где она применяется и применение дает больше профита, нежели другая реализация. EP>>Профит в том, что: I>Покажи внятный пример использования.
auto start = system_clock::now();
calc();
auto end = system_clock::now();
auto diff = end - start; // OKauto x = start + end; // Compile errorauto y = diff + 5s + 5min; // OKauto z = start + 2h + 2s + diff; // OK
I>Профит есть и у векторного пространства. Твоя задача — показать область, где у афинного профит над векторным. I>Пока что ты смог указать chrono.К твоему сведению это не предметная область, а либа. I>Чисто логика — косточка от арбуза не является арбузом. Более того, арбуз имеет смысл есть без косточек
Я был убеждён в том, что предметная область применения библиотеки std::chrono очевидна
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>А что тебя смущает ?
EP>То что примеры итерации или точек времени очевидны.
Да, когда нечего сказать, в ход идет аргумент "тут всё просто", "это очевидно"
EP>>>Да, да, я всё помню, ты сначала пел про то что в одиночку перекодил 40 программистов на задачах линейной алгебры, а потом конечно же подтвердил это I>>Вообще говоря ты привел свои догадки пополам с вымыслом. Нет и не было задачи `перекодить` 40 человек.
EP>Тем не менее, ты зачем-то этим хвастался
Хвастался, только совсем другим. `перекодить` — боюсь даже представить, что ты себе надумал.
I>>Покажи внятный пример использования.
EP>
EP>auto start = system_clock::now();
EP>
Итого — примера нет.
I>>Профит есть и у векторного пространства. Твоя задача — показать область, где у афинного профит над векторным. I>>Пока что ты смог указать chrono.К твоему сведению это не предметная область, а либа. I>>Чисто логика — косточка от арбуза не является арбузом. Более того, арбуз имеет смысл есть без косточек
EP>Я был убеждён в том, что предметная область применения библиотеки std::chrono очевидна
Попробуй выразить эту очевидность в терминах пользователя, сразу станет ясно. Вот скажем, редактор векторной графики — здесь всё предельно понятно. Попробуй придумать такой же пример, только что бы демонстрировал профит от chrono и сформулируй, почему именно от chrono будет максимум профита.
Вы уже договоритесь между собой, подходит или не подходит. Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию 
