Back in 2018, when the work on LispBM started, I was learning about embedded systems both from a software and a hardware perspective. During this time, I was introduced to the STM32-Discovery board and started writing small programs for it. For a person with a background in more high-level programming the program/compile/flash/debug cycle of interacting with a development board felt very clunky! Moving to embedded/IoT from being more of a "Haskeller" was quite a culture shock, not only the clunky development loop but also all the wires, all the acronyms (I2C, SPI, UART ...) and that the oscilloscope is an absolutely necessary debugging tool. It was quite overwhelming!
As a beginner, one makes a lot of mistakes and an easy task such as getting an LED to blink can easily lead to several repetitions of the compile/flash/debug procedure. Frustration grew!
At about the same time I discovered the MIT Structure and Interpretation of Computer Programs (SICP) video series and found the simplicity and beautiful elegance of the language they described so very appealing. The language explored in SICP is called Scheme and it is a minimalistic Lisp dialect with a focus on functional programming.
When learning something new and very foreign I like to combine it with something I am more familiar with. This is where the original idea for LispBM started to form. I wanted a REPL on the development board and I wanted to implement something like the beautiful system they showed in SICP - to make an efficient implementation of a Lisp or Scheme-like language for microcontrollers.
Of course many of the ideas in SICP are extra beautiful because they are expressed in the Scheme language itself. To run efficiently without using too many resources all of that had to be recreated in C.
Note that while the initial motivation came from the frustration of working with embedded systems and the beauty of Scheme, the actual LispBM implementation does not follow SICP or any one single source very closely. The only Lisp dialect I had any experience with at all was Emacs Lisp, which probably also colored some of my initial design choices.
In detail, motivation and inspiration came from many sources:
Over the years the LispBM runtime system has changed a lot and many insights have been reached. If we were to take a new stab at motivating a Lisp dialect on embedded systems it would go something like this:
There is a long tradition of using a custom Lisp dialect as a built-in scripting or configuration language, think of AutoCAD and Emacs. LispBM continues this tradition.
From 2018 to 2022 LispBM had been a personal hobby project without any particularly clear direction or aim. In January 2022, we started experimenting with integrating LispBM into the VESC BLDC motor control software.
This started an intensive period of making LispBM more feature complete. LispBM already had a lot of diverse functionality, such as concurrency, quasiquotation and so on. Focus had been on those implementation details and algorithms that I found interesting and fun, but really basic things such as negation were missing.
From this point onward LispBM has matured and grown together with the VESC ecosystem of hardware solutions. Apart from substantial extension libraries for the VESC BLDC software and the VESC Express family of firmwares, the following additions and improvements to the LispBM runtime system come from the challenge of making LispBM a more complete scripting language for the VESC platform:
In addition to the above-mentioned major additions, now that we had users, numerous bugs were discovered and fixed! Focus has increased on correctness as can be seen by the size of the test suite and in the static analysis tools used. The aim and goal of LispBM is now to be a sandboxed, efficient, small, correct and bug-free language and runtime system.
A question we often get in relation to LispBM being a part of the VESC software is: Why didn't you pick uPython instead? My answer to this is that I think both I and Benjamin are very happy that we chose to build something from scratch. A more established system would probably have been even harder for us to adapt to the specific requirements of the VESC software. I hope that by building something uniquely suited to the VESC situation, we have also created something of general applicability.
This journey from frustrated embedded developer to LispBM implementor has been supported by many people. Benjamin Vedder's willingness to experiment with integrating LispBM into VESC software was the turning point that gave the project real purpose and direction. I am infinitely grateful.
The VESC community deserves special recognition for being patient early adopters, providing invaluable bug reports, and pushing LispBM to become more robust. Every crash report and feature request has made LispBM better.
Finally, thanks to all the open source contributors, the computer science researchers whose work inspired LispBM's design, and anyone who has taken the time to try LispBM on their own projects.