Статья про хаскель в проде, где все правильно написано

[metaclass]

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 с рефлекшенами и кодогенерацией в рантайме - это то же самое, только медленно и уныло.

Comments

[vit-r.livejournal.com]

Ещё раз.
Смотрим моё утверждение.
Как доказывается его неправильность?

Фиг с ним, с дизайном. Есть задачи, для которых Хаскель годен. Достаточно показать хорошие комментарии.

Поскольку я читаю с мейла, ссылки я вижу сразу. Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?

[qnikst (from livejournal.com)]

> У меня подозрение, что люди, программирующие на Хаскеле, пишут очень хреновые комментарии и создают извращённый дизайн. Поэтому ...

в моём комментарии приведены программы с хорошим дизайном. Если в Вашем утверждении квантор exists, а не forall, то утверждение является тривиальным, т.к. естественно программисты пишущие извращенный дизайн на любом языке существуют.

> Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?

возьмем произвольный файл, например Cryptol.TypeCheck.Solve. Я не заметил, в каком месте у вас появились "комментарии", или документация теперь == комментарии?

Не забудьте, что теперь бремя доказательства утверждения того, что в обоих приведённых программах плохой *дизайн* лежит на вас. (Тут я напомню, что вы не ответили на мой вопрос, так бы я был рад сам

[vit-r.livejournal.com]

Я не заметил, в каком месте у вас появились "комментарии

В цитате двумя абзацами выше.

Честно говоря, мне даже влом объяснять, почему конструкции вроде

Just (imps,extra) ->
do let su = importImps imps
gs0 = apSubst su gs

или
$ DelayedCt { dctSource = lname
, dctForall = as
, dctAsmps = ps
, dctGoals = us
}, su)

не являются хорошим кодом.

[qnikst (from livejournal.com)]

про комментарии принято.

я бы все же на вашем месте постарался и объяснил. Т.к. если это то, о чем я думаю, то я бы в эту дискуссию не вступал бы изначально.

[qnikst (from livejournal.com)]

т.к. если это предположение о том, что код должен быть написан как:

   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)

то мне остаётся только скромно промолчать.

[vit-r.livejournal.com]

Любители Хаскеля не пишут код, а кодируют хитроумное решение.

Что годится для упражнений ума на лекции или статьи в математическом журнале, который читают по шесть страниц в день, но совершенно не пригодно для коммерческого использования.

Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.

[qnikst (from livejournal.com)]

Я, честно, вас не понимаю.

Замечу, я первый раз читаю этот код, мне просто нравится этот проект и я знаю людей его писавших, плюс использовал немного не заглядывая во-внутрь. Я читаю этот код и не вижу никаких проблем с пониманием того, что там происходит, 1 раз мне пришлось сделать поиск (чтобы понять кто-такой DelayedCT, в редакторе даже этого бы не пришлось, т.к. документацию бы сразу увидел), и мне сразу понятно, что он делает. Поэтому я честно не понимаю, где здесь "кодирование хитроумного решения", и constraint solver-а может проще выглядеть в привычных языках, которые я знаю и имел опыт работы. я вижу, как в императивных языках он будет выглядеть хуже, так, не помещаться на экран, не являться последовательной декомпозицией по типу данных (ADT), быть завернутым в несколько слоёв проекто-специфичных абстракций, и все это будет мешать мне понимать, сопровождать и отлаживать код.

> Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.

Если не лень, то Вы можете рассказать, что вы понимаете под хорошей обработкой ошибок? Ссылки на статьи или книги тоже принимаются.

Тут каждое действие или возвращает результат или ошибку с достаточным (?) контекстом для того, чтобы понять как она произошла. Соотвественно у вызывающего метода есть все возможности по тому, чтобы её обработать, перезапустить, логировать.

[vit-r.livejournal.com]

Я преследую свои личные цели. В очередном показанном коде я не вижу того, что заявлено.

Дело не в языках. На любом языке можно писать понятно и надёжно, а можно так, что работа с кодом превратится в мучение.

Про обработку ошибок рассказывать долго. Это книжку писать надо, а у меня сейчас актуальны другие темы.

[qnikst (from livejournal.com)]

Смотрите, мы пришли к тупику, вы выделили 2 элементарных куска кода и сказали, что он сложный и непонятный и ненадежный. При этом я смотря на этот код не вижу того, что он сложный, он для меня понятный и я не вижу ни одной причины пояему он не надежный. Какая-то тут проблема, не находите?

Я, конечно, не скажу какая, но напомню то, о чем я много раз сказал в данном треде, какой код вам показывали, и что не понравилось. Для того, чтобы показать простой пример. Вдруг у вас 40 летний опыт использовпния слабовыразительных императивных языков :) типа си или явы. А любая функциональщина бужеи встречена как этот проект.
Играть покажите мне то, что мне понравится, мне тоже не сильно интересно, особенно при такой подробности аргументации. Так что наверное лучше остаться при мнениях, что хацкелисты пишут неподдерживаемые программы с извращенным дизайном, а мне при том, что мнение человека с недостаточным опытос в ФП малоинтересно при обсуждении ФП и design choices там.
Уточную, что на прочие вопросы в ИТ и программировании мои выводы не распространяются и о той же обработке ошибок можно вполне и поговорить/послушать.

[vit-r.livejournal.com]

я не вижу ни одной причины пояему он не надежный

Да хотя бы потому, что куча переменных из одной и двух букв. Причём, двухбуквенные переменные отличаются одной буквой.

Ещё раз. Я просил показать код, с которым долго работал, в котором искал ошибки или расширял функциональность, и который считает хорошим как по удобству обслуживания, так и по понятности другим людям.

И мне пофиг, какие парадигмы.С Лиспом я знаком давно.