3 ms·

> I just write a regular C program that processes some source files and output source files and run that first in by build script. Cool, you now invented your

by adev_ 2y ago

> I just write a regular C program that processes some source files and output source files and run that first in by build script. Cool, you now invented your own DSL and half-baked meta programming macro language for something that shall have been in the language to begin with. In addition, any complex interaction between your "own made template engine" and the native code is now a pile of hack. E.g write a generic function: Good luck to interpret any error based on the typing. Code generation is almost consistently the worst solution to a meta-programming problem.

kreco 2y ago
> Cool, you now invented your own DSL and half-baked meta programming macro language I'm not sure I'm following your statement. What he said was to use a C program to parse C code and emit additional C code. There is no mention of DSL. > for something that shall have been in the language to begin with. The whole point of this discussion is to debate on that. I have no strong opinion (yet) but the meta program looks easy to understand compared to the pandora box of metaprogrammaing withing the language (since it requires standardization, limitations etc.).
- ezwoodland 2y ago
  I think the parsed c program is the DSL. You have to write a parser and compiler for the c-like source to the actual c code.
- adev_ 2y ago
  > What he said was to use a C program to parse C code and emit additional C code. There is no mention of DSL Because it is always the same story: - You start by writing a little meta-compiler to solve one specific codegen problem in a specific portion your code. - Then you realize their is many slight variations of this problem in other areas of your project or other projects... because it is exactly what *Genericity* is all about. And we know that since literally the 1970s and freaking LISP. - To avoid your meta-compiler to become a Frankenstein of options with endless hardcoded logic: you make it interpret some annotations in C comments, some preprocessors or some template files somewhere. -> Congratulations: you invented your own half baked DSL. I have seen that many time, in many places. Again and again. Often because there is a category of C programmers that would prefer to swim in their own shit instead of using few C++ templates. Codegen is consistently a terrible solution to a well studied problem: meta-programming. The fear of the feature creep (templates, macros) shall never be a justification to create some half baked complexity monster that will alaways finish worst than the problem they try to avoid. If you doubt about that: Just use a lexer or parser generator. Or better, the quintessence of codegen: Autotools. They are a perfect illustration of how terrible and how fucking unmaintainable Codegen is. I can think of a single use case where a meta-compiler and a DSL are appropriate solutions: *Serialization* (Protobuf, Thrift, CapNProto, ...). Because in this precise case, you actually do want a language neutral way to express your interface: you want an IDL. Currently here, Zig does the right thing: Comptime execution for meta-programming is one order of magnitude better than anything available in C or C++ before C++20
coliveira 2y ago
The notion of "something that shall have been in the language" is not properly defined, as you can basically start from that and arrive at C++. So it is perfectly fine to assume that compile-time programming does not belong into the language and write your own processor. As for DSL, any DSL is a separate language that needs to be learned, so it is not very different from creating your own processor.

by adev_ 2y ago

kreco 2y ago

> Cool, you now invented your own DSL and half-baked meta programming macro language I'm not sure I'm following your statement. What he said was to use a C program to parse C code and emit additional C code. There is no mention of DSL. > for something that shall have been in the language to begin with. The whole point of this discussion is to debate on that. I have no strong opinion (yet) but the meta program looks easy to understand compared to the pandora box of metaprogrammaing withing the language (since it requires standardization, limitations etc.).

ezwoodland 2y ago
I think the parsed c program is the DSL. You have to write a parser and compiler for the c-like source to the actual c code.
adev_ 2y ago
> What he said was to use a C program to parse C code and emit additional C code. There is no mention of DSL Because it is always the same story: - You start by writing a little meta-compiler to solve one specific codegen problem in a specific portion your code. - Then you realize their is many slight variations of this problem in other areas of your project or other projects... because it is exactly what *Genericity* is all about. And we know that since literally the 1970s and freaking LISP. - To avoid your meta-compiler to become a Frankenstein of options with endless hardcoded logic: you make it interpret some annotations in C comments, some preprocessors or some template files somewhere. -> Congratulations: you invented your own half baked DSL. I have seen that many time, in many places. Again and again. Often because there is a category of C programmers that would prefer to swim in their own shit instead of using few C++ templates. Codegen is consistently a terrible solution to a well studied problem: meta-programming. The fear of the feature creep (templates, macros) shall never be a justification to create some half baked complexity monster that will alaways finish worst than the problem they try to avoid. If you doubt about that: Just use a lexer or parser generator. Or better, the quintessence of codegen: Autotools. They are a perfect illustration of how terrible and how fucking unmaintainable Codegen is. I can think of a single use case where a meta-compiler and a DSL are appropriate solutions: *Serialization* (Protobuf, Thrift, CapNProto, ...). Because in this precise case, you actually do want a language neutral way to express your interface: you want an IDL. Currently here, Zig does the right thing: Comptime execution for meta-programming is one order of magnitude better than anything available in C or C++ before C++20

coliveira 2y ago

The notion of "something that shall have been in the language" is not properly defined, as you can basically start from that and arrive at C++. So it is perfectly fine to assume that compile-time programming does not belong into the language and write your own processor. As for DSL, any DSL is a separate language that needs to be learned, so it is not very different from creating your own processor.