Code generation: Poor man’s macros
June 19, 2021 – 100 days to offload countdown #88
I love macros. I would love to get paid to develop in rust or elixier, or in the best case some lisp dialect – that would be awesome. But I get paid to write, for the most part, php code.
Everybody and their dog loves to make fun of php developers, and every day stackoverflow is accepting questions tagged with php basically proves them right. I will gather some thoughts on why php as a programming language is better than its still rightly deserved public image some of these days. Having to write 100 posts in a short time frame can make someone desperate for things to write about.
In a language with real macros, which I see as code generation as
first class citizen of a language, things that are orthogonal to the
codes main purpose, like access control, caching, data sanity checks,
can be expressed concisely with a single line of code that expands to
the real deal, cutting down on boiler plate code and easing future
enhancements and fixes immensely. In php we use the reflection API
and comment tags to inform the generation of the final code
(e.g. @cache TTL
). Whenever possible using the language itself to
create the final code is preferable to using an external tool like m4
or homegrown awk programs. php has anotations now, we will use these
to replace doc-tags.
I once developed a j2ee based service, and without code generation this would have been a reason to quit the job – java as a language was so unsuitable to implment the j2ee concepts, 75% of the code written for a service was boilerplate code, if that would have to be written by hand, it would never have taken off.
Another range of problems suitable for code generation is data manipulation - seperate the filter and transformation logic from the code enables a devide and conquer approach and eases adaption of systems.