JavaScript.CodeCompared.To/Forth

A JavaScript semicolon ends a statement; a Forth semicolon ends a definition, and it is a word like any other. There are no statements in Forth at all — only words, run one after another.

console.log takes any number of arguments of any type and decides how to show each. Forth has a different printing word for each kind of thing — . for a signed number, U. for an unsigned one, EMIT for a character, TYPE for a string — because nothing on the stack carries a type that could tell a single word what to do.

A stack-effect comment is Forth's JSDoc, and like JSDoc nothing enforces it. It is written for every word, because with no parameter names in the code it is the only place a reader can learn what a word takes and gives back.

Every Forth program works on this one shared stack, and every word takes its inputs from it and leaves its outputs on it. That is the whole calling convention: there are no argument lists because the arguments are already there, in order, when a word starts.

Destructuring assignment is JavaScript's way of shuffling values around without a temporary variable; in Forth that is the only way anything is ever done. The Forth prints each stack from the top down, which is why SWAP . . shows 4 9.

DEPTH prints 3 rather than 4 because it counts the stack before pushing its own answer. .S is what a Forth programmer types between lines at an interactive prompt the way a JavaScript developer inspects a variable in the console; some Forths prefix its output with the depth, as in <3> 10 20 30.

Returning two numbers needs no array: the word simply leaves both. 2/ is an arithmetic shift, so it is exact for the even sums here; JavaScript's / 2 would have produced a fraction for an odd one, where 2/ rounds down.

JavaScript hoists function declarations to the top of their scope, so the call above the definition works. Forth has no hoisting, and moving the last line of the Forth example to the top would stop with "undefined word: DESCRIBE". Forth programs are therefore written bottom-up: the smallest words first, the program's entry word last.

One-line arrow functions are about as close as JavaScript gets to typical Forth, where most words fit on a line and a word longer than a few lines is considered a design problem.

The late visibility of the name is what allows a new word to be built on an old word of the same name, something JavaScript's single binding per scope cannot express. Both versions make the same 21,891 calls; the Forth one is fast enough that the difference is invisible here.

Reassigning a JavaScript variable changes what every closure that reads it sees, so the second report prints [7]. Forth resolved FORMAT once, when REPORT was compiled — so the Forth output line is unchanged, and the new FORMAT is used only by code written after it. A deferred word, shown further down, is how Forth opts into JavaScript's behavior.

Every JavaScript number is a 64-bit binary floating-point value, which is why 0.1 + 0.2 is not exactly 0.3. Forth sidesteps that by not having fractions, and 7 2 / gives 3 where JavaScript's 7 / 2 gives 3.5 — the same as Math.trunc(7 / 2). Most Forths offer a separate floating-point word set with its own stack, but it is optional and this one does not have it.

JavaScript's bitwise operators convert their operands to 32-bit integers, so | 0 and >>> 0 are windows onto exactly the arithmetic Forth does all the time. The plain largest + 1 line is what Forth cannot do: a floating-point number simply keeps growing. On a 64-bit Forth the wrap happens at a much larger number.

The three lines print the same numbers in both languages because both are doing 32-bit integer shifts. A 64-bit Forth agrees on the first and last lines and not the middle one: shifting a negative number right with zeros coming in depends on how many bits there were to begin with. The difference is only in naming: Forth writes shift counts after the value, like every other operand.

JavaScript's % is the symmetric kind, and getting the floored one takes the ((n % d) + d) % d idiom that every JavaScript developer who has wrapped an index around an array has written. Plain / and MOD in Forth may be either kind, depending on the system, so portable code that divides negative numbers names the one it wants.

toString(8) and parseInt(…, 8) each take the radix as an argument and leave nothing changed. Forth's radix is one global setting that affects the rest of the program, including every number literal after it — so every line puts DECIMAL back before moving on.

JavaScript has six falsy values beyond false itself — 0, "", null, undefined, NaN and 0n. Forth has one, because it has only numbers: there is no empty string, no null and no NaN to be falsy. That removes a whole category of surprise, and replaces it with the need to remember what a number on the stack was supposed to mean.

Number(true) is 1 in JavaScript; the equivalent Forth flag is −1, the same as ~0. The choice means AND, OR and INVERT work as logical operators on flags and as bitwise operators on everything else, with one set of words for both.

JavaScript's && skips the second operand when the first is falsy, which is why it never prints checking second. Forth runs both checks and prints both lines. When skipping matters in Forth, the second test goes inside the first test's IF.

A nested ternary is a common JavaScript way to express a three-way choice in one expression. Forth has no expressions to nest, so the same shape becomes a sequence of early exits, each leaving its answer behind.

Many Forths add CASE … OF … ENDOF … ENDCASE for matching exact values, and it has no fall-through to forget a break for — but it is an optional part of the standard. Naming the condition, as WEEKEND? does, is the more common Forth habit.

The JavaScript loop builds a string and prints it once; the Forth loop prints each number as it goes, so it needs no string at all. The loop body and its counter live between DO and LOOP, and the counter is not a variable anyone can reassign.

Testing at the end is what makes 0 count as one digit, in both versions. The inverted sense is the easy thing to get wrong: UNTIL means "stop when true", so the test is DUP 0=, not DUP 0<>.

A value that is not printed has to be dropped, so the loop body DROPs every reading that is not high. Forgetting that DROP leaves a growing pile of numbers on the stack — a bug with no JavaScript counterpart, since an unused expression value simply vanishes.

Every read and write of a Forth variable is explicit: visits = visits + 1 becomes fetch, add, store. That is also why a variable is rare in idiomatic Forth — a value that is only needed for a moment stays on the stack, and a variable is kept for state that has to outlive the word that set it.

A VALUE reads like a let and a CONSTANT like a const, which makes them the usual choice for settings. The difference from a VARIABLE is only what the name pushes: the number itself, rather than where it lives.

This is the minimum of the pattern, kept small so the shape is visible; the next sections store real data in that memory, which is where a defining word earns its keep. The JavaScript closure keeps greeting alive for as long as hello exists; a Forth program keeps data alive by writing it into memory, and nothing is ever collected.

An Int32Array is the closest thing JavaScript has to Forth memory: fixed-size integers laid end to end in a block of bytes. What Forth leaves out is everything the typed array adds — its length, and the bounds check that ignores a write past the end. Writing to index 7 here would overwrite whatever comes next in memory.

Both columns print 2 1 0 0: the least significant byte first, which is little-endian order. A JavaScript Uint8Array over an Int32Array's buffer and a Forth C@ on a cell's address are the same trick, and both inherit the byte order of the machine underneath. DataView exists in JavaScript precisely to choose the order explicitly; Forth leaves that to the program.

fill and set on a typed array are the same two operations, and String.fromCharCode turns the bytes back into text the way TYPE does. Code 46 is the period and 88 is X.

A JavaScript object looks its properties up by name at run time and can gain new ones whenever it likes. A Forth record has its fields decided in advance as fixed offsets, which is exactly how a C struct works and why reading a field costs one addition.

A JavaScript length counts UTF-16 code units, so "héllo" is 5. Forth counts bytes, and "é" is two bytes in UTF-8, so the Forth answer is 6 — the same number TextEncoder reports. Any Forth word that walks a string byte by byte will see "é" as two characters.

charCodeAt and C@ answer the same question for plain ASCII text. The address-and-count pair is how every Forth word receives text, so this loop shape appears in nearly every Forth string routine.

padStart(3, "0") describes the result; pictured numeric output describes the steps, digit by digit from the right. TYPE prints no trailing space, unlike ., which is why SPACE is needed after the padded number and not after the total.

parseInt("512px") quietly ignores the "px"; >NUMBER tells you exactly how much it ignored — 2 characters — and leaves the decision to the caller. For "px" there are no digits at all: JavaScript returns NaN, while Forth leaves 0 with two characters unconverted, and only that count reveals the failure.

Having two words for the two behaviors is typical of Forth: rather than one literal syntax with rules, there is a small word for each job. S\" was added in the 2012 standard; older Forths have only S".

An execution token is a callback with no type and no closure: just a number that can be passed, stored and executed. The name avoids REPEAT, which is already the Forth word that closes a BEGIN … WHILE loop.

🚨 The obvious alternative — parking the token on the return stack with >R and reading it inside the loop with R@ — crashes, because DO keeps its own counters on that same return stack, so R@ reads a loop counter and EXECUTE jumps to it. Looping over addresses instead of indices is a classic Forth idiom, and it is how forEach would be written if JavaScript arrays were bare memory. The word is only a few lines, because the language has nothing to hide: an array is an address, an element is @, a callback is EXECUTE.

An array of arrow functions and an array of execution tokens are the same data structure. 🚨 The order matters. Compiled code goes into the same memory that , writes to, so a :NONAME placed between CREATE HANDLERS and its , would put the word's code where the array's first element belongs, and HANDLE would execute garbage.

This is the behavior a JavaScript let gives every function reference for free, and that an ordinary Forth redefinition does not. Forth makes it an explicit choice for the few places it is wanted, which is also why a deferred word costs one extra lookup and a plain word does not.

The "constructor" is the part before DOES> and the one "method" is the part after, shared by every word it creates, much as area is shared through the prototype. What a Forth object cannot have is a second method — each created word does exactly one thing — so larger designs pass the object's address to ordinary words instead.

The second call should print nothing, and in the Forth it leaves the two numbers behind unused, since the guard exits before - consumes them. JavaScript can only add syntax like this with a build step such as a Babel plugin. In Forth the compiler is a set of words the program can add to, and IF and EXIT are themselves defined exactly this way.

new Function compiles its text into an isolated function. EVALUATE has no isolation at all: the text shares the program's stack and dictionary, so it can define new words or leave results that the rest of the program then uses.

JavaScript compiles neverCalled without checking what launchRocket refers to, and would throw a ReferenceError only if the function ran. Forth's single pass and eager lookup catch the misspelling at once, which is the other side of having to define every word before using it. The failure here is the expected one.

The effect is a throw caught only by the outermost try, as in the JavaScript example — which is why setVolume(3) and 3 SET-VOLUME both never run. The failure shown is the expected one.

JavaScript chooses a sentinel — -1 or null — that cannot be a real answer. Forth puts a separate flag on top instead, so any number can be a real answer, and the caller must test the flag before trusting what is underneath.

An error in Forth is a number rather than an object, chosen by the program — positive numbers are free for any use, and −1 through −4095 are reserved. CATCH and THROW belong to the optional exception word set, which is why this page's Forth can only show this example.

Most of the JavaScript is the turtle: a canvas, a position, and the trigonometry that turns "forward" into coordinates. Forth's approach to every problem is to build words like FORWARD first and then write the program in them, and here the turtle vocabulary is that first layer, handed to you. Both drawings share one starting corner, so the three shapes fan out from the same point.

The same numbers in both columns give the same picture — only the size differs, because the Forth drawing is scaled to fit its pane while the JavaScript canvas is drawn at a fixed size. Changing 91 to 89 twists the spiral the other way, and 120 turns it into a triangle.

Three curves joined by 120-degree turns make the snowflake. The Forth side divides a length of 243 by 3 three times and gets exactly 9, while JavaScript's 220 becomes a fraction without complaint — integer-only arithmetic is why the Forth example chose a power of three.

JavaScript's tokenizer knows that ( and " are punctuation, so spacing never changes meaning. Forth's tokenizer knows only spaces — which is also what lets 2DUP, ?DUP and .S be names. The failure here is the expected one: TIGHT is never defined, and LOOSE never runs.

The second line switches back before the 10 and gets ten. A JavaScript literal carries its own base, so no line can affect how the next one is read; in Forth the base is state, which is why careful code puts DECIMAL back as soon as it can.

A JavaScript return value that nobody uses is discarded. A Forth result nobody uses stays on the stack, under whatever the next word expects to find — so in Forth, ignoring a result means writing DROP.