![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Статья про хаскель в проде, где все правильно написано
http://www.stephendiehl.com/posts/production.html
Про типичную опердень и как она умучает рантайм хаскеля:
A common performance problem is that of many small updates updates to records with large numbers of fields. Records of hundreds of fields are somewhat pathological but in practice they show up in a lot of business logic that needs to interact with large database rows. Too much of this can very noticeable impact on GC pressure by doing allocations on each update.
По ходу, рекорды у них лежат плоскими в памяти и каждый раз при апдейте их надо клонировать. Наверно, заменить их на мапы и прочие словари с деревом в кишках реализации будет проще, не говоря уже о невменяемости рекордов в хаскеле в целом.
И про метапрограммирование: Avoid TemplateHaskell. Half the appeal of Haskell is that its high-level design allows you to avoid huge amounts of useless boilerplate code that you have to write in other languages. If you need compile-time code generation, you’re basically saying that either your language or your application design has failed you.
Как без метапрограммирования нормально делать опердени, где 99% кода - это бойлерплейт по перекладыванию между полями разных объектов и БД - хрен его знает.
Всякие ORM с рефлекшенами и кодогенерацией в рантайме - это то же самое, только медленно и уныло.
Про типичную опердень и как она умучает рантайм хаскеля:
A common performance problem is that of many small updates updates to records with large numbers of fields. Records of hundreds of fields are somewhat pathological but in practice they show up in a lot of business logic that needs to interact with large database rows. Too much of this can very noticeable impact on GC pressure by doing allocations on each update.
По ходу, рекорды у них лежат плоскими в памяти и каждый раз при апдейте их надо клонировать. Наверно, заменить их на мапы и прочие словари с деревом в кишках реализации будет проще, не говоря уже о невменяемости рекордов в хаскеле в целом.
И про метапрограммирование: Avoid TemplateHaskell. Half the appeal of Haskell is that its high-level design allows you to avoid huge amounts of useless boilerplate code that you have to write in other languages. If you need compile-time code generation, you’re basically saying that either your language or your application design has failed you.
Как без метапрограммирования нормально делать опердени, где 99% кода - это бойлерплейт по перекладыванию между полями разных объектов и БД - хрен его знает.
Всякие ORM с рефлекшенами и кодогенерацией в рантайме - это то же самое, только медленно и уныло.
no subject
(Замечу, что я специально опустил вопрос документации)
no subject
Если у благородного дона есть чем похвастать, то надо не теории разводить, а показать.
no subject
Благородного дона никто код показывать не просил, ни свой, ни тот, который он считает хорошим. Если бы попросили, то в зависимости от того, кто просил благородный дон мог бы соизволить и кинуть ссылки на пару открытых проектов, а мог бы и нет. Дон то пишет под своим именем и найти публичную часть того, чем он занимаетс никой сложности не составляет, а там уже и решать просить ли что-то у дона, или мимо пройти.
no subject
no subject
Я ж спрашиваю не для того, чтобы поругаться просто так, а для того, чтобы понять предпосылки к утверждению и возможно привести интересные примеры, или хотя бы минимум обоснования мнения человека, с которым я в корне не согласен, что тоже может быть полезно, даже если я не смогу привести интересующие Вас примеры.
P.S. для меня просьба показать "хороший код" должна быть явной, тут её не было.
no subject
У людей очень разные понятия об извращенности дизайна, и разный опыт работы, разная теоритическая база, так в определенных mind set-ах никакая программа на случайно выбранном языке не будет "нормальной".
Это иллюзия. Такое впечатление, что разговор идёт об абстрактной живописи.
no subject
Ещё раз, а то как-то печально диалог движется, ответ на вопрос какие "проекты вы видели, на основе которого делаете такие выводы", является обязательным для продолжения дискусии и приведения примеров (в всяком случае в подветке разговора со мной). Почему это так, написано в комментарии, заставившем вас вспомнить школьный опыт.
no subject
Будем, будем. Основы доказательств там должны были объяснять.
no subject
no subject
no subject
Смотрим моё утверждение.
Как доказывается его неправильность?
Фиг с ним, с дизайном. Есть задачи, для которых Хаскель годен. Достаточно показать хорошие комментарии.
Поскольку я читаю с мейла, ссылки я вижу сразу. Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?
no subject
в моём комментарии приведены программы с хорошим дизайном. Если в Вашем утверждении квантор exists, а не forall, то утверждение является тривиальным, т.к. естественно программисты пишущие извращенный дизайн на любом языке существуют.
> Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?
возьмем произвольный файл, например Cryptol.TypeCheck.Solve. Я не заметил, в каком месте у вас появились "комментарии", или документация теперь == комментарии?
Не забудьте, что теперь бремя доказательства утверждения того, что в обоих приведённых программах плохой *дизайн* лежит на вас. (Тут я напомню, что вы не ответили на мой вопрос, так бы я был рад сам
no subject
В цитате двумя абзацами выше.
Честно говоря, мне даже влом объяснять, почему конструкции вроде
Just (imps,extra) ->
do let su = importImps imps
gs0 = apSubst su gs
или
$ DelayedCt { dctSource = lname
, dctForall = as
, dctAsmps = ps
, dctGoals = us
}, su)
не являются хорошим кодом.
no subject
я бы все же на вашем месте постарался и объяснил. Т.к. если это то, о чем я думаю, то я бы в эту дискуссию не вступал бы изначально.
no subject
Just (implications, side_conditions) -> do let substitutions = importImplications implications new_goals = applySubstitutions substitutions goalsи
... $ DelayedConctraints { delayed_constraints = local_name , delayed_contstraints_universals = type_parameters , delayed_constriants_assumptions = assumed_contraints , delayed_constraints_goals = collected_constraints }, substitutions)то мне остаётся только скромно промолчать.
no subject
Что годится для упражнений ума на лекции или статьи в математическом журнале, который читают по шесть страниц в день, но совершенно не пригодно для коммерческого использования.
Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.
no subject
Замечу, я первый раз читаю этот код, мне просто нравится этот проект и я знаю людей его писавших, плюс использовал немного не заглядывая во-внутрь. Я читаю этот код и не вижу никаких проблем с пониманием того, что там происходит, 1 раз мне пришлось сделать поиск (чтобы понять кто-такой DelayedCT, в редакторе даже этого бы не пришлось, т.к. документацию бы сразу увидел), и мне сразу понятно, что он делает. Поэтому я честно не понимаю, где здесь "кодирование хитроумного решения", и constraint solver-а может проще выглядеть в привычных языках, которые я знаю и имел опыт работы. я вижу, как в императивных языках он будет выглядеть хуже, так, не помещаться на экран, не являться последовательной декомпозицией по типу данных (ADT), быть завернутым в несколько слоёв проекто-специфичных абстракций, и все это будет мешать мне понимать, сопровождать и отлаживать код.
> Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.
Если не лень, то Вы можете рассказать, что вы понимаете под хорошей обработкой ошибок? Ссылки на статьи или книги тоже принимаются.
Тут каждое действие или возвращает результат или ошибку с достаточным (?) контекстом для того, чтобы понять как она произошла. Соотвественно у вызывающего метода есть все возможности по тому, чтобы её обработать, перезапустить, логировать.
no subject
Дело не в языках. На любом языке можно писать понятно и надёжно, а можно так, что работа с кодом превратится в мучение.
Про обработку ошибок рассказывать долго. Это книжку писать надо, а у меня сейчас актуальны другие темы.
no subject
Я, конечно, не скажу какая, но напомню то, о чем я много раз сказал в данном треде, какой код вам показывали, и что не понравилось. Для того, чтобы показать простой пример. Вдруг у вас 40 летний опыт использовпния слабовыразительных императивных языков :) типа си или явы. А любая функциональщина бужеи встречена как этот проект.
Играть покажите мне то, что мне понравится, мне тоже не сильно интересно, особенно при такой подробности аргументации. Так что наверное лучше остаться при мнениях, что хацкелисты пишут неподдерживаемые программы с извращенным дизайном, а мне при том, что мнение человека с недостаточным опытос в ФП малоинтересно при обсуждении ФП и design choices там.
Уточную, что на прочие вопросы в ИТ и программировании мои выводы не распространяются и о той же обработке ошибок можно вполне и поговорить/послушать.
no subject
Да хотя бы потому, что куча переменных из одной и двух букв. Причём, двухбуквенные переменные отличаются одной буквой.
Ещё раз. Я просил показать код, с которым долго работал, в котором искал ошибки или расширял функциональность, и который считает хорошим как по удобству обслуживания, так и по понятности другим людям.
И мне пофиг, какие парадигмы.С Лиспом я знаком давно.
no subject
no subject