The Internet of Things is really taking off. The ESP8266 has made it possible to add a powerful process with wifi to any project for a couple of bucks. Whether you doing a one off art project, or are building a home automation gizmo that you plan on funding with Kickstarter, the ESP8266 can be at the core.

I've gotten really excited about this new chip and it's potential, so naturally I decided to write my own scripting language. When you say that sort of thing in the circles I run around in or when you read it in ESP8266 forums, you generally get a lot of push back.

Once the rolling of the eyes and general incredulity settle down, you are likely to get any combination of these 3 responses:

1. Anyone who writes a new scripting language for any reason on any platform is nuts. There's nothing you could possibly do that hasn't already been done.
2. The ESP8266 already has support for many scripting languages already, based on excellent memory efficient and powerful standards (Javascript, Python, Lua, Basic). Trying to add something new, especially a language not based on an accepted standard, is just nuts.
3. Scripting languages on a platform like ESP8266 incur useless overhead. Native code FTW. You're nuts.

TL;DR I'm nuts.

So what motivation could I possibly have for doing this? I'll push back on each of the points above:

1. There are plenty of reasons for writing a custom language specific to a particular platform. In the case of the ESP8266, it is both much more powerful that other solutions that have come before it (like the AVR chip in Arduino) and much less powerful than traditional computers for which most of these languages were written. So it makes sense to make a language that enhances its advantages while minimizing its constraints.
2. All the languages currently on the ESP8266 were originally written for more powerful platforms. Even though the versions being ported are generally "micro" versions, they still push the limits of the platform. For instance, they typically leave less than 25KB of ram storage, It's hard to do anything in that space. And they generally use garbage collection that adds even more overhead to the management of that tiny memory space.
3. Native programming is fine as long as you want to upload new code every time you make a change. You might think this problem is solved with OTA. But how do you test your changes without crashing the device, which would require you to bring it back to the shop, crack it open and flash new firmware over the serial port. OTA was designed for mass deployment, not experimentation.

One of the great advantages of m8rscript is that I wrote it to be cross-platform. It runs on both ESP8266 and Mac. That has allowed me to write a macOS app which can simulate m8rscript code before deploying on the device.

To be continued...