Hi Denis,

Indeed, it was strange, but it was to express a feeling that I was having.

Compiler theory is more than compilers, it is about transforming data into executable code. We often limit ourselves to static structures, patterns, etc. and we forget about all the flexibility, and expressiveness, that we can achieve.

Gherkin is a language that help teams to defined and understand the test. With teams, I mean all the roles, not just developers. That is because Gherkin reads like English, although it is a kind of DSL. Gherkin itself is a great example, it requires a special compiler, and we as programmers need to write glue code to make it work.

Another great example, is the one that comes from a talk of a friend of mine. He wrote a feature file (gherkin) for a minesweeper game, before the presentation, we discussed it a lot, and we agreed that you should be able to see the board in some fashion. So, in addition to the gherkin parsing, he added a tool to parse boards, so you can see the board in the test file directly. It is here.

In my understanding, compiler, and compiler technology, it is not limited to compilers (like GCC) but also to all the tools related to it: parsing, ASTs, transformers, ... For example, JavaScript "is not compiled", but interpreted, but you need all the compiler technology. The script allows the application to generate new code beyond the one programmed by its original authors, so it is kind of self-modifying. But techniques like JIT (just in time compilers), like the ones in Java or JS, are truly self-modifying, they monitor the program execution, and recompile the program, so its execution can be optimized.

Uf, it got larger than expected (that is why I avoided exact cases, the list is long). Anyway,

Thanks for asking!