[Const-me]

I agree about learning experience. But when I need a tiny language, I usually implement them so they compile into something already implemented and supported. Not necessarily .NET bytecode, here’s an example where I compiled a tiny language into HLSL source for the Microsoft’s shader compiler: https://github.com/Const-me/vis_avs_dx/tree/master/avs_dx/Dx...

[stevekemp]

Yeah sometimes that works. I wanted to write a "compiler" for brainfuck recently. So my first step was converting a BF program to C, then using gcc to compile that.

I guess my actual compiler wasn't so different, just generated an assembly source-file then passed that through an assembler. But that kind of transpiling is pretty simple to get working, and if your destination language is fast enough, or optimized enough, then it'll work just fine.

https://github.com/skx/bfcc/

[codr7]

From my experience, writing your own gives you a level of control and leverage not achievable through a third party VM that might be worth it once you get some practice. As long as you haven't tried, you have no idea about the trade-offs, goes for anything.

Same goes for not compiling all the way down to byte code (or even worse, C), makes some things easier to implement and allows more flexibility because of the lack of separation between compile time and run time.