Rostyslav Dzinko :: Deep in Code

Have you ever been working on a really large product? If you have ever worked with C++, C#, or Java programming languages you've definitely been involved in writing build scripts for make, make, maven, babel, or other, possibly even custom-developed build systems. And that's... That's a pain in the ass... Really, more is needed to code the project, you are also coding how to build the project. These scripts tend to grow in size to the extent that it does not look like a simple collection of source file path sets but rather a framework with its own rules. If the application is cross-platform things become much worse: rules are complicated, workarounds increase drastically, and eventually, your build system becomes a risky component of the whole product itself. If you do not understand the pain, just check out an Unreal Engine build system which is a custom build system written in C#, or check an O3DE cmake build scripts , or, for example,  Mozilla Build System (I like how

This is a humble endeavor to briefly cover the modern state of metaprogramming. Not All Runtime Code Is Written By Programmers Metaprogramming itself is not a new approach to writing software. It originates in the 1970s and since that time even became a popular coding style for Lisp programmers. It is also widely used in interpreted languages like Python for different purposes like unit-testing and alternating existing code behavior (for example, the  gevent  library uses this approach to  patch standard library objects  to express its behavior via standard library APIs). The common thing between these two examples is that we were talking about metaprogramming in either interpreted or JIT-compiled language. As a result of my personal programming experience and languages I've been using for years, I've always been mentally stuck to the fact that all runtime code (or at least the most significant parts) in a program is created by a software engineer itself, and, well, it's st