# Less magic in FRAME, good or bad?

**URL:** <https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287>\
**Category:** Tech Talk\
**Tags:** frame\
**Created:** [March 10, 2023, 3:40pm UTC](https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287 "2023-03-10T15:40:36Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\
**Post date:** [March 13, 2023, 4:26pm UTC](https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287/8 "2023-03-13T16:26:09Z")

</div>

> [@Abdulbee](#):
>
> FRAME is complex, partly because of its heavy use **of “behind the scenes” code** and **some of the most complex rust paradigms**

This sentence hits an interesting point that I want to emphasize.

There is two types of complexity, native to language (what you called “_complex rust paradigms_”), and hiding it behind a lot of code generated in a macro (what you called “_behind the scenes code_”).

Two nice examples of the former are:

1. a trait that has been mostly auto-implemented, and you finish it by providing the rest of the the items.
2. By implementing a single trait on your type, you get access to lot more functionality by a lot of blanket implementations provided by FRAME.

These are _good_ abstractions. If you find these hard, or want less of them, I would (opinionatedly) say that FRAME and Rust is not the right tool for you.

But the latter type, the bad abstractions, are those that generate too much code that you cannot even see behind the curtain. The old `decl_xxx` macros were the best example of this anti-pattern.

Even if there is going to be code auto-generated, the macro syntax should resemble real Rust abstraction sufficiently to make the code understandable.

Derive macros are an example of this. They _do generate some code under the rug_ (as @tomaka phrased it), but are they bad? I don’t think so.

The best example here, in my opinion, is the existing `construct_runtime`. See [this suggestion](https://github.com/paritytech/substrate/issues/13137#issuecomment-1383140186) of how it can be simplified, and made easier to reason about, compared to the existing one. It is still a macro, it still generates code, but, under a more transparent rug, so to speak.

---

_[View the full topic](https://forum.polkadot.network/t/less-magic-in-frame-good-or-bad/2287)._