[HN Gopher] Forth - Is it still relevant?
___________________________________________________________________
Forth - Is it still relevant?
Author : lioeters
Score : 98 points
Date : 2025-11-09 04:59 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Animats wrote:
| > With all the advantages, it is unfortunate that Forth lost out
| to C language over the years and have been reduced to a niche.
| Per ChatGPT: due to C's broader appeal, standardization, and
| support ecosystem likely contributed to its greater adoption and
| use in mainstream computing.
|
| Oh, please. I've written in Forth. It's useful when you have to
| do a cram job to fit in a really tiny machine. Otherwise, no.
| spragl wrote:
| Indeed. Why did grass shears loose out to lawnmowers? The
| question is misguided, they are two different categories.
|
| The interesting question is why Forth lost out to BASIC on the
| home computers. There were a few that were Forth based, and
| there were RPL on calculators, so that whole programming
| paradigm could conceivably have caught on. I wonder how that
| would have affected other kinds of programming...
| jng wrote:
| yosefk had the ultimate take on this: https://yosefk.com/blog/my-
| history-with-forth-stack-machines...
| astrobe_ wrote:
| Not really. The article was written 10+ years ago, saying that
| one cannot use Forth in commercial products, yet Forth Inc. and
| MPE are still in business.
| xyzal wrote:
| I don't know about now but it soon may be :)
|
| An interesting project chose it as its lang:
| https://collapseos.org/
| Someone wrote:
| The article doesn't mention performance. Because Forth programs
| basically chain subroutine calls together, it's a safe bet it is
| bad on modern hardware with its multitude of caches.
|
| That's something you could prevent with an advanced compiler that
| inlines lots of code and carefully tries to put functions often
| called together in cache lines, but this code doesn't do that,
| and if you did, why spend that effort on your compiler if a
| simple traditional language makes that inlining easier?
| astrobe_ wrote:
| Yes, I observe a 30-40x slowdown with that method on my
| interpreter. I was perfectly aware of the cost, Anton Ertl had
| shown in the 90ies that it wasn't the best on Pentium already
| [1].
|
| The trick is that you can regain 100% the speed of C (or
| machine code) by native-coding the critical parts. It's pretty
| much the same cheating method as JIT or calling native code
| with an FFI, just manual.
|
| In this regard, a simple, naive subroutine threaded scheme
| makes it very trivial to do. Think Lua extensions but even more
| easy because you don't have dynamic types or GC memory.
| Seriously, when I look hear that language X is "easy to extend"
| and I look at it... No, it is not.
|
| I have come to the same conclusions as eForth "independently"
| (I have looked at many Forth systems before making my own, so
| there could be some influences), except I wasn't interested in
| compatibility with the standard, so I ditched the counted
| strings for C's ASCIIZ strings. This makes interfacing with
| C/C++ libraries as straightforward as you can get.
|
| I quite don't understand why eForth goes for C++; I do see its
| value to parse more complex languages but Forth? I also don't
| see the value of multithreading. Cooperative schemes usually
| work well enough and are easier to handle. If concurrency is
| needed, multiple programs with RPC, shared memory or pipelines
| are options usually available (some options are more portable
| than others, though).
|
| > So, the question is, how to encourage today's world of C
| programmers to take a look at Forth.
|
| This is a huge mistake. If you make a Forth for others instead
| of doing it for your own needs, you are doing it wrong. Doing
| it for yourself, and not being tied by backwards compatibility
| because you have published your Forth and you don't want to
| lose your audience, leads to vastly different answers.
|
| [1] http://www.complang.tuwien.ac.at/projects/forth.html
| _0ffh wrote:
| No. Chaining subroutine calls is an implementation detail that
| is not inherent in the language, even if it may be a popular
| option because it is easy to do.
|
| The usual implementation options are subroutine threading,
| indirect threading, and direct threading.
| nickcw wrote:
| I wrote a FORTH for ARM which inlined short definitions (eg
| stack manipulation) then did peephole optimization keeping the
| stack in registers for that word.
|
| The compiled code came out looking quite nice. I'm sure a
| decent C compiler would have done better, but it wasn't bad at
| all.
|
| It meant all the stack noise was compiled as register move
| instructions leaving only calls to chunky words which were too
| big to inline.
| anthk wrote:
| Threaded Forth's date back to the 80's; they almost invented
| 'modern' task switching.
|
| Also: https://www.bradrodriguez.com/papers/mtasking.html
| adastra22 wrote:
| Task switching goes back to the 60's though?
| djmips wrote:
| The Apollo Guidance Computer is a fun example.
| thesz wrote:
| If you doing your own Forth CPU, make a barrel one [1] to hide
| any overhead. State of such individual CPU is small, you can
| easily have thousands of them.
|
| [1] https://en.wikipedia.org/wiki/Barrel_processor
|
| If you do your implementation on regular CPU, do a software
| pipelined [2] interpreter, which also can do several threads of
| execution simultaneously.
|
| [2] https://en.wikipedia.org/wiki/Software_pipelining
|
| Software pipelined stack machine interpreter was used to
| compress code for VLIW DSP.
| scatbot wrote:
| Any Forth system at it's core is essentially a stack-based
| virtual machine with a reprogrammable high-level assembler and
| a REPL. Some Forths use direct or indirect threading, others
| are implemented as bytecode VMs, not unlike the JVM, high-
| performance JavaScript engines or the Erlang VM, but that's
| really just an implementation detail.
|
| People say that stack juggling is boring, but I actually find
| it to be a very natural way to think about computation. Forth's
| linear, concatenative style gives you SSA-like semantics for
| free, which makes it straightforward to lower into register-
| optimized bytecode or native code.
|
| And once you're there, dynamic recompilation at runtime can do
| the rest. A naive, threaded implementation of Forth might not
| be performance-friendly on modern hardware, but there's nothing
| that prevents it from being high-performance. It just depends
| on how much effort you're willing to put into the
| implementation.
| tombert wrote:
| I still feel like I need to learn Forth.
|
| It has always fascinates me how Forth has been historically used
| for low level embedded programming, but also can be as high level
| as you'd like. I feel like this isn't a concept that has really
| gone away.
| octetta wrote:
| Forth is so easy to learn... go for it!
| fjfaase wrote:
| I am using a stack based language as an intermediate language for
| a C compiler I am writing. The language can be mapped to assembly
| and I wrote a memory safe interpreter for it. Both are not geared
| to performance as that is not a primary concern for the compiler
| and tool chain.
| iberator wrote:
| I just wrote assembler for my custom virtual cpu. Now i plan to
| write Forth interpreter or compiler...
|
| IMO Forth is easiest language to implement from scratch,
| especially on stack based CPUs :)
| wewewedxfgdf wrote:
| Curious, I just got an LLM to write a small web server in Forth.
|
| Phew - that is a terse language. I have heard it compared to
| assembly language and yeah I see that.
| drlobster wrote:
| I'm very curious to know how it got on with that. I've had
| Claude Code write me a Forth for a custom CPU and then write
| applications on top of that. It get's there but unsurprisingly
| it's nowhere near as fluent in it as Python.
| procaryote wrote:
| Assembly language is often more readable, weirdly
| wartywhoa23 wrote:
| May I suggest this wonderful playground to everyone interested in
| both Forth and pixel shaders: https://forthsalon.appspot.com
| djmips wrote:
| Some very clever demonstrations to be found.
| ajb wrote:
| When looking at these kind of subcultures, I think the best
| policy is "learn from them, but remember that they don't learn
| from you". They may have a unique better take on some aspects,
| but they will try to convince you to scorn all other viewpoints,
| and that's always worse than the gain.
| ofalkaed wrote:
| >but they will try to convince you to scorn all other
| viewpoints
|
| How is that not what you are doing? Lay it all out and back up
| what you are claiming, some of us are willing to hear you out.
| ajb wrote:
| Ok, if my comment came across as saying to scorn forth, then
| it was badly written.
|
| Chuck Moore is a genius. How many other people created a
| language, wrote their own semiconductor simulator and ECAD
| system, and used it to design their own CPU? But, Forth has a
| strong culture of NIH, and it started with him. Maybe you
| need a degree of arrogance and self-belief to do the things
| he's done. Sadly, most people are not such geniuses as to be
| able to get away with it.
|
| What I tried, perhaps badly,to say; is that it's worth
| learning everything from Forth culture except for contempt
| for everything that's _not_ Forth. There are a lot of things
| wrong with common-denominator programming languages, and
| common-denominator practices; and it can be exciting for a
| young programmer to join a community which openly expresses
| the problems and has an alternative view. (This was
| especially the case 15-20 years ago when C++ hegemony was at
| its height). But it can easily become parochial.
|
| The lesson of Forth for me, is that you can really gain a lot
| of productivity by ruthlessly removing generalisations and
| focusing on the exact problem you want to solve; and not
| being afraid to re-implement stuff in order to do so - if you
| can do it in a simpler way. I don't think adopting
| concatenative syntax is necessary to do this; there are too
| many examples where it was achieved without.
|
| Chuck Moore has argued that all programming should adopt this
| radical simplification approach; this seems to be the case
| put by the OP (although not explicitly). I don't think it
| works. Too many tasks require a degree of collaboration which
| is enabled by the abstractions. Rewriting everything simpler
| works for a lone programmer, but it means you have to
| _understand_ everything, and sometimes you just have to
| interoperate with some system whose complexity can 't be
| refactored away. Take Unicode- Chuck Moore's answer would be
| "throw away unicode" but most of us don't have that choice.
| ofalkaed wrote:
| >contempt for everything that's not Forth.
|
| I have never seen that, most in the Forth world seem
| resigned to obscurity and content living in their own
| world. If you could point me to the people advocating Forth
| above all else, I would love to see it and I don't mean
| that in a "you're wrong, I'm right" way, I just want to see
| what their methods are.
| vacuity wrote:
| More generally, even if someone says something questionable,
| there may be something to learn from what they said. Always
| seek to learn and grow, because all that you can learn from is
| before you.
| nickcw wrote:
| I've always had a soft spot for FORTH. I think the magic of it is
| how little assembly you need to write before you are writing your
| FORTH system in FORTH.
|
| So in my opinion this is somewhat antithetical to the idea of
| FORTH
|
| > 100% C/C++ with multi-platform support. Though classic
| implementation of primitives in assembly language and scripted
| high-level words gave the power to Forth, it also became the
| hurtle for newbies. Because they have to learn the assembly and
| Forth syntax before peeking into the internal beauty of Forth.
|
| Fair enough to write a core of FORTH in C as a kind of portable
| assembler but most of the system should be written in FORTH in my
| opinion, then you can change it from FORTH. As fast as I can see
| eForth is written entirely in C.
|
| Anyway FORTH is fun, writing your own is fun too and a great
| educational experience, but despite being a fan, I wouldn't write
| anything serious in it today. It is much too low level and it has
| even less memory safety than C!
|
| The elegance of it continues to impress though with functional
| programming to get the job done and compile time programming to
| mold the language into that DSL which expresses the problem
| perfectly.
| antirez wrote:
| In my YouTube C language course in the latest episodes I'm
| implementing a Toy FORTH interpreter: I believe FORTH is nice
| even just for the educational value it contains, and also,
| together with Lisp, it shows _another way_ to perform
| computations. In the mind of the novel programmer, being exposed
| to these different ways to express computation has deep effects
| even if most of the code will be written, in their career, in
| imperative or OOP languages.
| djtango wrote:
| If you are familiar with lisp are there still big benefits to
| going through the journey again with forth? Or is it just more
| recursion and expression except via a stack rather than a list
| keyle wrote:
| Thanks for mentioning your Youtube serie, have you considered
| doing it in English?
|
| The Youtube auto-dub stuff is pretty bad and the subtitles are
| quite good but hard to follow with all the vim motions on top
| of it!
|
| Your writing is in English and your code comments too...
| English was not my native language but I'm fluent now. So
| unless you are targeting specifically the Italian viewers, you
| would reach many more people in English. Your content is worth
| being international I feel.
| slim wrote:
| have you considered learning italian ? it's not that
| difficult once you know english
| keyle wrote:
| My grand mother was Italian, I could understand a fair bit
| in the family, but this is technical talk in Italian, it
| doesn't roll off the tongue.
| antirez wrote:
| Hi! I'm perfectly capable of doing the same series in
| English, not that I'm so skilled with other languages, but
| enough to do it: you can find many programming videos in
| English on my channel. However: it will _never_ be at the
| same level of something in my mother tongue, so a few years
| ago I decided that some of my output would be in Italian. Not
| the most accessible, but the most quality. I believe that
| soon or later YouTube videos will have near-perfect dubbing,
| so this also will make the content available to a larger
| audience. Cheers.
| ofalkaed wrote:
| >together with Lisp
|
| Lisp has a lot in common with Forth in that people often reduce
| it to a trick and miss the lesson it has to teach; people
| implement their six words from the bare metal and use those six
| words to implement Forth but never seem to make the leap,
| realize they can take it one step further and implement the
| language they need for the task at hand just as easily as they
| implemented Forth with those six or however many words they
| decided to start with. Sure it may not be the most efficient
| solution but in a time when most people walk around with half a
| dozen cores in their pocket, counting clock cycles is generally
| not a concern and it can probably be more efficient than the
| batteries included solution that comes with eight D cells when
| it only requires a single coin cell. But there is something
| about the weight of those eight D cells, they are substantial
| and we can feel it.
| crq-yml wrote:
| I believe Lisp is relatively more understood than Forth these
| days, in that most of the "big ideas" that have been built in
| it have also been borrowed and turned into language features
| elsewhere. We have a lot of languages with garbage
| collection, dynamic types, emphasis on a single container
| type, some kind of macro system, closures, self-hosting, etc.
| These things aren't presented with so much syntactical
| clarity outside of Lisp, but they also benefit from
| additional engineering that makes them "easy to hold and
| use".
|
| Lisp appeals to a hierarchical approach, in essence. It
| constrains some of the principal stuff that "keeps the
| machine in mind" by automating it away, so that all that's
| left is your abstraction and how it's coupled to the rest of
| the stack. It's great for academic purpose since it can add a
| lot of features that isolate well. Everyone likes grabbing
| hierarchy as a way to scale their code to their problems,
| even though its proliferation is tied to current software
| crises. Hierarchical scaling provides an immediate
| benefit(automation everywhere) and a consequent
| downside(automation everywhere, defined and enforced by the
| voting preferences of the market).
|
| Forth, on the other hand, is a heavily complected thing that
| doesn't convert into a bag of discrete "runtime features" -
| in the elementary bootstrapped Forth, every word collaborates
| with the others to build the system. The features it does
| have are implementation details elevated into something the
| user may exploit, so they aren't engineered to be "first
| class", polished, easy to debug. It remains concerned about
| the machine, and its ability to support hierarchy is less
| smoothly paved since you can modify the runtime at such a
| deep level. That makes it look flawed or irrelevant(from a
| Lisp-ish perspective).
|
| But that doesn't mean it can't scale, exactly. It means that
| the typical enabled abstraction is to build additional
| machines that handle larger chunks of your problem, but the
| overall program structure remains flat and "aware" of each
| machine you're building, where its memory is located, the
| runtime performance envelope, and so on. It doesn't provide
| the bulldozers that let you relocate everything in memory,
| build a deep callstack, call into third-party modules, and so
| on. You can build those, but you have to decide that that's
| actually necessary instead of grabbing it in anger because
| the runtime already does it. This makes it a good language
| for "purposeful machines", where everything is really tightly
| specified. It has appealing aspects for real-time code,
| artistic integrity, verification and long-term operation.
| Those are things that the market largely doesn't care about,
| but there is a hint of the complected nature of Forth in
| every system that aims for those things.
| spaintech wrote:
| It personally feel that Forth if often overlooked as a solution.
| It's great for lowlevel embedded work... even on complicated x86
| hardware. I also think that people shy away because the tooling
| is thin and often DIY, but a Forth exokernel plus a single-
| purpose app can squeeze more from the hardware.
|
| Tethered Forth programming on small devices is an underrated
| opportunity, IMO. There is also the opportunity to revise the
| OpenBoot project, I remember the days of automation for
| deployments at the Bios, it was an amazing tool for massive
| deployments of Sun T systems in telcos.
| codr7 wrote:
| Forth make a nice starting point for designing your own
| interpreters/languages imo. But I find the stack gymnastics
| quickly get in the way of practical solutions.
| meindnoch wrote:
| In my experience Forth is a great match for LLMs.
| johnisgood wrote:
| Which? I did not have much success.
| sweisman wrote:
| I wrote the test harness in Forth for a physics experiment
| launched on the Space Shuttle.
|
| https://github.com/sweisman/cass-edi
| reaperducer wrote:
| Considering the amount of FORTH code in orbit and launched into
| outer space, I expect the first aliens to discover us will
| think it's our universal programming language.
| wartywhoa23 wrote:
| The name alone, which means "onward or outward in place or
| space; forward" is perfectly fitting to a language aimed at
| the stars!
| whobre wrote:
| Decide for yourself: https://skilldrick.github.io/easyforth/
| tdeck wrote:
| This kind of illustrates the biggest problem with the FORTH
| ecosystem, in my opinion. Approximately 80% of open source
| development effort seems to go toward building new, slightly
| incompatible FORTH interpreters to suit the author's own tastes.
|
| Sure, gForth still doesn't have a decent way to make HTTP
| requests or match a regular expression, but writing libraries
| like that doesn't seem to be fun for the average FORTH developer,
| who would rather reimplement a very barebones language
| environment to address the gap left by the other 1200 FORTHs.
|
| It's not that these projects aren't cool, but if you actually
| want the language to become popular why not look at things every
| other popular language has?
| binary132 wrote:
| You seem to be presuming here that wanting FORTH to be popular
| even crossed the minds of the 1201 FORTH developers in
| question. :')
| tdeck wrote:
| At least this author wrote the following:
|
| > So, the question is, how to encourage today's world of C
| programmers to take a look at Forth. How do we convince them
| that Forth can be 10 times more productive?
|
| So they are clearly interested in getting people to view
| FORTH as a productive choice.
| binary132 wrote:
| I'll amend my first comment to say 1200, then.
| ErroneousBosh wrote:
| > but if you actually want the language to become popular why
| not look at things every other popular language has?
|
| Because that is completely missing the point of what Forth is.
|
| It's meant to be a simple high-level language that stays quite
| close to the underlying machine and can be implemented in a few
| dozen lines of assembler to solve a specific problem you have.
|
| It doesn't need to be some massive bloated ball of mud and
| straw like ultra-high level languages such as C, where every
| aspect of the underlying machine is abstracted away in library
| after library.
| tdeck wrote:
| The whole context of this article is "how can we get C
| programmers to understand that they would be more productive
| in FORTH". My thesis is that maybe the attitude of "you
| should be writing everything from scratch, including (often)
| the FORTH environment itself" might just possibly have
| something to do with why people aren't jumping on the FORTH
| productivity bandwagon.
|
| The number of C programmers whose use case is "I need to
| bring up this CPU with a never-before-seen instruction set"
| is a rounding error. The number who need to fit their complex
| logic into 1K of memory is small and dwindling every year. I
| can buy an ESP32 for less than a dollar.
|
| Moreover, there's no technical reason why FORTH programmers
| can't write, share, and use libraries (except maybe the
| aforesaid plethora of incompatible language implementations).
| FORTH is great for creating neat little DSLs that solve a
| specific problem. Stacking these can be powerful, but if you
| personally don't want to use them, or it doesn't fit your use
| case, that's fine.
| andsoitis wrote:
| > "how can we get C programmers to understand that they
| would be more productive in FORTH"
|
| It could also be that they wouldn't be more productive
| (given the kinds of software the typical C programmer
| writes).
|
| It could also be that that is the wrong question.
| saulpw wrote:
| The reason C beats Forth is code-sharing. Forth is a
| better language and system on its own, but it's difficult
| to standardize for reasons both technical and cultural.
| So if you write some really wonderful code in Forth to,
| say, decompress a bytestream, another Forth programmer is
| unlikely to be able to use that code without substantial
| modification. So Forth becomes either a single-person or
| a small-team system at best. Larger teams can't grow (in
| part because onboarding to your particular Forth system
| is a non-standard process), and especially cross-
| pollination between teams and companies is not possible.
| ErroneousBosh wrote:
| > The whole context of this article is "how can we get C
| programmers to understand that they would be more
| productive in FORTH".
|
| They absolutely would not be more productive in Forth. If
| they're writing in an ultra-high-level language like C,
| they're unlikely to be targetting something where Forth
| would make sense.
|
| You need ridiculously powerful processors to run a C
| compiler, and your code is likely targeting some massive
| processor with possibly hundreds of kilobytes of code
| space.
|
| Forth and C inhabit entirely different conceptual spaces.
|
| > Moreover, there's no technical reason why FORTH
| programmers can't write, share, and use libraries
|
| None of the libraries you write will be of any use to me,
| and vice-versa.
| lioeters wrote:
| > ultra-high-level language like C
|
| LOL, thanks for the reminder that most of my career has
| been spent up in the stratosphere, towers upon towers of
| abstractions. Started re-learning C during pandemia for
| embedded systems and microcontrollers, feeling freer as I
| go deeper down the stack. Got into Lisp interpreter, then
| compiler and assembler. Had a chance to study eForth in
| this post, and it can get real close to the metal.
|
| > need ridiculously powerful processors to run a C
| compiler
|
| That's one thing I noticed while getting familiar with C,
| that it's a huge effort to write a compiler in itself.
| Whereas Lisp and Forth even more, creating a
| variant/subset of the language from scratch is an
| exercise for every student. These languages are hidden
| gems, even though they play such important roles in the
| history of computer science. They are relevant, perhaps
| now more than ever when people are losing touch with the
| ground, the basics of code and computation.
| tov_objorkin wrote:
| Forth is pretty lowlevel, i don't think it can compete with the
| highlevel languages. Postfix notation and stack juggling is
| just boring.
| vdupras wrote:
| That's what I would call the "Forth challenge", that is to
| grow out of stack juggling.
|
| When you look at the Forth code of a beginner, yes it's full
| of stack juggling, of "@" and of "!". When you look at code
| from more experienced Forth programmers, there's much less of
| it.
|
| The challenge is to build your way out. There's no fixed way
| to do this, because the best path to do so is generally
| dependent on the task at hand.
|
| Needless to say, most programmers fail this challenge.
| jrochkind1 wrote:
| You are definitely not making it sound attractive for real
| projects where the outcome matters.
|
| Sounds like a fun game maybe.
| vdupras wrote:
| This challenge comes with rewards. Forth has superpowers
| that can't be found elsewhere.
|
| But its definitely not for everyone. I'd say that the
| status quo of Forth being an obscur niche is fine, just
| fine. If you need convincing, if you aren't spontaneously
| curious about Forth, then it's likely not for you.
| jrochkind1 wrote:
| I'm in favor of everyone having fun however they want,
| and you have piqued my interest a bit that it might be
| fun.
|
| But if even the proponents of the language say that
| ("needless to say"!) most programmers will be incapable
| of the challenge of writing good code in it... definitely
| doesn't sound like anything I'd want in anything I wanted
| to be maintainable or long-lasting. If this is the
| outcome you desire, then your, uh, anti-evangelism is
| working!
| vdupras wrote:
| I've never written Forth as part of a team. I suppose
| it's difficult with an average team. But then I try to
| imagine what a small team of good Forth programmers could
| do and I'm thinking it would be a quite powerful team.
|
| If I piqued your interest, might I interest you in the
| introductory series I wrote:
| https://tumbleforth.hardcoded.net/
| tov_objorkin wrote:
| Factoring is good way to reduce the complexity but writing
| math is painfull experience. To be fair, the infix version
| of Forth exists as an extension library.
| NetMageSCW wrote:
| C is pretty low level... and yet.
| Mmrnmhrm wrote:
| The power of FORTH is that creating a variation tailored to
| your specific problem is almost effortless.
|
| In most languages, building a compiler or interpreter is a
| major project. With FORTH, if you're the only user, you can
| have something working in minutes.
|
| I've lost count of how many times I've thrown together a simple
| stack-based interpreter. Whenever I need to encode non-trivial
| behavior in an app, I know I can spin up a quick FORTH and get
| it done.
| MangoToupe wrote:
| The neolithic is still relevant ffs
| K0balt wrote:
| I love FORTH, and wrote a good bit of forth software back in the
| day. The main problem with FORTH is that FORTH developers are
| writing FORTH instead of programs. I mean, that's kind of also
| how writing programs in FORTH works, TBF.
|
| The problem is that every program is a DSL, so it's hard to grep
| unless you built it. It's a great personal hacking language
| though.
|
| I often wonder, though, because of the mechanics of context with
| LLMs, if forth might not be the ideal language for LLMs to write
| simple tools for their own use?
|
| Could we pawn off the "you should try forth" problem onto AI lol?
| Razengan wrote:
| I swear in 2600 AD we'll still be asking the same of C++
| 1vuio0pswjnm7 wrote:
| "... after working with the [SORTA] language for a while, I guess
| I can read it pretty easily, but I also think FORTH is a
| beautiful language)." - djb
| kbr2000 wrote:
| https://www.ioccc.org/1991/brnstnd/index.html
| bobsh wrote:
| Forth is the first language I ever did anything cool with, circa
| 1982. First language to do a mandelbrot on a mac (probably). Used
| it in the enterprise, migrating databases (don't tell anyone). I
| highly recommend colorforth to those looking for maximum forth-
| ness and an amazing tiny runtime. Also, Oberon.
| agumonkey wrote:
| I found the culture in forth very interesting -
| optimizing the code density (threaded interpretation) -
| the dynamicism was said to allow for numerical optimization not
| possible in math libs / fortran long ago (see J.V.Noble
| papers, I'm not knowledgeable enough to confirm his claims but i
| assume they hold some ground) - the bare-metal repl
| feel is also special, as freeing as poking basic on old hardware
| but with the freedom of lisp in a way
|
| forth sits in the thinking-altering languages land firmly imho
| sph wrote:
| May I recommend the Concatenative discord server to dive deep
| into a vibrant, niche community of small forth-like languages.
| There's a lot of cool people in there (I'm just a user)
| agumonkey wrote:
| hehe for sure, it's a forth thread but i also love joy and
| factor, i'll jump in, thanks a lot
| NetMageSCW wrote:
| Surprised at the lack of mention of RPL and the HP-48,49,50
| calculators that use a language superficially similar to Forth
| for user programming and internally use a threaded interpreter to
| implement the calculator.
| tliltocatl wrote:
| IMHO, that's missing out the relevant bit. RPN and stack juggling
| is a red herring. Being able to bootstrap the system from zero
| and then turn it into anything is the real distinguishing feature
| of Forth. The only other language that can do it is Lisp, but
| Lisp assumes dynamic memory allocation to be the most fundamental
| operation while Forth doesn't.
| HackerThemAll wrote:
| > How do we convince them that Forth can be 10 times more
| productive?
|
| Prove that. Record some videos, show me some code and metrics
| that'll be evidence that I'm getting 10x more productive.
|
| Look at the languages in the repository:
|
| C 50.6%
|
| C++ 47.6%
|
| Forth 1.5% <-----
|
| HTML 0.1%
|
| Makefile 0.1%
|
| JavaScript 0.1%
|
| How does that build credibility?
___________________________________________________________________
(page generated 2025-11-09 23:01 UTC)