5 ms·

Something about macros that I don't see discussed much is the trade-off between improved clarity of intent vs learning curve for contributors. I don't have a t

by lhorie 5y ago

Something about macros that I don't see discussed much is the trade-off between improved clarity of intent vs learning curve for contributors. I don't have a ton of experience w/ C, but the large projects I've seen appear to have a tendency to avoid heavy macro usage (e.g. using `void *` for hashmap implementations instead of reaching for macros, for example). I see macros appear more frequently among those that prioritize machiavellian cleverness, often under the pretext of squeezing performance: code written by (g|x)ooglers, for example. I'm curious what more experienced C developers think of jumping into projects with heavy usage of macro-based DSLs, especially the syntax-bending variety being suggested here. Does it get in the way of contributing? Or of reasoning about performance? Etc.

Hirrolot 5y ago
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 https://github.com/koka-lang/libmprompt/issues/8
- lhorie 5y ago
  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?
  - Hirrolot 5y ago
    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.
  - Zababa 5y ago
    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.
nomel 5y ago
> 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.
- tpoacher 5y ago
  Simplicity is elegance.
  - nomel 5y ago
    "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".
bumbada 5y ago
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.
fsociety 5y ago
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.
- Hirrolot 5y ago
  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-alter-it.html https://hirrolot.github.io/posts/extend-your-language-dont-a...
glouwbug 5y ago
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

by lhorie 5y ago

Hirrolot 5y ago

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 https://github.com/koka-lang/libmprompt/issues/8

lhorie 5y ago
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?
- Hirrolot 5y ago
  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.
- Zababa 5y ago
  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.

nomel 5y ago

> 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.

tpoacher 5y ago
Simplicity is elegance.
- nomel 5y ago
  "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".

bumbada 5y ago

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.

fsociety 5y ago

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.

Hirrolot 5y ago
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-alter-it.html https://hirrolot.github.io/posts/extend-your-language-dont-a...

glouwbug 5y ago

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