11–20 of 111 posts
This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments! Part 1: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... Part 2: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... (github mirror: https://github.com/AlexandreAbreu/jonesforth/blob/master/jon... ht…
This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments! Part 1: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... Part 2: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth... (github mirror: https://github.com/AlexandreAbreu/jonesforth/blob/master/jon... ht…
Earlier quoted context omitted.
The more likely culprit is this: > But Forth is also like a high-wire act; if C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code. You can do horrible things like redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?) You can easily jump off into bad sectio…
> Forth code ends up deeply personal, and specific to the current task. That's the point though. You create a domain specific language using Forth and solve your domain specific problems with it.
Earlier quoted context omitted.
The more likely culprit is this: > But Forth is also like a high-wire act; if C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code. You can do horrible things like redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?) You can easily jump off into bad sectio…
> Forth code ends up deeply personal, and specific to the current task. That's the point though. You create a domain specific language using Forth and solve your domain specific problems with it.
DSLs come at a cost.
Also, my time with Lisp has taught me that interactive environments are A Good Thing, and Forth is exceedingly interactive, and has better native introspection than many Lisps (when your guts are strewn across the floor, it's hard to hide them).
But for all that is good about it, Forth does have its problems: depending on how well your problem maps to the stack, Forth can be exceedingly painful.
A discussion of Forth's flaws, of course, would not be complete without a link to Yossi Kreinin's now-famous post on the subject: http://yosefk.com/blog/my-history-with-forth-stack-machines....
Earlier quoted context omitted.
> Forth code ends up deeply personal, and specific to the current task. That's the point though. You create a domain specific language using Forth and solve your domain specific problems with it.
Yes, but create "other programmers don't understand my DSL" problem. DSLs come at a cost.
I quite like Forth. It feels like a blend of lisp and apl. And even ml if you squint a bit at it as an applicative as composition system. People on reddit seems to hint at the fact that Forth people stay under the radar because it allow them to design and solve problems in better ways. I wonder how true it is ..
The more likely culprit is this: > But Forth is also like a high-wire act; if C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code. You can do horrible things like redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?) You can easily jump off into bad sectio…
I'm a embedded software dev and write code all day in C. Sure enough forth comes up in conversations once in a while as does other ideas like Python, JS, Lua etc.. Of all the alternatives to C, Forth is the only one which groks hardware. This is particularly important for embedded development. Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this…
Forth is a great little language, and a perfect example of how to to do a surprising amount with very little. For more complicated embedded work, however, I've been deeply impressed with Philipp Oppermann's tutorial on writing a kernel in Rust: http://os.phil-opp.com/ You have to limit yourself to Rust's "core" library (instead of the usual "std"), and you won't have a heap until you write one, but it's surprisingly nice. Well, except for debugging double faults. That's never nice. :-/
Here's my toy PIC 8592 interface in pure Rust: https://github.com/emk/toyos-rs/tree/master/crates/pic8259_s... Be careful, it's a subtle chip and I only deal with the basics.
I'm a embedded software dev and write code all day in C. Sure enough forth comes up in conversations once in a while as does other ideas like Python, JS, Lua etc.. Of all the alternatives to C, Forth is the only one which groks hardware. This is particularly important for embedded development. Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this…
> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. Forth is a great little language, and a perfect example of how to to do a surprising amount with very little. For more complicated embedded work, however, I've been deeply impressed with Philipp Op…
But if you're working in a raw microconroller, you're going to be touching metal constantly, and you won't want anything you don't use slowing you down.
In short, Rust is great, but it doesn't beat Forth in Forth's biggest problem space: programming embedded systems under exceptionally tight size/speed constraints.