Forth in its simpler implementations seems like it goes about as far as one could conceivably go in terms of maximizing state, or minimizing non-state. No parameters or perhaps even local variables, everything is just pushed onto a stack (or one of many stacks) that can be freely manipulated at any point. No major opaque control flow mechanisms, ifs and loops are implemented as functions operating on an exposed "return stack" which can be freely manipulated. No opaque function definitions compiled into a binary, function implementations are placed in a data structure that can be freely accessed at any time. No separate compile stage that manipulates state otherwise inaccessible to the program, compilation happens at run-time by manipulating freely accessible data structures, and the "syntax" for compiling things is essentially just function calls that manipulate globally accessible state based on what's in the input stream and you can write your own alternatives if you want.

If the functional paradigm tends towards avoiding state, then it would seem to me that forth does the opposite: making almost everything a part of the state of a program that a developer can access and manipulate, even things that most structured programming languages do not expose to the developer.

The MOV-only CPU [1, 2] is probably about as close to this as you can get. If you think about it, every structured programming affordance is sugar for writing a state machine. MOV-only pushes all control flow into a state machine, and does so without using any branches itself. It's all MOVs all the time.

[1] https://github.com/xoreaxeaxeax/movfuscator

[2] https://harrisonwl.github.io/assets/courses/malware/spring20...

BASIC, as in the original line-numbered version. Every variable is global. Every line is an entry point. The philosophy is: It works just fine, so long as you're careful.

Also: Any assembly language that predates memory protection.

... Recurrent neural networks?

Assembly language, where most opcodes in a given application are concerned with moving data around and every opcode (including the no-op) mutates at least one register, in that the no-op causes the program counter to advance even if it does absolutely nothing else.

Spaghetti architecture. There is so much state organizational controls outside the codebase limit which parts of the code may be executed at any given time.

Befunge is a bit like that, with its 2D grid of state/program/wtf being the entirety of the program.

Maybe OOO counts? Every bit of code gets its own state?

lisp - code is data (meaning state).

i've been thinking about this for a while. my basic question is: languages give or don't give features mostly to avoid spaghetti code; what if what's really needed is tools to make dealing with spaghetti code easy?

State machines?