![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclasshttp://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 с рефлекшенами и кодогенерацией в рантайме - это то же самое, только медленно и уныло.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-02-26 08:25 pm (UTC)(Замечу, что я специально опустил вопрос документации)
no subject
Date: 2016-02-26 08:32 pm (UTC)Если у благородного дона есть чем похвастать, то надо не теории разводить, а показать.
no subject
Date: 2016-02-26 08:39 pm (UTC)Благородного дона никто код показывать не просил, ни свой, ни тот, который он считает хорошим. Если бы попросили, то в зависимости от того, кто просил благородный дон мог бы соизволить и кинуть ссылки на пару открытых проектов, а мог бы и нет. Дон то пишет под своим именем и найти публичную часть того, чем он занимаетс никой сложности не составляет, а там уже и решать просить ли что-то у дона, или мимо пройти.
no subject
Date: 2016-02-26 08:43 pm (UTC)no subject
Date: 2016-02-26 08:53 pm (UTC)Я ж спрашиваю не для того, чтобы поругаться просто так, а для того, чтобы понять предпосылки к утверждению и возможно привести интересные примеры, или хотя бы минимум обоснования мнения человека, с которым я в корне не согласен, что тоже может быть полезно, даже если я не смогу привести интересующие Вас примеры.
P.S. для меня просьба показать "хороший код" должна быть явной, тут её не было.
no subject
Date: 2016-02-26 09:32 pm (UTC)У людей очень разные понятия об извращенности дизайна, и разный опыт работы, разная теоритическая база, так в определенных mind set-ах никакая программа на случайно выбранном языке не будет "нормальной".
Это иллюзия. Такое впечатление, что разговор идёт об абстрактной живописи.
no subject
Date: 2016-02-26 09:42 pm (UTC)Ещё раз, а то как-то печально диалог движется, ответ на вопрос какие "проекты вы видели, на основе которого делаете такие выводы", является обязательным для продолжения дискусии и приведения примеров (в всяком случае в подветке разговора со мной). Почему это так, написано в комментарии, заставившем вас вспомнить школьный опыт.
no subject
Date: 2016-02-26 10:01 pm (UTC)Будем, будем. Основы доказательств там должны были объяснять.
no subject
Date: 2016-02-26 10:06 pm (UTC)no subject
Date: 2016-02-26 10:08 pm (UTC)no subject
Date: 2016-02-26 10:34 pm (UTC)Смотрим моё утверждение.
Как доказывается его неправильность?
Фиг с ним, с дизайном. Есть задачи, для которых Хаскель годен. Достаточно показать хорошие комментарии.
Поскольку я читаю с мейла, ссылки я вижу сразу. Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?
no subject
Date: 2016-02-26 10:43 pm (UTC)в моём комментарии приведены программы с хорошим дизайном. Если в Вашем утверждении квантор exists, а не forall, то утверждение является тривиальным, т.к. естественно программисты пишущие извращенный дизайн на любом языке существуют.
> Какой файл в этом cryptol содержит хорошие комментарии и хорошую обработку ошибок?
возьмем произвольный файл, например Cryptol.TypeCheck.Solve. Я не заметил, в каком месте у вас появились "комментарии", или документация теперь == комментарии?
Не забудьте, что теперь бремя доказательства утверждения того, что в обоих приведённых программах плохой *дизайн* лежит на вас. (Тут я напомню, что вы не ответили на мой вопрос, так бы я был рад сам
no subject
Date: 2016-02-26 10:55 pm (UTC)В цитате двумя абзацами выше.
Честно говоря, мне даже влом объяснять, почему конструкции вроде
Just (imps,extra) ->
do let su = importImps imps
gs0 = apSubst su gs
или
$ DelayedCt { dctSource = lname
, dctForall = as
, dctAsmps = ps
, dctGoals = us
}, su)
не являются хорошим кодом.
no subject
Date: 2016-02-26 10:59 pm (UTC)я бы все же на вашем месте постарался и объяснил. Т.к. если это то, о чем я думаю, то я бы в эту дискуссию не вступал бы изначально.
no subject
Date: 2016-02-26 11:08 pm (UTC)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
Date: 2016-02-26 11:09 pm (UTC)Что годится для упражнений ума на лекции или статьи в математическом журнале, который читают по шесть страниц в день, но совершенно не пригодно для коммерческого использования.
Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.
no subject
Date: 2016-02-26 11:24 pm (UTC)Замечу, я первый раз читаю этот код, мне просто нравится этот проект и я знаю людей его писавших, плюс использовал немного не заглядывая во-внутрь. Я читаю этот код и не вижу никаких проблем с пониманием того, что там происходит, 1 раз мне пришлось сделать поиск (чтобы понять кто-такой DelayedCT, в редакторе даже этого бы не пришлось, т.к. документацию бы сразу увидел), и мне сразу понятно, что он делает. Поэтому я честно не понимаю, где здесь "кодирование хитроумного решения", и constraint solver-а может проще выглядеть в привычных языках, которые я знаю и имел опыт работы. я вижу, как в императивных языках он будет выглядеть хуже, так, не помещаться на экран, не являться последовательной декомпозицией по типу данных (ADT), быть завернутым в несколько слоёв проекто-специфичных абстракций, и все это будет мешать мне понимать, сопровождать и отлаживать код.
> Плюс обработка ошибок хреновая. Впрочем, с ними практически никто работать не умеет.
Если не лень, то Вы можете рассказать, что вы понимаете под хорошей обработкой ошибок? Ссылки на статьи или книги тоже принимаются.
Тут каждое действие или возвращает результат или ошибку с достаточным (?) контекстом для того, чтобы понять как она произошла. Соотвественно у вызывающего метода есть все возможности по тому, чтобы её обработать, перезапустить, логировать.
no subject
Date: 2016-02-26 11:37 pm (UTC)Дело не в языках. На любом языке можно писать понятно и надёжно, а можно так, что работа с кодом превратится в мучение.
Про обработку ошибок рассказывать долго. Это книжку писать надо, а у меня сейчас актуальны другие темы.
no subject
Date: 2016-02-26 11:48 pm (UTC)Я, конечно, не скажу какая, но напомню то, о чем я много раз сказал в данном треде, какой код вам показывали, и что не понравилось. Для того, чтобы показать простой пример. Вдруг у вас 40 летний опыт использовпния слабовыразительных императивных языков :) типа си или явы. А любая функциональщина бужеи встречена как этот проект.
Играть покажите мне то, что мне понравится, мне тоже не сильно интересно, особенно при такой подробности аргументации. Так что наверное лучше остаться при мнениях, что хацкелисты пишут неподдерживаемые программы с извращенным дизайном, а мне при том, что мнение человека с недостаточным опытос в ФП малоинтересно при обсуждении ФП и design choices там.
Уточную, что на прочие вопросы в ИТ и программировании мои выводы не распространяются и о той же обработке ошибок можно вполне и поговорить/послушать.
no subject
Date: 2016-02-27 08:08 am (UTC)Да хотя бы потому, что куча переменных из одной и двух букв. Причём, двухбуквенные переменные отличаются одной буквой.
Ещё раз. Я просил показать код, с которым долго работал, в котором искал ошибки или расширял функциональность, и который считает хорошим как по удобству обслуживания, так и по понятности другим людям.
И мне пофиг, какие парадигмы.С Лиспом я знаком давно.
no subject
Date: 2016-02-26 10:41 pm (UTC)no subject
Date: 2016-02-26 10:45 pm (UTC)