Я так же по поводу дат считают - пока арифметики с ними нет, нет смысла ко всяким системным и не очень типам приводить
Смысл есть - потому что обычно от вашей системы будут ожидать, что вы таки не принимаете дат "25-15-2025", независимо от особенностей работы с датами где угодно (мы же предполагаем ISO-шную систему, а не любую из альтернатив? даже если нет, то это где-то придётся выразить, и почему не в типах данных?). И ещё что вы сортировку по датам сравнительно честную будете делать, а не лексическую в зависимости от того, как эту дату вводил пользователь. Да и просто даты пользователю смотреть будет удобнее, если они все будут в общем форматировании, даже если вводились как придётся. Ничего из перечисленного сделать нормально не получится если их как-то когда-то не парсить. Ну а если вы чаще показываете даты, чем их сохраняете в store - то эффективнее их будет парсить при сохранении, и сохранять таки в соответствующих системных типах.
вдруг базу данных таймзон обновить забыли?
Стирать из своей системы важные для пользовательского опыта метаданные только потому, что девопсы могут забыть подложить правильный tzdata - это, по-моему, покруче всякого религиозного следования SOLID.
Вы не привязывайтесь к языкам. Пусть это будет ваш лично Decimal, который вообще сам по себе - десятчиное рациональное число с реализацией типа "чёрный ящик". Учитывая, что ни C#, ни Python, по вашим же словам, не имеют в стандартной библиотеке типа, который подходил бы для "серъёзных" финансов - вы либо напишете все операции вокруг существующих численных типов так, чтобы они себя хорошо вели, либо введёте новый тип, который эти операции реализует как вам нужно.
Если же нужно хранить точный результат от деления $100 на три - то лучше будет вместо Decimal назвать это дело Rational, и чёрный ящик ему соответствующий подобрать.
Money<Ruble,100>
Это дублирование информации. Нет веских причин не включить число 100 куда-то внутрь определения Ruble , и отображение настроить соответственно.
Я, правда, малость не понимаю, куда эта ветка начинает уходить.
Вы не согласны с подходом создания типов для реализации доменной логики, или вам просто сильно хотелось меня "макнуть" в пробелы в моих знаниях (о которых я и сам в курсе)?
Хранить лучше всего простой строкой, которая при записи дублируется хоть вот Decimal, — для быстрых неточных расчётов.
Строкой бесконечной длины, что ли?
Или хранить 0.(3)? Но это требует специального парсера, который знает про все эти 22/7. И зачем заморачиваться дописыванием парсера, если то же самое решается хранением "настоящего 9¾" - в трёх связанных целочисленных полях - [9, 3, 4]?
Пардон? ⅓×миллиард — это треть миллиарда, после отбрасывания дробного цента — у всех поровну.
Но и миллиард не делится на три нацело (и олимпиард не делится). Либо у кого-то останутся "дополнительные" доллары, либо вам всё-таки надо будет хранить синтетическую треть цента, которую никак не будет возможно обналичить. Да, по отношению к двум людям из трёх это "нечестно", потому что у них будет на цент меньше на момент раздела. Зато чем позже раздел, тем меньше разница. Пусть живут дружно, как завещал Кот Леопольд, я не знаю.
Программистское мышление в себе нужно убивать. Зачем вообще хранить деньги, если с ними нельзя сделать одну из самых распространенных операций с деньгами?
Физическую банкноту в сто долларов на три части вы можете поделить либо ножницами, либо в одной кучке останется 34 цента вместо 33х. Равно как и 0.(3) цента вы никуда не денете, потому что это не настоящие деньги, а математический/программистский артефакт. Все прочие операции вполне можно кодировать либо типом Decimal, либо тем франкенштейном из трёх целых чисел.
какая разница, сколько индусов там под капотом, если UX при этом восхитительный?
В том и дело, что и это не удалось ведь. То чек на оплату несколько часов идёт (потому что нечего полку своим телом загораживать, ага), то товары от другого покупателя (потому что нечего одежда похожая, и спиной стоял).
Во-вторых, во многих языках есть тип «рациональное число»
В руби-то, может, и есть - а в базе данных? Вот mysql, к примеру, как вроде одна из самых популярных, такой роскошью не обладает, да и в Postgres для этого специальные расширения нужны (и наверняка ещё своя особенная боль от отсутствующей поддержки в binding'ах).
Ну если более реально смотреть, то, конечно, можно для денег сразу выделять три поля с целочисленным типом, чтоб хотя бы рациональные числа хранились точно.
нельзя, потому что потом эти трети (если они — акции) — могут вырасти в миллиард раз, сделав дележ слишком уж неравным.
В этом случае тоже потеряется возможность слить их обратно вместе и получить ровно сто долларов. Но с другой стороны, если целью станет сохранить порядок роста - то скорее именно подход с получением одним человеком на цент больше позволит это сделать, так как не произведёт никаких дробных.
На тип нет, но на перевод из разменных единиц в неразменные — повлияет, 200 центов — это 2 бакса, а двести иен — это двести иен.
Но в том сообщении никто и не обсуждал перевод из разменных единиц в неразменные, вы были первый.
Люди делятся на тех, кто с деньгами работал, и тех, кто предлагает хранить суммы числами.
Я не претендую на роль истины или человека, который знает всё. Но что конкретно плохого в выборе Decimal?
А как мы разрулим ситуацию: «три человека скинулись и купили 100 долларов, а потом поссорились и им надо их поделить поровну, а потом помирились — и им снова из трех слагаемых надо получить $100»?
А как бы вы хранили в базе данных иррациональные числа? Честная запись у числа из вашего ответа вообще-то бесконечная. И решать такую проблему можно в том числе так же, как она решалась бы в жизни - кому-то может достаться на один цент больше, или, если повезёт, каждому вместо одного цента достанется экземпляр валюты, которая в моменте позволяет разделить один цент ровно на три (правда, тогда теряется гарантия, что потом это можно будет собрать обратно именно в сто долларов, а не чуть больше или меньше).
В оманском риале — 1000 байз, а в иене — только иена, разменных денежных единиц в Японии нет. И так далее, и тому подобное :)
Эта информация как-то повлияет на тип Decimal? По-моему, такие вещи нужно будет обрабатывать как-то ещё, например, в логике операций. Хотя если настаиваете - договоритесь с @Cels,что для каждой валюты нужен будет свой отдельный класс с правилами.
т.е. вы несколько часов пишете код и только потом запускаете функцию, чтобы проверить работает она или нет?
Это от кода зависит. Иногда и так тоже, да. В моём проекте, к тому же, нельзя просто взять и запустить функцию в вакууме, обвязки вокруг запуска тоже кому-то нужно писать. А иногда на обвязки как раз времени-то и нет.
Ну в смысле "как". На костылях, и после долгой работы над отлавливанием багов по всему стеку. Как и любое ПО. И подход с более вовлечённой типизацией полностью всех проблем не решит, только некоторые.
Какой подтип/подтипы вы сделаете, н-р, для денег (и 15 валют)?
Думаю, что-то типа Monetary{Decimal, Currency}.
Речь шла не про новый класс, а про новый тип, который нужен н-р для См. и Дм.
И почти сразу уже решили, что ничего подобного на самом деле не нужно, а нужен чуток специализированный Quantity{Amount, Unit}. Я правда не понимаю, зачем вы продолжаете эту нить развивать.
дебаг-то запускается при запуске приложения/сервиса, пэтому большой разницы нет - будут ли ошибки во время компиляции или во время первого запуска.
Ну что вы, разница огромна. Как я уже сказал, множество разработчиков работают в условиях инкрементальной компиляции, а вот время первого запуска конкретной функции (не всего приложения) может отличаться от времени написания этой функции на много минут или даже часов.
Для моего проекта вряд ли сходу подойдёт, потому что тестировать надо не каждую комбинацию возможных входных данных, а сценарии действий пользователя, в том числе с имитацией течения времени.
Плюс сама система немаленькая, и у неё куча разных крутилок, которые тоже на всё будут влиять - по моей предварительной оценке, вариантов там может быть столько, что один полный suite займёт больше, чем спринт у разработки.
По поводу листания маркетплейса - кто-то там пользуется деревом категорий?
Я пользуюсь. Мне удобнее найти категорию, затем зайти в фильтры и выбрать там важные аспекты того, что я ищу (обычно два-три пункта).
К сожалению, категории и фильтры на всех таких сайтах, по меньшей мере в РФ, глубоко неадекватны моим запросам - категории неочевидны, фильтров слишком мало, а продавцы не желают нормально заполнять характеристики. У отдельных представителей (команды жёлто-белых) фильтры вообще со временем становятся хуже и неудобнее - видимо, зачем-то реально хотят загонять всех пользователей исключительно в строку поиска (которая, впрочем, тоже работает через одно место, потому что всё перечисленное и для неё верно).
умные системы магазина сами считывают что лежит в корзинке и считают сумму
Вот на этом шаге сейчас всё и рушится. Amazon недавно как раз отказался от идеи таких магазинов, как вы предлагаете, плюс "умные системы магазина" на поверку оказались армией дешёвых работников из Индии, которые по камерам пытались отследить, что же вы там сложили в корзинку. В итоге они просто придумали закрепить по кассовому аппарату на каждую корзинку, чтоб вы сканировали по ходу дела, а не всё сразу. Открыт вопрос, что делать если вы передумали и вернули товар на полку.
А по-моему, пользователи уже привыкли, что расписание свободных часов парикхмахера будет в табличке в виде небольшого календаря с подсвеченными днями, и её можно окинуть взглядом сразу.
И меню в кафе с картинками людям обычно тоже скорее нравится, чем нет - потому что там картинка большая, и место есть и для цены, и для размера порции, и для описания ингредиентов. Такое же меню, но в виде сотни постов с картинками от бота в телеграме (где цена, размеры и ингредиенты - в теле сообщения), по моему, в удобстве проигрывает даже этим дико неудобным скачиваемым pdf-кам.
Угу, и после рандомных решений с ненулевой вероятностью получается codestyle, одинаково ненавистный обоим программистам, поэтому споры прекращаются по естественным причинам, после обработки двух заявлений на увольнение.
Смысл есть - потому что обычно от вашей системы будут ожидать, что вы таки не принимаете дат "25-15-2025", независимо от особенностей работы с датами где угодно (мы же предполагаем ISO-шную систему, а не любую из альтернатив? даже если нет, то это где-то придётся выразить, и почему не в типах данных?). И ещё что вы сортировку по датам сравнительно честную будете делать, а не лексическую в зависимости от того, как эту дату вводил пользователь. Да и просто даты пользователю смотреть будет удобнее, если они все будут в общем форматировании, даже если вводились как придётся. Ничего из перечисленного сделать нормально не получится если их как-то когда-то не парсить. Ну а если вы чаще показываете даты, чем их сохраняете в store - то эффективнее их будет парсить при сохранении, и сохранять таки в соответствующих системных типах.
Стирать из своей системы важные для пользовательского опыта метаданные только потому, что девопсы могут забыть подложить правильный tzdata - это, по-моему, покруче всякого религиозного следования SOLID.
Вы не привязывайтесь к языкам. Пусть это будет ваш лично Decimal, который вообще сам по себе - десятчиное рациональное число с реализацией типа "чёрный ящик". Учитывая, что ни C#, ни Python, по вашим же словам, не имеют в стандартной библиотеке типа, который подходил бы для "серъёзных" финансов - вы либо напишете все операции вокруг существующих численных типов так, чтобы они себя хорошо вели, либо введёте новый тип, который эти операции реализует как вам нужно.
Если же нужно хранить точный результат от деления $100 на три - то лучше будет вместо Decimal назвать это дело Rational, и чёрный ящик ему соответствующий подобрать.
Это дублирование информации. Нет веских причин не включить число 100 куда-то внутрь определения
Ruble, и отображение настроить соответственно.Я, правда, малость не понимаю, куда эта ветка начинает уходить.
Вы не согласны с подходом создания типов для реализации доменной логики, или вам просто сильно хотелось меня "макнуть" в пробелы в моих знаниях (о которых я и сам в курсе)?
Строкой бесконечной длины, что ли?
Или хранить
0.(3)? Но это требует специального парсера, который знает про все эти 22/7. И зачем заморачиваться дописыванием парсера, если то же самое решается хранением "настоящего 9¾" - в трёх связанных целочисленных полях - [9, 3, 4]?Но и миллиард не делится на три нацело (и олимпиард не делится). Либо у кого-то останутся "дополнительные" доллары, либо вам всё-таки надо будет хранить синтетическую треть цента, которую никак не будет возможно обналичить. Да, по отношению к двум людям из трёх это "нечестно", потому что у них будет на цент меньше на момент раздела. Зато чем позже раздел, тем меньше разница. Пусть живут дружно, как завещал Кот Леопольд, я не знаю.
Физическую банкноту в сто долларов на три части вы можете поделить либо ножницами, либо в одной кучке останется 34 цента вместо 33х. Равно как и 0.(3) цента вы никуда не денете, потому что это не настоящие деньги, а математический/программистский артефакт. Все прочие операции вполне можно кодировать либо типом Decimal, либо тем франкенштейном из трёх целых чисел.
Интересно, какая доля общения с голосовыми помощниками состоит из фразы "позови/соедини с человеком".
Продавец и покупатель - оба человека (пока что).
И то, что более выгодно покупателю - одновременно менее выгодно продавцу. Сходятся они где-то посередине.
А теперь - расскажите, почему это продавцы захотят ставить в свой сайт инструмент, который более выгоден покупателям, чем им самим?
В том и дело, что и это не удалось ведь. То чек на оплату несколько часов идёт (потому что нечего полку своим телом загораживать, ага), то товары от другого покупателя (потому что нечего одежда похожая, и спиной стоял).
Ваша правда, забыл уже эти классификации.
В руби-то, может, и есть - а в базе данных? Вот mysql, к примеру, как вроде одна из самых популярных, такой роскошью не обладает, да и в Postgres для этого специальные расширения нужны (и наверняка ещё своя особенная боль от отсутствующей поддержки в binding'ах).
Ну если более реально смотреть, то, конечно, можно для денег сразу выделять три поля с целочисленным типом, чтоб хотя бы рациональные числа хранились точно.
В этом случае тоже потеряется возможность слить их обратно вместе и получить ровно сто долларов. Но с другой стороны, если целью станет сохранить порядок роста - то скорее именно подход с получением одним человеком на цент больше позволит это сделать, так как не произведёт никаких дробных.
Но в том сообщении никто и не обсуждал перевод из разменных единиц в неразменные, вы были первый.
Ну а как же ещё объяснить вашу классификацию программиста (в противовес непрограммистам) как человека, который
?
Если с такими вводными в софте всё равно случаются баги - этому есть только два объяснения:
весь софт написан непрограммистами
программисты сознательно добавляют баги в софт
Уязвимости в том числе вызваны багами, недостаточной внимательностью при разработке, недостаточными проверками границ массивом, и всем прочим.
Проще говоря, CVE существуют из-за того, что на планете нет ни одного "настоящего програмиста".
Я не претендую на роль истины или человека, который знает всё. Но что конкретно плохого в выборе Decimal?
А как бы вы хранили в базе данных иррациональные числа? Честная запись у числа из вашего ответа вообще-то бесконечная. И решать такую проблему можно в том числе так же, как она решалась бы в жизни - кому-то может достаться на один цент больше, или, если повезёт, каждому вместо одного цента достанется экземпляр валюты, которая в моменте позволяет разделить один цент ровно на три (правда, тогда теряется гарантия, что потом это можно будет собрать обратно именно в сто долларов, а не чуть больше или меньше).
Эта информация как-то повлияет на тип Decimal? По-моему, такие вещи нужно будет обрабатывать как-то ещё, например, в логике операций. Хотя если настаиваете - договоритесь с @Cels,что для каждой валюты нужен будет свой отдельный класс с правилами.
Не, там сейчас всегда какие-нибудь сезонные предложения. Скорее всего их люди в основном и смотрят.
Из базы CVE.
Это от кода зависит. Иногда и так тоже, да. В моём проекте, к тому же, нельзя просто взять и запустить функцию в вакууме, обвязки вокруг запуска тоже кому-то нужно писать. А иногда на обвязки как раз времени-то и нет.
И вот поэтому-то движение в политике идёт не в сторону "всем ходить строем", а скорее в сторону "делайте что хотите, только остальным не мешайте".
Это байки. Вон какие протесты повсюду. Кроме того, из политики нельзя уволиться - приходится продолжать спорить.
Ну в смысле "как". На костылях, и после долгой работы над отлавливанием багов по всему стеку. Как и любое ПО. И подход с более вовлечённой типизацией полностью всех проблем не решит, только некоторые.
Думаю, что-то типа
Monetary{Decimal, Currency}.И почти сразу уже решили, что ничего подобного на самом деле не нужно, а нужен чуток специализированный
Quantity{Amount, Unit}. Я правда не понимаю, зачем вы продолжаете эту нить развивать.Ну что вы, разница огромна. Как я уже сказал, множество разработчиков работают в условиях инкрементальной компиляции, а вот время первого запуска конкретной функции (не всего приложения) может отличаться от времени написания этой функции на много минут или даже часов.
Для моего проекта вряд ли сходу подойдёт, потому что тестировать надо не каждую комбинацию возможных входных данных, а сценарии действий пользователя, в том числе с имитацией течения времени.
Плюс сама система немаленькая, и у неё куча разных крутилок, которые тоже на всё будут влиять - по моей предварительной оценке, вариантов там может быть столько, что один полный suite займёт больше, чем спринт у разработки.
Я пользуюсь. Мне удобнее найти категорию, затем зайти в фильтры и выбрать там важные аспекты того, что я ищу (обычно два-три пункта).
К сожалению, категории и фильтры на всех таких сайтах, по меньшей мере в РФ, глубоко неадекватны моим запросам - категории неочевидны, фильтров слишком мало, а продавцы не желают нормально заполнять характеристики. У отдельных представителей (команды жёлто-белых) фильтры вообще со временем становятся хуже и неудобнее - видимо, зачем-то реально хотят загонять всех пользователей исключительно в строку поиска (которая, впрочем, тоже работает через одно место, потому что всё перечисленное и для неё верно).
Недавно же как раз вскрылось, что это не AI был.
Вот на этом шаге сейчас всё и рушится. Amazon недавно как раз отказался от идеи таких магазинов, как вы предлагаете, плюс "умные системы магазина" на поверку оказались армией дешёвых работников из Индии, которые по камерам пытались отследить, что же вы там сложили в корзинку. В итоге они просто придумали закрепить по кассовому аппарату на каждую корзинку, чтоб вы сканировали по ходу дела, а не всё сразу. Открыт вопрос, что делать если вы передумали и вернули товар на полку.
А по-моему, пользователи уже привыкли, что расписание свободных часов парикхмахера будет в табличке в виде небольшого календаря с подсвеченными днями, и её можно окинуть взглядом сразу.
И меню в кафе с картинками людям обычно тоже скорее нравится, чем нет - потому что там картинка большая, и место есть и для цены, и для размера порции, и для описания ингредиентов. Такое же меню, но в виде сотни постов с картинками от бота в телеграме (где цена, размеры и ингредиенты - в теле сообщения), по моему, в удобстве проигрывает даже этим дико неудобным скачиваемым pdf-кам.
Угу, и после рандомных решений с ненулевой вероятностью получается codestyle, одинаково ненавистный обоим программистам, поэтому споры прекращаются по естественным причинам, после обработки двух заявлений на увольнение.