>together with Lisp

Lisp has a lot in common with Forth in that people often reduce it to a trick and miss the lesson it has to teach; people implement their six words from the bare metal and use those six words to implement Forth but never seem to make the leap, realize they can take it one step further and implement the language they need for the task at hand just as easily as they implemented Forth with those six or however many words they decided to start with. Sure it may not be the most efficient solution but in a time when most people walk around with half a dozen cores in their pocket, counting clock cycles is generally not a concern and it can probably be more efficient than the batteries included solution that comes with eight D cells when it only requires a single coin cell. But there is something about the weight of those eight D cells, they are substantial and we can feel it.

I believe Lisp is relatively more understood than Forth these days, in that most of the "big ideas" that have been built in it have also been borrowed and turned into language features elsewhere. We have a lot of languages with garbage collection, dynamic types, emphasis on a single container type, some kind of macro system, closures, self-hosting, etc. These things aren't presented with so much syntactical clarity outside of Lisp, but they also benefit from additional engineering that makes them "easy to hold and use".

Lisp appeals to a hierarchical approach, in essence. It constrains some of the principal stuff that "keeps the machine in mind" by automating it away, so that all that's left is your abstraction and how it's coupled to the rest of the stack. It's great for academic purpose since it can add a lot of features that isolate well. Everyone likes grabbing hierarchy as a way to scale their code to their problems, even though its proliferation is tied to current software crises. Hierarchical scaling provides an immediate benefit(automation everywhere) and a consequent downside(automation everywhere, defined and enforced by the voting preferences of the market).

Forth, on the other hand, is a heavily complected thing that doesn't convert into a bag of discrete "runtime features" - in the elementary bootstrapped Forth, every word collaborates with the others to build the system. The features it does have are implementation details elevated into something the user may exploit, so they aren't engineered to be "first class", polished, easy to debug. It remains concerned about the machine, and its ability to support hierarchy is less smoothly paved since you can modify the runtime at such a deep level. That makes it look flawed or irrelevant(from a Lisp-ish perspective).

But that doesn't mean it can't scale, exactly. It means that the typical enabled abstraction is to build additional machines that handle larger chunks of your problem, but the overall program structure remains flat and "aware" of each machine you're building, where its memory is located, the runtime performance envelope, and so on. It doesn't provide the bulldozers that let you relocate everything in memory, build a deep callstack, call into third-party modules, and so on. You can build those, but you have to decide that that's actually necessary instead of grabbing it in anger because the runtime already does it. This makes it a good language for "purposeful machines", where everything is really tightly specified. It has appealing aspects for real-time code, artistic integrity, verification and long-term operation. Those are things that the market largely doesn't care about, but there is a hint of the complected nature of Forth in every system that aims for those things.

Thanks for mentioning your Youtube serie, have you considered doing it in English?

The Youtube auto-dub stuff is pretty bad and the subtitles are quite good but hard to follow with all the vim motions on top of it!

Your writing is in English and your code comments too... English was not my native language but I'm fluent now. So unless you are targeting specifically the Italian viewers, you would reach many more people in English. Your content is worth being international I feel.

Hi! I'm perfectly capable of doing the same series in English, not that I'm so skilled with other languages, but enough to do it: you can find many programming videos in English on my channel. However: it will never be at the same level of something in my mother tongue, so a few years ago I decided that some of my output would be in Italian. Not the most accessible, but the most quality. I believe that soon or later YouTube videos will have near-perfect dubbing, so this also will make the content available to a larger audience. Cheers.

have you considered learning italian ? it's not that difficult once you know english

My grand mother was Italian, I could understand a fair bit in the family, but this is technical talk in Italian, it doesn't roll off the tongue.

I know that the OP proposal sounded absurd :D But, can you believe that there are many folks that learned Italian following my channel? I'm shocked but this happened multiple times in the latest months. The fact is that Italian is incredibly easy to understand, very easy to talk, and very hard to master. Bot to get from 0 to 101, is a very low effort task compared to other languages.

If you are familiar with lisp are there still big benefits to going through the journey again with forth? Or is it just more recursion and expression except via a stack rather than a list

You learn things with Forth that you don't learn with Lisp. Foremost among these is the relationship between the highlevel language and the underlying computer.

In many Common Lisps you can write functions in assembler if you need to, but in a Forth compiler the assembler is right there. In fact if you have a native assembler it's very easy to bootstrap a baby Forth on top of it and then use that baby Forth to build a complete Forth. No C required.

The feeling you get from doing this is one of complete mastery of the computation process. It's awesome.