permacomputing

Source repository for the main permacomputing wiki site
git clone http://git.permacomputing.net/repos/permacomputing.git # read-only access
Log | Files | Refs

commit 3a964146e6ea319c8f376ccc3ceca5660f4ff1a2
parent 1b44284a330f7496e3ff54ee2b9ed37cc7549acc
Author: Ville-Matias Heikkila <viznut@low.fi>
Date:   Sun, 24 Jul 2022 13:39:48 +0300

fix facts about forth compilation

Diffstat:
MForth.mdwn | 2+-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Forth.mdwn b/Forth.mdwn @@ -2,7 +2,7 @@ The main benefit of Forth is that it is very small. A classical Forth system takes the roles of the compiler, the editor and the operating system while completely fitting in a memory space of less than 20 kilobytes. The smallness also makes it possible to implement a Forth system from scratch in a weekend. -Forth is usually run with a two-stack [[virtual machine]], so it is much slower than compiled code. However, classical Forth systems typically also include an [[assembler]] that can be used to implement speed-critical parts of the program. +Forth is often run with a two-stack [[virtual machine]], which makes it much slower than compiled code, although native-compiling Forth systems are also common. Classical Forth systems typically also include an [[assembler]] that can be used to implement speed-critical parts of the program. Most programmers see Forth as quite esoteric in comparison to other languages. Forth also doesn't "protect" the programmer from its inner peculiarities – even though it is possible to create abstractions, it is not advisable to forget what lies under those abstractions.