![[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
2) Запись не плоская. Запись это, буквально, массив указателей. Для 100 полей - да. 100 указателей надо скопировать. Вроде бы, наивное поведение было бы столько раз копировать, сколько раз обновляем поля (по одному). Но это, обычно, упрощается - выделили один раз, перенесли 84 указателя, 16 заполнили новыми значениями.
Строгие (!Q) поля не указатели, если они хранят данные размером до указателя.
3) Сейчас в Хаскель вносят зависимые типы, практически. Поэтому не TH, а типы. Для типов есть методика устранения ненужных доказательств (если ты нигде не используешь параметр "длина" вектора, то он будет убран из кода вообще).
no subject
no subject
TH все еще нужен, т.к. он выразительнее, чем Generic даже в sop варианте. Другое дело, что TH код сложнее писать, однако в большинстве случаев TH надо применять, готовый, а не писать самому. Имхо бояться его не надо, если есть возможость обойтись, то обходиться, нету - ничего страшного.
Вообще статья достаточно странная, не хацкелистам крайне не рекомендуется.