#forth — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #forth, aggregated by home.social.
-
I am happy to announce Mecrisp-Ternary, an experiment to implement the #Forth programming language on a custom balanced #ternary architecture with variable width. Instruction set emulator is included, #FPGA implementation is coming soon: https://codeberg.org/Mecrisp/mecrisp-ternary
-
I am happy to announce Mecrisp-Ternary, an experiment to implement the #Forth programming language on a custom balanced #ternary architecture with variable width. Instruction set emulator is included, #FPGA implementation is coming soon: https://codeberg.org/Mecrisp/mecrisp-ternary
-
I am happy to announce Mecrisp-Ternary, an experiment to implement the #Forth programming language on a custom balanced #ternary architecture with variable width. Instruction set emulator is included, #FPGA implementation is coming soon: https://codeberg.org/Mecrisp/mecrisp-ternary
-
I am happy to announce Mecrisp-Ternary, an experiment to implement the #Forth programming language on a custom balanced #ternary architecture with variable width. Instruction set emulator is included, #FPGA implementation is coming soon: https://codeberg.org/Mecrisp/mecrisp-ternary
-
I am happy to announce Mecrisp-Ternary, an experiment to implement the #Forth programming language on a custom balanced #ternary architecture with variable width. Instruction set emulator is included, #FPGA implementation is coming soon: https://codeberg.org/Mecrisp/mecrisp-ternary
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://www.pixiv.net/novel/show.php?id=28051258
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://www.pixiv.net/novel/show.php?id=28051258
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://www.pixiv.net/novel/show.php?id=28051258
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://www.pixiv.net/novel/show.php?id=28051258
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://note.com/poison_raika/n/n59fa251a00b4
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://note.com/poison_raika/n/n59fa251a00b4
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://note.com/poison_raika/n/n59fa251a00b4
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
深淵の霧と浄化の光 Туман Безодні й Світло Очищення
栄光へ、行け
Іди. До славиhttps://note.com/poison_raika/n/n59fa251a00b4
<>
#ＡＩ生成 #darkened #sky #never #clear #abyssal #mist #swallow #hope #blow #wind #reek #death #innocent #people #through #chaos #forth #wave #heavy #with #spiral #lament #spewed #out #history #strong #soul #abandon #future
-
please find below some interesting resources that relate to how the people's permacomputer project could adapt FORTH for its purposes.
thank you everyone for your thoughtful and constructive suggestions over the last period, as we have been considering FORTH.
it seems the scene is very active, and has lots of ideas.
---
# TI-FORTH Screen Editor
"You will find here a new screen oriented editor for TI-Forth.
For people with other systems, TI-Forth is a fig-forth with some
computer specific extensions. The goal was to write a small
editor with a lot of futures, like autorepeating keys, overtype
and insert, some limited form of cut-and-paste, single-stepping
through source, execution of Forth from editor. Results are
below. Compiled code adds below 2K to system stuff".https://tuhs.superglobalmegacorp.com/Unix_Usenet/comp.sources.unix/1985-November/004781.html
# eulex
"A straightforward standalone Forth implementation for x86".
https://github.com/davazp/eulex/
https://davazp.net/2012/12/08/eulex-forth-implementation.html
# within the durexforth project
https://github.com/jkotlinski/durexforth/discussions/551
## tt
https://gist.github.com/ekipan/e592bf34c314a260112da08adcff980a
## z
https://gist.github.com/ekipan/28bb4bd609797b6d85c58af45d14ed61
# libforth
"libforth: A small Forth interpreter that can be used as a library written in c99".
-
#RISC_OS folks May the 4th be with you! Announcing a new Forth Compiler coming to RISC OS for this autumn (will be unveiled at the London Show this October, together with many other things). The cool bits are in the thread below 👇
#Forth #Fth #Compiler #Bytecode #Programming #SoftwareDevelopment
-
May the Forth be with you!
Today is a great day to honor Charles Moore and his life's work.
Lets make some words about it and stack them. #MayTheFourthBeWithYou #4th #Forth -
May the Forth be with you!
Today is a great day to honor Charles Moore and his life's work.
Lets make some words about it and stack them. #MayTheFourthBeWithYou #4th #Forth -
May the Forth be with you!
Today is a great day to honor Charles Moore and his life's work.
Lets make some words about it and stack them. #MayTheFourthBeWithYou #4th #Forth -
Coming up on
Beltanefestival and still in search of software developer work.I speak the old tongues of #C, #Forth, #REXX, and #Shell, along with other foreign tongues of #Erlang, #NodeJS, #Go, #Java, #C# and more. I make utterances in #English and #French.
I command in several BSD and Linux dialects. Even wrote successful anti-spam filtering software #BarricadeMX and several #milters.
And can brag about winning the @IOCCC (but don't in polite company).
I seek employment for a worthy cause with remuneration.
Please someone reach out, if only to stop me pestering you fine folks every so often with this plea.
-
It has come to my attention that this exists.
https://github.com/tabemann/zeptoforth
I can't update my poll without resetting the results. But, uh, I guess it's an option now?
-
AI-Generated Books, Forth & Pharo, and Why I'm Back with Common Lisp
A notebook-style essay about stumbling upon AI-generated tech books (HiTeX Press, "Robert Johnson"), the realization that beautiful design doesn't equal working code, and the journey through Smalltalk chaos to the quiet stability of Common Lisp.
Includes thoughts on:
- The "end of the internet age"
- Why I avoid publicly traded companies
- AI in music, photography, and content moderation
- Why a REPL beats bouncing windowsFake books → real lessons → building my own tools with CLOS and CLOG.
Read here in German:
https://mahamind7.blogspot.com/2026/03/angriff-der-ai-text-2.html#CommonLisp #Smalltalk #AI #TechBooks #Programming #Forth #Pharo
-
Bandit: A 32bit baremetal computer that runs Color Forth [video]
https://www.youtube.com/watch?v=HK0uAKkt0AE
#HackerNews #Bandit #Computer #Color #Forth #Baremetal #Technology #Video
-
Peter Schmid's Pocket Power Pack is something for the #ModelRail enthusiasts: an all-in-one device that both powers a small layout and controls it too, all from one box. Bluetooth link to your smartphone as a throttle control, too!
#Technology #News #Hackster #OpenHardware #Microcontroller #Forth
-
Peter Schmid's Pocket Power Pack is something for the #ModelRail enthusiasts: an all-in-one device that both powers a small layout and controls it too, all from one box. Bluetooth link to your smartphone as a throttle control, too!
#Technology #News #Hackster #OpenHardware #Microcontroller #Forth
-
Peter Schmid's Pocket Power Pack is something for the #ModelRail enthusiasts: an all-in-one device that both powers a small layout and controls it too, all from one box. Bluetooth link to your smartphone as a throttle control, too!
#Technology #News #Hackster #OpenHardware #Microcontroller #Forth
-
Peter Schmid's Pocket Power Pack is something for the #ModelRail enthusiasts: an all-in-one device that both powers a small layout and controls it too, all from one box. Bluetooth link to your smartphone as a throttle control, too!
#Technology #News #Hackster #OpenHardware #Microcontroller #Forth
-
Peter Schmid's Pocket Power Pack is something for the #ModelRail enthusiasts: an all-in-one device that both powers a small layout and controls it too, all from one box. Bluetooth link to your smartphone as a throttle control, too!
#Technology #News #Hackster #OpenHardware #Microcontroller #Forth
-
@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:
https://github.com/thi-ng/charlie
The REPL itself live at:
https://forth.thi.ng/The attached screen capture shows 4 shader examples (longest one is 12 lines of code)
-
@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:
https://github.com/thi-ng/charlie
The REPL itself live at:
https://forth.thi.ng/The attached screen capture shows 4 shader examples (longest one is 12 lines of code)
-
@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:
https://github.com/thi-ng/charlie
The REPL itself live at:
https://forth.thi.ng/The attached screen capture shows 4 shader examples (longest one is 12 lines of code)
-
@akkartik Since #Forth is just so great for super concise code, allow me to add another example, here to transpile (a subset of) Forth into GLSL for livecoding shaders. This one is using my old 2015 CharlieVM and you can find all the example source snippets in the readme here:
https://github.com/thi-ng/charlie
The REPL itself live at:
https://forth.thi.ng/The attached screen capture shows 4 shader examples (longest one is 12 lines of code)
-
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
-
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
-
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
-
While I was working on this, the article Python Numbers Every Programmer Should Know appeared on the orange website. In #LuaLang, and on a 16-bit target, these overheads are less -- for example, a number weighs 10 bytes instead of 24 bytes -- but overheads don't have much place to hide on a small, slow machine.
(Btw numbers cost 7 bytes each in 8-bit Microsoft BASIC so Lua isn't gratuitously inefficient here, even by the standards of 50 years ago.)
One place that makes overhead really obvious: a 64K segment holds a table of length, at most, 4,096 entries. That's 40,960 bytes, and Lua's strategy is to double allocation size every time it wants to grow the table. 2 x 40,960 exceeds a 64K segment, so 4,096 entries is the growth limit.
On a 640K machine, after deducting the ~250K (!) size of the interpreter (which is also fully loaded into RAM), you'll get maybe five full segments free if you're lucky. So that's like maybe 20,000 datums total, split across five tables.
Meanwhile a tiny-model #Forth / assembly / C program could handle 20,000 datums in a single segment without breaking too much of a sweat!
The efficiency has costs to programmer time, of course. Worrying about data types, limits, overflows, etc. The kinds of things I was hoping to avoid by using Lua on this hardware -- and to its credit, it does a good job insulating me from them. Its cost is that programs must be rewritten for speed in some other language once out of the rapid prototyping phase and having reasonable speed / data capacity becomes important.
I'd estimate the threshold where traditional interpreters like Lua become okay for finished/polished software of any significant scope, is somewhere around 2MB RAM / 16MHz. So think, like, a base model 386. Maybe this is why the bulk of interpreters available in DOS are via DJGPP which requires a 386 or better anyway.
#BASIC was of course used on much smaller hardware, but was famously unsuited to speed or to large programs / data.
I know success stories for #Lisp in kilobytes of memory, but I'm not quite sure how they do it / to what extent the size of the interpreter, and overhead of data representation (tags + cons representation), eats into available memory and limits the scope of the program, as seen with other traditional interpreters.
This is beginning to explain why #Forth has such a niche on small systems. It has damn near zero size overhead on data structures. (The only overhead is for the interpreter core (a few K) and storing string names in the dictionary (which can be eliminated via various tricks)). ~1x size and ~10x speed overhead is the bargain of the century to unlock #repl based development. However, you're still stuck with the agonizing pain of manual memory management and numeric range problems / overflows. Which is probably why the world didn't stop with Forth, but continued on to bigger interpreters.
-
I'm leaning toward #Forth for #AdventOfCode2025. I've been looking at Forth and #Rexx and the whole "build your own kitchen sink" feeling appeals to me. I see some libraries out there, but I can avoid them :)
Being on an Apple Silicon Mac limits my selection of Forths--no Rosetta no how. I had hoped for more pure C engines than I found.
gforth is the big kid on the block, but last time I played with it I couldn't build it myself (a soft requirement). Installs and runs well, but feels "big" and I'm looking for "small."
pforth https://github.com/philburk/pforth is an early favorite. I crash it sometimes but that's my bad code.. Feels solid with correct code.
fforth (this one) https://cowlark.com/fforth/index.html builds and runs like greased lightning.
muforth https://github.com/nimblemachines/muforth would probably simulate the programming for a dedicated device experience. I'd have to see if its ARM support could run under a container on my Mac. Maybe qemu?
If anyone sees this and has suggestions for something I missed please let me know.
-
Coming back here ... too much post-apocalyptic news and politics elsewhere.
I'm gearing up for #AdventOfCode2025 and trying to decide which language to use. It's either
#Pascal, which I know well.
#Forth, which I haven't seriously looked at in a few decades.
#Rexx, same as Forth (on *nix, not a mainframe).I've done AoC in Pascal, C, and Fortran in the past. All work well, but if I don't try a new language, I'll go with my first love in FPC Pascal.
Anyone who might see this, do you have opinions/recommendations/experience with using Forth or Rexx for #AdventOfCode? I've got a month to re-familiarize myself with either Forth or Rexx.
-
Ilo – a Forth system running on UEFI
https://asciinema.org/a/Lbxa2w9R5IbaJqW3INqVrbX8E
#HackerNews #Ilo #Forth #UEFI #Programming #TechNews #OpenSource
-
Ah, yet another brave soul who decided to #journey into the arcane world of #Forth 🧙♂️—a #language that’s as comprehensible as a cat's tax return. 😂 Instead of explaining anything useful, our hero thought building a #bytecode #compiler and a #VM would be a productive use of time. But hey, it's not like anyone was expecting any actual insight from this #nerdy #escapade. 🥴
https://healeycodes.com/compiling-a-forth #HackerNews #ngated -
I'm currently checking out options for doing a little coding on a #MSX1 system (real and emulated, when abroad). There's an adapted #F83 #Forth here (https://github.com/janaite/msx-forth83/tree/master) but while it's working, it's not optimized for 40 colum mode. And on MSX1 you only have 40 columns.
Then there's a #BASIC compiler from the former, dutch "#MSX #Club #Gouda" named #Mozart which compiles your MSX BASIC code and gives you some speed improvement - it's here (https://download.file-hunter.com/Program%20language/Mozart%20-%20Compilador%20BASIC%20para%20MSX%20(1990)(Cibertron%20Software)(br).zip).
And, of course there's #TurboPascal3 for MSX which does support 40 column mode (run TINST.COM to set up screen). It's also here (https://download.file-hunter.com/Program%20language/Turbo%20Pascal%203.01a.DSK.zip)
Aside from that you could use a C compiler like #SDCC or #BDSC under #MSXDOS1 ...
-
Implementing DOES> in Forth, the entire reason I started this mess
https://boston.conman.org/2025/06/09.1
#ycombinator #Forth #ANS_Forth #implementing_Forth #DOES #assembly #6809 -
Ah yes, another episode of "Captain Napalm's Wild Ride" where he ventures into the mystical realm of #Forth to implement DOES>, because why not? 🚀 Spoiler: It's another tale of someone wrestling with a concept that's as clear as Boston's traffic patterns. 🚗💥 But hey, at least we learned he doesn't even like Boston—shocking, I know! 🙄
https://boston.conman.org/2025/06/09.1 #CaptainNapalm #WildRide #Programming #Humor #BostonTraffic #HackerNews #ngated -
Ah yes, another episode of "Captain Napalm's Wild Ride" where he ventures into the mystical realm of #Forth to implement DOES>, because why not? 🚀 Spoiler: It's another tale of someone wrestling with a concept that's as clear as Boston's traffic patterns. 🚗💥 But hey, at least we learned he doesn't even like Boston—shocking, I know! 🙄
https://boston.conman.org/2025/06/09.1 #CaptainNapalm #WildRide #Programming #Humor #BostonTraffic #HackerNews #ngated -
Ah yes, another episode of "Captain Napalm's Wild Ride" where he ventures into the mystical realm of #Forth to implement DOES>, because why not? 🚀 Spoiler: It's another tale of someone wrestling with a concept that's as clear as Boston's traffic patterns. 🚗💥 But hey, at least we learned he doesn't even like Boston—shocking, I know! 🙄
https://boston.conman.org/2025/06/09.1 #CaptainNapalm #WildRide #Programming #Humor #BostonTraffic #HackerNews #ngated -
Ah yes, another episode of "Captain Napalm's Wild Ride" where he ventures into the mystical realm of #Forth to implement DOES>, because why not? 🚀 Spoiler: It's another tale of someone wrestling with a concept that's as clear as Boston's traffic patterns. 🚗💥 But hey, at least we learned he doesn't even like Boston—shocking, I know! 🙄
https://boston.conman.org/2025/06/09.1 #CaptainNapalm #WildRide #Programming #Humor #BostonTraffic #HackerNews #ngated -
Implementing DOES> in Forth, the entire reason I started this mess
https://boston.conman.org/2025/06/09.1
#HackerNews #Implementing #DOES> #in #Forth #ForthProgramming #HackerNews #CodingJourney #TechBlog
