![[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 11:48 pm (UTC)Я, конечно, не скажу какая, но напомню то, о чем я много раз сказал в данном треде, какой код вам показывали, и что не понравилось. Для того, чтобы показать простой пример. Вдруг у вас 40 летний опыт использовпния слабовыразительных императивных языков :) типа си или явы. А любая функциональщина бужеи встречена как этот проект.
Играть покажите мне то, что мне понравится, мне тоже не сильно интересно, особенно при такой подробности аргументации. Так что наверное лучше остаться при мнениях, что хацкелисты пишут неподдерживаемые программы с извращенным дизайном, а мне при том, что мнение человека с недостаточным опытос в ФП малоинтересно при обсуждении ФП и design choices там.
Уточную, что на прочие вопросы в ИТ и программировании мои выводы не распространяются и о той же обработке ошибок можно вполне и поговорить/послушать.
no subject
Date: 2016-02-27 08:08 am (UTC)Да хотя бы потому, что куча переменных из одной и двух букв. Причём, двухбуквенные переменные отличаются одной буквой.
Ещё раз. Я просил показать код, с которым долго работал, в котором искал ошибки или расширял функциональность, и который считает хорошим как по удобству обслуживания, так и по понятности другим людям.
И мне пофиг, какие парадигмы.С Лиспом я знаком давно.