В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
и сделать это правильно: не в кишках одного из наших микросервисов, и даже не в обособленном внутреннем артифакте, а там, где этому коду самое место: в оригинальной библиотеке, которой пользуются все
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
И вместо простого сложения чисел (одна инструкция) вы получаете кучу проверок, которые, тем более, надо не забыть везде расставить. Как вы будете проверять, что вы их везде расставили? Опять тесты писать?
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
Да, блин, оно уйдёт пара минут, когда у вас Python 5-й ЯП.
А если брать такого же околонулёвого новичка и задаваться целью, чтобы он понял почему Python такой какой он есть, тут минимум год понадобится и то вряд ли мы добьёмся этой цели в общем случае. Другое дело, что это для программирования вовсе необязательно это всё понимать, что в случае с Python, что в случае с C. В этом и есть суть вопроса.
Вы же пытаетесь быть максимально неудобным в каждом вопросе
Я ж говорю, отзеркалил вашу манеру 1-в-1. Не очень приятно, да? А то у вас двойные стандарты какие-то. Как только речь не о С, так сразу все "почему" сразу закончились. Хотя по факту их за пределами С становится ещё в 100 раз больше.
Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет
Ну, я не знаком с этой спецификой. Сейчас вроде половина развлечений в интернете. Хотя, возможно, речь про вахты в таких условиях, где и интернета тоже нет.
Вообще-то пойнт о том, что TTM страдает от типов был начальным. И вы по сути согласились с этим, сославшись лишь на то, что без типов вам не спокойно за то, что вы выкатили в прод. Дальше уже чисто оффтопик пошёл.
Ну, я ж написал, про анализаторы всякие.
Это довольно специфичные применения. Нельзя сказать, что большая часть бэкенда Facebook на Haskell написана, там скорее PHP, а у GitHub - Ruby.
Я имел в виду детали. Что из себя этот пользовательский тип представляет. Плюс дальше ещё MySQL фигурирует.
В целом, можно это и по ссылке в самом проекте посмотреть. Это так, для полноты статьи скорее.
В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
Круто! В Elixir я тоже контрибьютил по мелочи. Но меня частое переключение контекста выматывает.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
Очевидно же, что выше web backend обсуждался, не?
Хочется верить, что к разработке бортовых компьютеров другие методологии применяются)
Да, блин, оно уйдёт пара минут, когда у вас Python 5-й ЯП.
А если брать такого же околонулёвого новичка и задаваться целью, чтобы он понял почему Python такой какой он есть, тут минимум год понадобится и то вряд ли мы добьёмся этой цели в общем случае. Другое дело, что это для программирования вовсе необязательно это всё понимать, что в случае с Python, что в случае с C. В этом и есть суть вопроса.
Я ж говорю, отзеркалил вашу манеру 1-в-1. Не очень приятно, да?
А то у вас двойные стандарты какие-то. Как только речь не о С, так сразу все "почему" сразу закончились. Хотя по факту их за пределами С становится ещё в 100 раз больше.
Ну, я не знаком с этой спецификой. Сейчас вроде половина развлечений в интернете. Хотя, возможно, речь про вахты в таких условиях, где и интернета тоже нет.
Семантика этого поля зависит от бизнес-требований, которые постоянно меняются. Поэтому фиксировать её в типах неразумно дорого.
И даже JSON может однажды поменяться на какой-нибудь Avro и ничто не помешает поддерживать оба формата параллельно.
Вообще-то пойнт о том, что TTM страдает от типов был начальным. И вы по сути согласились с этим, сославшись лишь на то, что без типов вам не спокойно за то, что вы выкатили в прод. Дальше уже чисто оффтопик пошёл.
Как мы с бекенда переместились в бортовой компьютер? Я вас теперь как мастера переобувания запомню))
Впрочем, ваш пример пока не критичный, раз уж единицы измерения известны, то мы просто конвертнули в общую СИ и едем дальше.
Я просто зеркалю ваши вопросы по C. Поверьте, с вашим подходом доебаться до Python гораздо проще, потому что принципы его работы на порядок сложнее C.
Python не является ОО-языком.
Я нахожу странной манеру ставить двоеточие и потом перечислять пункты никак не связанные с определением того, что было до двоеточия)
Ну вот, а я думал, вы в коммерческий успех Idris верите
При сильной (пусть и динамической) типизации такое не прокатит.
Что, что. Pattern matching и дальнейшую обработку.