I am still waiting for some parts that I will use in the next hardware revision of my SDA, so in the meantime, I will write a short introduction on how to not make programming languages. It is just a summary of pain-points that I encountered when developing the "amazing" SVS scripting language used in my PDA.

Step one:

Just start programming!

Don't bother with nonsense like specification, just open a textfile and start writing #include <stdio.h> int main() { printf(.... etc. etc. You can't be disappointed with the end product if you don't have any idea what the end product should be.

This was my approach and it didn't work well. I noticed it firstly when I was adding first new data type. Originally the script supported only unsigned int variables and constants. I wanted to add text strings and things went really badly because of many wrong decisions in the design stage. This was amplified by the fact that I was using C and I had to redesign many of the data structures I was working with. I made it work somehow, but it needed ugly workarounds here and there. For example: If you were working with a function that was returning string instead of:

a = function(); 

You needed to do:

a = "" + function(); 

Otherwise you got a type check error. I ended up rewriting all the expression solving logic in the end. Now SVS supports 32bit int type 32bit float and strings, although the conversions between those types are not perfect, it works way better than before.

Think a bit about the feature set in the early phase of development.

Step two:

You will never encounter invalid input and debugging is for losers

Your main goal when developing a programming language interpreter/compiler is to make it work with valid input data and when invalid data show up, just let it crash or something.

It turned out that when you are developing new application, your script interpreter will encounter more invalid inputs (somewhat broken programs) than the valid ones. Quality of error messages and error detection must be reasonably good. First versions of SVS just printed one of predefined error messages together with a number of the token where the error happened. Finding out what keyword in the source file corresponds with the right token was left on the user. 
Now the debug output prints some parameters of the error and also prints a line in the source file where the error most probably occurred. This makes debugging much easier.

Think about debugging from the start.

Step three:

Big, monolithic blobs of code are the best

Do not cobble things together, it doesn't work in the long time perspective. Splitting them up is just not fun. Try to split your code to logical layers and create understandable APIs.

Step four:

Documentation sucks!

Just do not bother yourself with documenting anything, the code will document itself. Or not? This is actually my biggest pain-point. With no documentation the project is useless to other people. Creating specification and documentation for a project is not fun, but it's actually really good in the long term. I recently finished documenting the main features of the SVS language. Documentation on how to use SVS in some C project will be published later.

And the best thing: SVS is now available on GitHub!

https://github.com/stanislavbrtna/svs-script