>>108048352
Swapping because you can only deal with the topmost element of the stack is an artificial limitation.
In most languages you know exactly how many arguments are passed to your function at compile time and you don't need to swap things around. Just refer to the arguments by name. Forth is one of the only languages where a stack underflow is even possible.

A weird quirk like that makes Forth feel like a toy, theoretical language like how Lambda Calculus isn't meant for real work.

>>108048399
It can and is used for real work though?

>>108048451
I didn't say otherwise.
Maybe consider that the language is flawed in a weird way that doesn't make much sense.

All the SWAP/DUP/ROTing is a huge slog.

>>108048352
It bet it's very nice in a resource constrained environment but s-exp are easier to understand when the code is getting hairy.

It's 2026. We have register machines for a reason. There is no use-case for stack twiddling bullshit like forth.
>b-but muh embedded
It's 2026.

>>108048585
>>108048490
>>108048483
You know you can define your own words with the DUP ROT SWAP etc commands and automate 90% of the language right

File: QBE.png (60.3 KB)

60.3 KB PNG

Register machines are the future

>>108048352
I started making my own Forth but I got filtered on implementing create does. Sad times. :(

Regarding OP's example, having top of stack be a register reduces stack thrashing and increases run-time speed.

I think it's neat. I admire how simple the implementation is. But I am too smoothbrained to be able to use for anything more than a calculator.

>>108048352
dup btfo

File: file.png (98.9 KB)

98.9 KB PNG

>>108048352
you just want this image

>>108048352
It's not that interesting.

>>108048585
The stack is just for easy implementation of the base language. You can still manipulate registers with it, and at the end of the day your program is basically supposed to be written in a DSL you put together and abstracted all the annoying shit behind.

>>108048352
this reminds me of theoretical compsci from Uni. I've never dealt with Forth, though. Is it possible to have 2 or more stacks?

>>108051584
Not just possible, but necessary.

>>108051584
There's supposed to be at least a data stack for function arguments and a return stack for returning from function calls. There can be more though.

>>108048585
>I have a wall clock runninng on jdk and I like it

>>108048352
I like it. Reminds me I never finished my "Maid 4,096th" that apparently necrobumped maid thread back into the catalog. I mean, it's playable, but I haven't polished it for distribution.

>>108051627
not necessarily if you don't care about recursively enumerable languages.

>>108048352
I want to write my own forth implementation on a microcontroller.

>>108052425
There are plenty of implementations already, you can look at many 6502 assembly code implementations if you want to see how to go about it,

Well Forth bros? Rate it.

: fizzbuzz ( n -- )
  1 + 1 cr
  do
    i dup
    3 mod 0= dup          ( n f f )
    if ." fizz" then
    swap dup
    5 mod 0= dup          ( f n f f )
    if ." buzz" then
    rot or                ( n f )
    if drop else . then
    cr
  loop ;

>>108048352
>What are your thoughts on the Forth programming language?
The Unabomber's favorite language.

It's a really cool idea, a genius idea, but not too ergonomic for actual use (i've tried).

Forth is alive everywhere, because many virtual machine bytecodes are actually code for stack machines.

the fith is better

File: POL8.png (48 KB)

48 KB PNG

>>108048352
Forth is based Chuchk Moore is based. You need to adjust your thinking a lot to do forth successfully though.

File: POL9.png (48.9 KB)

48.9 KB PNG

>>108056571

>>108056571
which book?

>>108056803
https://www.forth.org/POL.pdf

>>108048352
Stack is stupid and doesn't scale.

>>108056829
yeah, that one's been on the list for a few years now. i'll get around to it i'm sure.

>>108056571
What's the name of your PDF reader?

>>108048352
vbscript? yeah its pretty good

thought it said "fourth"

>>108056991
It's short, I read it in an afternoon the other day.

>>108048352
Tacit languages are based
Stack based languages are based
Concatenative languages are super based
Simple as

>>108057046
This is xpdf, older version with motif gui

>>108048399
Regarding the stack. Yes you can make a mess of dups and rots where keeping track of what's on the stack becomes impossible. An when you try to directly translate code from other language you know from before, this is what happens almost certainly. Thats why the gforth manual has a section on "Designing the stack effect".
After some practice it feels like the mental overhead from having to keep track of the stack is about the same as keeping track of variable names in code that names intermediate variables.

>>108048352
I don't think about it all because it's not 1979.

the stak manilulation is waste of CPU cycles
Iike the idea of having a simple interpreted shell and call convention to glue assembly routines calls. such interactivity can really elevate assembly-written projects and environments

>>108060430
>stak manilulation is waste of CPU
Meanwhile, modern dev:

import is_even;

>>108048806
They're simpler in design than even imperative programming, and yet they couldn't even outlast functional programming. Go figure.