What makes computer languages odd is in having syntax persistently be "born" in tandem with a desire for a certain semantics, and the two being hard to separate upon close inspection. You have to know the domain and have the experience to see when and where it occurs, but a need for additional syntax always appears beyond a certain point.
The reason why this is the case is because the computer's ultimate use lies in automation of some task: to automate you have to define the problem domain, and to define the problem domain you have to configure something, and as you expand the amount of configuration taking place from a single-use app like your usual batch-processing shell script towards a more bespoken front-end for a certain kind of task, you end up with valid and invalid ways of configuration. If you define an input mechanism that automates a configuration with "good defaults and helpful rules", you haven't concretely changed the underlying semantics - and this sort of thing is in the realm of what a linter does - but you have changed the syntax by which the problem is approached, and pushed the train of thought onto a certain rail.
And most of the time we ultimately aim to shove that concern into a graphical front-end, a form of syntax that is easy to browse through and discover your configuration options with, and enables some unique semantics with data visualization and inputs. But it's a layered process with multiple entry points - sometimes you change a configuration not by clicking around, but by editing a text file, and sometimes you change it by writing a different program. You also rely on having an operating system, files, sockets, etc. The concepts are made within an ecosystem of software and dependencies are assumed. And this is a predictable outcome of Algol.
In Algol-derived languages you have one, general-purpose syntax(and maybe an extra one, like the C preprocessor), and it does a bunch of things that are hard to enforce just with programmer discipline, so it gives you your structured loops and function calls and class methods and such. And you get access to libraries and those all expose the same kind of syntax with new vocabulary.
But then when you have to extend an Algol, you often end up in a place where you have enough configuration taking place to want it to be parsed in some degree. Maybe you decide you will generate code during the build process, or you have a little interpreter that enforces business rules, or something of that sort. You access it by calling a function, but that doesn't describe how you talk to it. You've started using a different protocol, all of the sudden, and your language tools correspondingly change. The boundaries are pretty hard.
And the way in which both Lisps and Forths differ from the Algol approach is in making it really easy to grab the metaprogramming you want, when you need it, so if you need a little compiler for a thing, the barrier to it is a modest "set a toggle so the logic occurs when compiling this other function, instead of at runtime". This is a thing that newer Algol-likes have chipped away at, but in general the priority is "common things are easy, hard things are possible", vs "you have the expressive power to design ideal solutions".
Forth's approach is more low-level than Lisp in that what it gives you to start with is almost nothing except the raw tools to define that syntax in a dictionary, enter the compilation mode, access memory and manipulate some bits. No safety or anything - you build that yourself when and where you want it. It's a useful "bring-up" language for new hardware because it's very permissive in that sense: you have a REPL available from the get-go and it can let you start banging bits. But it lacks the kind of standardization and collaboration that would result in an ecosystem like a C or Java, and that's also by definition: Forth has the expressive power to monopolize the entire path between the final application and the hardware, and if you aim to make it exist in a standardized context like a "web app" or a "Windows app", it suddenly does little of interest - that means you are defining the problem in web terms or Windows terms, and not as a mapping of hardware to solution.
It's a very isolated way of working on software, and a "software company" is nearly allergic to it, since the human factors dictate that the software should be collaborative and often hegemonic.