Lyth: A Naive Attempt at Catching the Road Runner
Published: 2020-02-17 02:09:25

I got a *"Wile E. Coyote"* obsession running through my mind for days now, trying desperately to catch the idée fixe that I should definitely drop my rock into this **reg** known as *yet another language*, and build yet another assembler for an embedded project.

I take as fact that Carnivorous Vulgaris, especially those who are not born yesterday, will likely - and with reason! - roll their eyes, sigh and ask that same old question, the one they keep repeating with a sickened tone... *Why would you do that?* Nothing today can beat the available tools. So this is waste of time. Well... A starving Coyote would do anything and everything to eat the bird, and this desert is so boring anyway.

There are (however) benefits in this endless task, all brilliantly described by <a href="https://ruslanspivak.com/lsbasi-part1/">Ruslan Spivak</a>, but I guess the claim that it would wake us as better software developers makes a valuable starting point...

However, designing a potentially new domain-specific language for a target embedded platform, taming intricacies of compilers and the mechanics of lexers, assemblers and linkers... is not it too overcomplicated a task for a rookie? In other word, why would an inept yet ambitious Coyote, an aspiring candidate for disaster, and a proud neurotic show here the perfect example of the <a href="https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect">Dunning-Kruger effect</a>?

Well... Good question, my fellow reader... This is where I wiggle my eyebrows with overconfidence... Let us explore the couple of potentially wrong statements and misled (if not knowingly biased) opinions that lead me to a potential plan to catch the Road Runner:

1. Industry seems to grin and bear it: The floodgates are wide open with more and more Famishus Famishus stampeding through the desert, knives and forks in hand, but sometimes... <a href="https://www.quora.com/Why-are-there-so-many-bad-software-engineers">ill-prepared.</a>
2. The no premature optimization idea can lead to cost-effective code development. This and the fact that some embedded platforms now boast multi CPU SBCs and gazillion bytes of RAM, this is a giant chinese buffet cheering up Coyotes they can now chase after Road Runners, and start using scripting and high-level <a href="https://opensource.com/life/16/8/python-vs-cc-embedded-systems">programming languages</a> for their embedded projects.
3. As a consequence, is the (millenial) Coyote of 2020 craving for immediate results rather than displaying art and patience?
4. Many Coyotes leapt into the very overcomplicated pitfalls (precipices) left wide open by cross-compilation tools for target platforms (I throw simply dreaded keywords here: host compilers, target compilers, staging, toolchain, broken dependencies and so on...), or worse, the tools sponsored by (ACME) hardware vendors often turns traitorously against them...
5. Will there be a lack of expertise among the Coyotes regarding linkers and assemblers? Or simply put, when our forefathers will kick the bucket, shall we blindfully use these tools without any knowledge of their mechanics?

![Wile E. Coyote disguised as Road Runner...](https://pbs.twimg.com/media/DQyvMmeX4AAlJLw?format=jpg&name=small)

*No premature optimization* could be applied to this kind of project for the sake of education, to reach out the vast assembly of hobbyists and software developers who already use Python, for example to show the different stages at stake such as:
1. Interpretation of allegedly elegant syntax and semantics of popular and modern languages.
2. Transparent demonstration of the translation into assembly and bytecode, leaving the control freak all the room he or she wants to optimize code.
3. An extra Tetris-like tool letting the said control freak put an address for the variable he or she wants to assign, thus showing what happens under the hood.
4. And many extra stuff dealing with determinism, FPGA (???), and kind of what you get is what you meant... Shush... I will not let the cat out of the bag now.

Would this be an interesting project to build a blinking LED app, involving all these steps without the widely known tools for the sake of self-education to complement existing <a href="https://micropython.org/">initiatives</a>? 

This would definitely not reach performance the existing assembler, or catch the Road Runner. But better use cunning than speed, and lure our target: What about another blinking LED project in a portable language that eliminates the use of a host compiler, and that makes assembly great again? If the steps involved expose everything so that future generation of hungry snot nosed Coyotes like me can pretend beating state of the art (just a bit) and try making an explosion of assemblers, and linkers, for the sake of nothing, that day would not be lost totally...

![Only to be courted by his peers...](https://pbs.twimg.com/media/DQyvNknWsAAFiqJ?format=jpg&name=small)