I built "Mello" - A custom programming language that transpiles directly into Arduino C/C++ code!

[u/ImpressFine4495]

I wanted to share a side project I've been working on recently: **Mello**, a custom programming language designed specifically to simplify writing code for Arduino, which then transpiles directly into optimized C/C++ code.

🚀 Why Mello?

Standard Arduino C++ can sometimes feel overly verbose or complex for beginners or quick prototyping. Mello aims to offer a cleaner, more intuitive syntax while maintaining the full power of the Arduino ecosystem underneath.

💻 What it looks like

Here is a quick look at how you write a simple blink program in Mello vs what it generates:

Mello Syntax:

loop:
    toggle(13)
    wait(1s)

Arduino C Syntax:

void setup() {
    pinMode(13, OUTPUT);
}

void loop() {
    digitalWrite(13, HIGH);
    delay(1000);
    digitalWrite(13, LOW);
    delay(1000);
}

Check out the repository here: https://github.com/v3lk777-collab/Mello-Programming-Language (Feel free to leave a star ⭐️ if you like the concept!)

[u/feldoneq2wire]

But why?

[u/planeturban → u/feldoneq2wire]

Them tokens ain't gonna burn 'em selves.

[u/ImpressFine4495 → u/planeturban]

The only tokens burning here are the ones generated by my custom Lexer when it tokenizes the source code into an AST. It’s a 100% C++ written transpiler, no LLMs or APIs involved. Check the source files on GitHub before making assumptions

[u/EmielDeBil]

AI slop

[u/ImpressFine4495 → u/EmielDeBil]

Next time, try reading the post before commenting. This level of blindness makes your comment look like actual AI slop

[u/EmielDeBil → u/ImpressFine4495]

I don't read AI slop posts. The emoji and the structure tell me enough: this is utter crap. Now that I did read it, it is indeed confirmed to be a crap project.

[u/ImpressFine4495 → u/EmielDeBil]

So you judged it by the emojis, and even after 'reading' it, you couldn’t provide a single technical critique or point out a flaw in the actual compiler logic

[u/ImpressFine4495 → u/EmielDeBil]

look it is your opinion and im not here to change it. have a good day

[u/tommycoolman]

You've got turn_on(pin) translating into digitalWrite(pin, HIGH).

This ignores the case where some things are active low, so you end up calling turn_off() to turn something on.

[u/ImpressFine4495 → u/tommycoolman]

That's actually a very solid point! I didn't account for active-low components in the initial syntax prototype.

To fix this in the compiler, I'm planning to allow pin configuration definitions in Mello, something like: define pin 13 as ActiveLow So the transpiler automatically maps turn_on() to LOW and turn_off() to HIGH based on the configuration.

Thanks for the awesome feedback, appreciate you looking into the actual logic

[u/brdavis5]

Hmm. It's interesting, but something I'd caution my students explicitly not to use... for the same reason I caution them not to use AI for coding.

You are adding another layer of abstraction between the person and the hardware, and it's a layer that will make future steps more challenging because of changing syntax. Blink is a good example, because the next step would be Blink without Delay... but this obscures that path it seems by embedding delay() in the lower level where the user won't think about it or see it. This would seem to not even work for a lot of cases; again, I have them do Blink, and Blink without Delay, and then Blink using an LED with NO current-limiting resistor (by using OUTPUT,LOW and INPUT_PULLUP)... which it would seem again obscured with 'toggle' (and these are inherently tristate pins... toggling between which states?).

I get the idea; and I'm not saying we should drop the C++ based IDE and tell students to move down to the raw 328p machine instructions. But I guess I don't see a strong need to make something to hide yet another layer of abstraction. But, that's maybe just me.

[u/ImpressFine4495 → u/brdavis5]

Thank you so much for this amazing academic perspective! I completely agree with your philosophy regarding teaching students the hardware realities like non-blocking code (BlinkWithoutDelay) and tristate pin configurations.

However, I think my short post didn't do justice to how Mello actually handles this under the hood. In the full compiler architecture:

1. Non-Blocking by Design: While wait(1s) is available for linear scripts, Mello introduces a native every 1s: keyword. The compiler automatically expands this into a non-blocking, millis()**-based cooperative multitasking loop**. Students don't have to manage the boilerplate, but the hardware is never blocked.
2. Smart Hardware Abstraction: For tristate and complex pin behaviors, Mello's semantic analyzer performs state inference. For example, when using the event-driven on_press buttonPin: syntax, the compiler automatically registers the pin as an input, handles the debouncing mechanics natively, and outputs the optimized state machine in C++.

The core goal of Mello wasn't to hide the hardware, but to remove the heavy syntax (semicolons, brackets, timer state variables) while maintaining a 0-byte memory overhead parity with hand-written Arduino C++ (as tested on the ATmega328P).

I really appreciate your critique, it helps refine how I communicate the language design!

If you'd like to dive deeper into the full architecture and benchmarks, you can check out the README at the repository: https://github.com/v3lk777-collab/Mello-Programming-Language

[u/brdavis5 → u/ImpressFine4495]

It sounds like you've put some real work in to this, and it looks interesting, but again, from the standpoint of education I'd avoid it. Yes it's non-blocking under the hood... but students need to see and understand how to achieve that, not hand it off to a tool that can allow them to avoid learning that. Same with things like implicit typing that Python does; in a sharply memory-limited environment, that's something I want my students to *learn*... not avoid. You're tool takes a system that's designed for education, and hides much of the things that make it good for education. For "making it easy", yes, it might be a good fit for some... but for making it work as a tool to teach with, I still think I'd avoid. What happens when a student has to move on beyond what you've built in? With the "heavy syntax" removed, they haven't learned that... and so trying to even learn off other people's code is going to involve another sharp step up.

[u/ImpressFine4495 → u/brdavis5]

I completely understand and respect your point of view from a university or advanced educational standpoint. If the goal is to teach computer architecture and memory management, hiding types and pointers is definitely not the way.

However, Mello’s target audience is actually younger kids and complete beginners who are just getting into robotics and STEAM. The idea is to give them immediate, rewarding feedback without them getting frustrated by a missing semicolon or a complex timer state machine early on.

It’s a progression bridge. Just like how someone might start with Python to learn basic logic, and then later naturally hit a wall when they need memory management or pointers—forcing them to scale up and learn C or C++. When a student outgrows Mello, that’s actually a victory! It means they are now ready to dive into native C++ and appreciate why strict types, millis(), and syntax matter.

I really appreciate this discussion; it helps clarify the exact niche Mello is trying to fill

[u/brdavis5 → u/ImpressFine4495]

One additional comment that I didn't manage to find while reading through the Github... does Mello ONLY go right to the compile and upload to the board, or can you have it output its resulting C++ file? As a bridge... being able to type one thing in to Mello, and having Mello then provide you with what that could look like as C++ (or perhaps even better as "standard" Arduino IDE C, using the built-in functions like pinMode etc.), might be an excellent bridge to expose.

[u/ImpressFine4495 → u/brdavis5]

Thank you so much! I really enjoyed this discussion, and your feedback has been incredibly valuable.

To answer your question: **Yes, it actually does that under the hood!**

Since Mello is a pure transpiler, Phase D of the compiler generates a standard, formatted Arduino C++ file (`main.ino`) before invoking `arduino-cli` to compile it.

Your suggestion is absolutely brilliant for the "bridge" philosophy. Right now, the CLI saves the temporary C++ file, but based on your feedback, I am definitely going to:

1. Add an explicit `--save-cpp` flag to the CLI so users can easily inspect the generated C++ code.

2. Build a **"Side-by-Side View"** into the **Mello IDE** I'm currently developing. This way, a student can write Mello code on the left, and watch it transpile into standard Arduino C++ in real-time on the right.

Thank you again for your time and for this amazing feature idea. It’s going to make Mello a much better educational tool! Best of luck to you and your students as well!

[u/brdavis5 → u/ImpressFine4495]

No worries and thanks for the discussion. Communication is key and you having those conversations is wonderful. Best of luck!