Writing Forth starts by typing simple stuff on the keyboard and seeing it work. So start with simple examples and just give them a go. When you first start, you might just do some calculations, like 

16 37 * 13 + . 

and the answer is 

605 ok

Well, let's say you need the same calculation except replacing 16 with other numbers. Just define a new word, say zz, as follows:

: zz 37 * 13 + . ;

and use it like

12 zz

You got 

457 ok

and ... well you get the idea much better if you try it. You'll create your own shortcuts as you need them for whatever you are doing. 

Some advice for bigger problems: Design from the top down, and
implement from the bottom up. In other words, break down the problem
into smaller chunks, and continue to break chunks down successively
until you can implement each piece. Create each piece (a word) one at a
time, and test interactively from the keyboard as you go. For example,
the top word for a washing machine might be WASH.
: WASH FILL  AGITATE 5 MINUTES DRAIN  RINSE SPIN ;
Now, to FILL you do need to turn on the tap, and turn it off when it is full, like
: FILL TAP ON BEGIN ?FULL UNTIL TAP OFF ;
TAP is just the address where the solenoid driver is connected, say $9876
and ON needs to put a 1 to turn bit 0 of $9876 high to open the
solenoid, and OFF just puts a 0 in the same place to close the solenoid.
: TAP $9876 ;
: ON  1 SWAP ! ;
: OFF 0 SWAP ! ;
etc.
And you start by typing in those last three definitions and making sure they work first. Then do ?FULL. When it is tested, then put in the FILL word and test it. On so on for all the other words.
There are very few languages or environments that use such an interactive development environment. And there are none with a smaller demand for resources than Forth.

Forth was never useful to more than a very small group of programmers and even that was  25 years ago. Can anyone name an application that was  or is accomplished because of something FORTH could do that other languages can't? The fact is, microprocessors come with lots of ultra-cheap memory these days. You don't need to program this way. 

All I know is that the considerable time I invested in FORTH programming a long time ago was completely wasted. If the goal is to have a fun but arcane hobby, maybe this the answer. Memorizing star wars trivia might get you more friends though.

FORTH Inc was started by key people who created Forth and the company still operates. And they are not the only professional Forth developers. So there was, and still is, sufficient demand to sustain commercial enterprises. (Disclaimer: I have nothing to do with FORTH Inc and never have.) My hobby from 40 years ago did keep me in gainful employment for a year or so at one stage (as a Forth developer).

As an example of achieving the unexpected, I point out that creating a GCODE interpreter to run on an ESP-12 turned out to be impossible using Lua, due to the huge overheads imposed by NodeMCU. I wrote and tested the program on a PC but I could not even get 30% of the code onto the ESP-12. I gave up trying to squeeze it in. I had a GCODE interpreter running on Arduino, but I needed WiFi. I rewrote the code into Forth and chose eForth running on an STM8 (yep, 8-bit CPU with only 8K flash memory). It fits and it works (on ESP-14 - see https://hackaday.io/project/13420-rigtigs-big-3d-printer). 

The lesson: Do not use a sledgehammer to drive in a tack. You do not need to program bigger hardware (multi-CPU chips with lots of IO, ram and flash) when a small chip will do the job. But, you do need the right tools. Sometimes, only a professional IDE with a huge resource base is the right way to go. But, sometimes you can do a LOT with very inexpensive off-the-shelf hardware, plus Forth. Personally, I'll go inexpensive when I can. And. I still have fun doing it (big or small).

I don't want to engage into discussions on the usefulness of programming languages but I consider the many years I spent programming µCs with much more memory in C wasted: the edit/unit-test/program/integration-test cycle was never fun. At least from a hedonistic point of view Forth is much more useful than C ;-)

When I read this: "Using Forth as a scripting language is easy, and it leads to surprisingly simple and powerful solutions." my first thought was 

— It will also lead to a surprisingly low number of users being able to use the psi. 

But maybe I should give forth a go again and see. When I tried it 30 years or thereabouts ago it didn't agree with me at all. I was totally confused by the concepts back then. ;-) 

Matseng, I fully agree. When I tried using Forth on VIC=20 30 years ago, everything worked, but I couldn't figure out how to do anything useful with it. The limits between the console and the application were blurred, and there was no guidance on writing "turnkey applications". 

From the start, the purpose of the TG9541/STM8EF was to create a useful & simple to use Forth, one that's optimized for embedded control, for appliances. However, while working on it, I understood why Forthers appear to have a different perception of programming. 

It's impossible to say when exactly one starts to see the machine as the compiler, code as syntax, and all the other things the "Enlightened" talk about. Actually understanding Forth is really simple, all it takes is writing a Forth.

I don't know yet if the other way works: start scripting style, baby steps, and I'll never know (You're Only a Newbie Once). Please have a look at the Forth intro page, and let me know where cognitive dissonance begins.

https://github.com/TG9541/stm8ef/wiki/STM8S-eForth-Programming

Thanks, I'll check out that document. And I guess that implementing my own Forth would be a rather good way to get to know the language. I for sure got a good understanding about the innards of cp/m while writing a bios for it to run on an emulated z80 in an esp8266.

But if I ever get comfortable coding and thinking in Forth is another thing. I understand OOP concepts quite well, but I've never really got the hang of doing a decent OOP design for my own code. So I guess there's a good chance that the same thing happens with Forth...

"surprisingly low number of users"  :)  You're probably right.

But imagine what the alternative user-friendly scripting language would be that can fit in half of 8K flash.  I guess there's BASIC? Lua?

Of course, you could write your own command interface in C, but then it wouldn't be extensible without re-compiling and re-flashing the firmware.  

The beauty of a scripting-language setup (incl. Forth) is that the serial command language and the programming language are one and the same.  Of course, you have to learn a bit of Forth, but this is a fun toy to do so on/with. 

Re: concepts: put stuff on stack, operate on it.  Define a word that does the same when you end up typing the same thing twice. Iterate until problem solved. 

Probably a tiny basic would be the most straight forward and most accessible for most people.  4 K would support a rather good basic interpreter.   LUA might be an alternative - even if I don't use it myself I guess that LUA is far more widespread and easy for the average Joe to learn compared to Forth.

Of course Forth is more "hardcore" and also more intriguing language - at least for me.  But most people just want to use the stuff, not learn new shit... ;-)