> vs learning curve for contributors

Early on in my programming career, I implemented all sorts of beautiful magic, but I was alone. Later, I realized that beautiful magic was keeping me alone. Now, much later in my career, I program mostly like a novice. I don't write clever code, I unroll powerful one liners into boring for loops, and I use all sorts of temporary variables to make intent perfectly clear, because I want and need as much help as I can get. Confusing contributors for some wanky obsession with "terseness" or "elegance" is a good indication of either a great team, or someone that works alone.

Simplicity is elegance.

"Simplicity" is also not well defined, and seems to be very very different for a novice or more advanced coder. Many seem to think fewer lines of code means simpler, or chaining 20 lines/calls is clearer than temporary variables, or use lambdas everywhere is better since function definitions are harder to grok. From my experience, elegance is often something very clever, and elegant by definition, but also nearly impossible to understand.

So, I guess "simplicity in understanding".

I have seen complex macros a lot and talked with the people that made them.

Most of them just were not conscious of the consequences of their behavior. E.g this behavior is typical of someone that programs for a living but does not debug her own code, because someone else in the company does. So she is isolated from the consequences of her actions.

For making them understand it is as easy as making the debugger people to program and the programming people to debug for a while.

Nothing like making people miserable suffering from bad source code they have themselves created for making them understand.

Then you give them solutions for their misery and they learn pretty fast.

Experienced C programmers tend to avoid the trap of using heavy macros because they have learned. But at the same time they look for alternatives that make them more productive with some king of real metaprogramming.

I'm currently using Datatype99 & Interface99 at work.

What can I say? Everything goes well, nothing critical has appeared soon, my coworkers are able to understand the code.

Regarding macro-based eDSLs, I would not resort to them for needs other than abstractions to be considered as a part of the language (ADTs, interfaces, etc.), since they are like languages on their own; when you try to understand/contribute to eDSL-based code, you have to understand its syntax and semantics, aside from how does it actually solve a particular problem in the problem domain.

In fact, as for now, I don't see much need in something like Metalang99 except for Datatype99 & Interface99 (and probably my feature request to libmprompt [1]).

[1]: https://github.com/koka-lang/libmprompt/issues/8

That's interesting. The reason I'm asking is that I'm interested in the open source adoption angle. For example, say Linux went ham on DSLs, would people unwillingly learn it for the sake of being able to be part of the large community, would they embrace it as if it's the next best thing after sliced bread, or is that just never going to happen because of some strong conceptual aversion to the paradigm? Or say a not-so-known C projects wants to gain adoption/popularity, would the choice of using DSLs be a showstopping consideration?

I'd say it can be the opposite. If the DSL is addressing a real and common problem in C codebase, it's better to use it and that everyone use it rather than have everyone create their own special DSL.

I'd wager no, as long as you remain sane and do not pollute everything with fancy macro eDSLs. Specifically Datatype99 & Interface99 can be good for newcomers because they make code more concise, less intimidating and intricate.

My issue with macros is that how they are used can vary greatly because it is so flexible. I’ve worked in a codebase where we treated macros like someone might treat C++ templates and it was great.

For example, I think x-macros can be super useful and a consistent way to define certain data structures.

But using macros to define your own special DSL and make C code not look like C code is pretty nasty.

I don't think the suggested metaprograms in the blog post don't look like C, in opposite [1].

[1]: https://hirrolot.github.io/posts/extend-your-language-dont-a...

Templated C is totally possible. It’s just a little verbose, but you get used to it. For instance, an alternative to void pointers while maintaining compile time type safety and gaining speed and maintainability looks something like this:

github.com/glouw/ctl

Check CTL/vec.h, for instance