Лично у меня немного глаз дёргается, когда я захожу на сайт, а там функционала нет и меня отправляют ставить приложение на телефон (привет некоторым службам доставки продуктов)
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
А в предметную область ты лазил?
Разумеется, как без этого вообще можно хоть что-то путное сделать.
потому что по имени функции было неочевидно, что она делает не только что, что обещает делать в имени
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
и сделать это правильно: не в кишках одного из наших микросервисов, и даже не в обособленном внутреннем артифакте, а там, где этому коду самое место: в оригинальной библиотеке, которой пользуются все
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
И вместо простого сложения чисел (одна инструкция) вы получаете кучу проверок, которые, тем более, надо не забыть везде расставить. Как вы будете проверять, что вы их везде расставили? Опять тесты писать?
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
Да, блин, оно уйдёт пара минут, когда у вас Python 5-й ЯП.
А если брать такого же околонулёвого новичка и задаваться целью, чтобы он понял почему Python такой какой он есть, тут минимум год понадобится и то вряд ли мы добьёмся этой цели в общем случае. Другое дело, что это для программирования вовсе необязательно это всё понимать, что в случае с Python, что в случае с C. В этом и есть суть вопроса.
Вы же пытаетесь быть максимально неудобным в каждом вопросе
Я ж говорю, отзеркалил вашу манеру 1-в-1. Не очень приятно, да? А то у вас двойные стандарты какие-то. Как только речь не о С, так сразу все "почему" сразу закончились. Хотя по факту их за пределами С становится ещё в 100 раз больше.
Такое не получится у вахтовиков. Там обратный эффект. Так как делать нечего, развлечений вокруг нет
Ну, я не знаком с этой спецификой. Сейчас вроде половина развлечений в интернете. Хотя, возможно, речь про вахты в таких условиях, где и интернета тоже нет.
Этим в любом случае придётся озаботиться, чтобы вопрос с капчами решить.
Самокат начал исправлять ситуацию: https://web.samokat.ru/
Думаю, сейчас многие осознают, что не смартфонами едиными юзеры пользуются, и то, что веб-версию можно сделать удобнее, чем мобильную.
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
Разумеется, как без этого вообще можно хоть что-то путное сделать.
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
Если ваш коллега забылся и поставил число не в той СИ или применил не ту формулу, то никакие типы вам не помогут. Только code review и тестирование.
Ну, я ж написал, про анализаторы всякие.
Это довольно специфичные применения. Нельзя сказать, что большая часть бэкенда 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 и ничто не помешает поддерживать оба формата параллельно.