The cost is stupidly high, though. Look at the source code of [1].
The only good page to take from OOP book is the automatic and implicit pseudo-variable "self" or "this", that can reduce stack juggling significantly. I've implemented that in my (yet to be published) dialect and it works like a charm. In my experience, you can have that for cheap and anything more is not worth it from the point of view of a byte-counting Forth programmer.
Yeah, I didn’t mean far out as in good. Some people would say that the important thing to take from OOP is message passing. Which I assume is a no go in Fort? Regardless of dialect.
In communication protocols, you typically send a symbol which tells the receiver the meaning and the syntax of the message, and then the data attached to the message.
In technical terms, messages belong to different application protocol data units ("APDU"). The receiver typically uses the APDU symbol (which can be just e.g. a byte) to dispatch the message internally to the right processing routine.
Message passing in OOP is the same thing, and it's ultimately about late binding. Late binding has, indeed, as much presence as dynamic typing in Forth, contrary to other scripting languages like Lisp or Lua where they are cornerstones, so to speak. Forth is firmly in the early binding camp, to the point that it does even know forward declarations [1]. Forth programmers won't do anything unnecessary, and so they expect their system won't do anything they don't need.
[1] Many scripting languages realized that skipping declarations to be "user-friendly" was a big design mistake and eventually implemented some sort of "strict" mode that became the de facto default. So they have two language features that cancel each other...
I had the same feeling, so I began to read https://www.forth.com/starting-forth/1-forth-stacks-dictiona... with gforth installed with apt. And made few exercises to manipulate the stack with some words and get a grasp on it. Now I saw how it works, I came back to my imperative languages and won't come back to it.
IMO my skills in forth are not really enough to see the distinction between any implementation of forth, so the first one I stumbled upon was ok.
This is made by the company the inventor of the language created. Then he left it because Forth, inc. needed the language to be standardized, which wasn't his idea of Forth and, his point of view is that he solved the software problems and what was left was solving the hardware problems, so he moved to working on stack-based processors.
Swift Forth is literally a professional Forth and is well regarded. The other often recommend Forth is the FOSS GForth. They are good for starting because they are popular and standard, so you'll find help easily.
Other "smaller" Forth are often non-standard dialects and are more-or-less mature experiments.
Gforth is free and well rounded so I'd recommend that if you want to experiment with Forth. It is not very fast though, SwiftForth with optimised subroutine threading will be a lot faster. I haven't tried SwiftForth though as you have to pay for it and it is x86 only.
if you are working with specific hardware (e.g. microcontrollers) it depends on which forth dialects are available but for the raspberry pico and pico 2 I recently found zeptoforth [1]
x86 only on Mac is one of the decisions of all time.
Especially for $400
Object-oriented Forth? Far out.
There’s surprising stuff on every page of this site. On the Contact Us page:
> If you’re looking for the debt relief company […]
The Featured Forth Applications page [1] answered a lot of my questions.
1: https://www.forth.com/resources/forth-apps/
> Object-oriented Forth? Far out.
The cost is stupidly high, though. Look at the source code of [1].
The only good page to take from OOP book is the automatic and implicit pseudo-variable "self" or "this", that can reduce stack juggling significantly. I've implemented that in my (yet to be published) dialect and it works like a charm. In my experience, you can have that for cheap and anything more is not worth it from the point of view of a byte-counting Forth programmer.
[1] https://vfxforth.com/flag/swoop/index.html
Yeah, I didn’t mean far out as in good. Some people would say that the important thing to take from OOP is message passing. Which I assume is a no go in Fort? Regardless of dialect.
In communication protocols, you typically send a symbol which tells the receiver the meaning and the syntax of the message, and then the data attached to the message. In technical terms, messages belong to different application protocol data units ("APDU"). The receiver typically uses the APDU symbol (which can be just e.g. a byte) to dispatch the message internally to the right processing routine.
Message passing in OOP is the same thing, and it's ultimately about late binding. Late binding has, indeed, as much presence as dynamic typing in Forth, contrary to other scripting languages like Lisp or Lua where they are cornerstones, so to speak. Forth is firmly in the early binding camp, to the point that it does even know forward declarations [1]. Forth programmers won't do anything unnecessary, and so they expect their system won't do anything they don't need.
[1] Many scripting languages realized that skipping declarations to be "user-friendly" was a big design mistake and eventually implemented some sort of "strict" mode that became the de facto default. So they have two language features that cancel each other...
So we had quite a deluge of Forth options recently :), not that I am complaining. As someone who doesn't use Forth much, which one is used the most?
This one for example looks like well rounded and user friendly option.
Would anyone care to comment about this?
I had the same feeling, so I began to read https://www.forth.com/starting-forth/1-forth-stacks-dictiona... with gforth installed with apt. And made few exercises to manipulate the stack with some words and get a grasp on it. Now I saw how it works, I came back to my imperative languages and won't come back to it. IMO my skills in forth are not really enough to see the distinction between any implementation of forth, so the first one I stumbled upon was ok.
This is made by the company the inventor of the language created. Then he left it because Forth, inc. needed the language to be standardized, which wasn't his idea of Forth and, his point of view is that he solved the software problems and what was left was solving the hardware problems, so he moved to working on stack-based processors.
Swift Forth is literally a professional Forth and is well regarded. The other often recommend Forth is the FOSS GForth. They are good for starting because they are popular and standard, so you'll find help easily.
Other "smaller" Forth are often non-standard dialects and are more-or-less mature experiments.
Gforth is free and well rounded so I'd recommend that if you want to experiment with Forth. It is not very fast though, SwiftForth with optimised subroutine threading will be a lot faster. I haven't tried SwiftForth though as you have to pay for it and it is x86 only.
I suspect there isn't a single "most popular" FORTH, instead there are a million niche-specific implementations.
After all half the fun of using the language is writing your own interpreter, and it's very easy to do on constrained hardware/systems.
gForth [0] is great for getting started
if you are working with specific hardware (e.g. microcontrollers) it depends on which forth dialects are available but for the raspberry pico and pico 2 I recently found zeptoforth [1]
or you know you can always bootstrap your own :)
[0] https://gforth.org [1] https://github.com/tabemann/zeptoforth
Me thinking this was a Forth IDE implementated in Swift UI.
And here I thought this was some sort of cross-platform Swift-Forth hybrid