Thoughts on Forth Programming

Can you please give some examples on those who are extremely productive using FORTH? I'm intrigued. I think FORTH could be very useful to someone who prefers to work alone or in small group, but I'm not sure how do they use it in daily life.

Forth style is great for writing but very hard for reading. I&#x27;m playing around with the idea that you use a Forth-like language to interactively develop code. The steps you perform become AST nodes. Then when you want to read it, it comes out in another form.<p>This is more ideal because it is more interactive and you can see the immediate result every step of the way. This is different than writing traditional code because sometimes variables and functions are not returning what you expect and you are working blind under the wrong assumption. You then need to debug it to find out where the value is not what you expected and why. Forth wins for writing in my book because you have immediate feedback which lifts some of the cognitive load and saves time on debugging.<p>However, the problem with reading Forth is that it forces the cognitive load of having to know what is on that stack at every moment. If you make one little mundane mistake then it completely changes the meaning of the code and you get lost. So for reading I think you need to read it in the more traditional language forms.<p>Some kind of IDE could let you interactively write. But once you save it, you can read it in a more traditional prefix &#x2F; infix syntax.

This quote stood out as sounding quite far-fetched: &quot;on many CPUs the interpreter consists of two or three machine instructions&quot;. Can someone point to an example?

The main problem with such a stack based language for &#x27;serious&#x27; programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would probably be pretty convoluted.

Anyone who wants to see a modern forth with elements of common lisp that is focused on application development should check out Factor.<p>Concatenative languages are really fun to use once you get over the initial hump.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;factor&#x2F;factor" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;factor&#x2F;factor</a>

I have been looking at Forth programming and one thing I would like to figure out is how to use gforth under Linux in a pipeline of shell and awk. I haven&#x27;t yet found a practical use for Forth in this environment yet...

&gt; One such property is the use of reverse polish notation and the lack or eschewal of local variables.<p>What do you gain by eschewing local variables in favor of reverse polish notation that throws values onto a stack?

&gt; In Forth there is only memory - word and byte-sized cells of storage in memory, and stacks. You step down on the level of assembly language which may sound daunting, yet gives you full control over every aspect of memory layout.<p>Other than in niche or pet projects, can this even work?<p>If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder?<p>Or do you just punt and use ascii code pages?

I feel like, from the &quot;individualism&quot; perspective, Forth is really a tool for hackers.<p>Hackers usually work alone or in very small groups, and the tools they need are usually handcrafted. They do not need corporate-level software, and long do they strive to be left alone, without being bothered.

The classic problem with inventing your own language is that now you can&#x27;t understand anyone else. If we&#x27;re going to have widespread communication then we need widely-understood languages and libraries. The goal should be to replicate understanding. We need to evolve a <i>common</i> vocabulary rather than ending up with nearly as many private dialects as programmers. Publishing libraries and gaining users for them should be a primary goal.<p>There are Forth words with generally agreed-on definitions but it seems it&#x27;s not designed to grow a large, common vocabulary in the way that modern package managers enable.

[deleted]

Ultimately, programming languages lie on a few spectra. Extremes are annoying, lack of access to them is sometimes too.<p>The big problem with the extremes especially the lower, is the amount of discipline they require from the user. If your team has anyone that ignores this, you get garbage and bugs, which get hard to fix as either the language constrains you due to structure or the problematic behaviors are depended upon transparently and this very hard to factor out.<p>Low level languages make it easier to commit the latter mistake. In higher level, this usually rears its ugly head as bad design where you have to replace big chunks of code at the same time, sometimes leaving compatibility glue. You cannot do that in some of the higher level &quot;discipline&quot; languages or have to hack it in nasty ways (hey Java and C# with reflection, C and C++ even with macros; try doing it in Haskell), while in something unstructured you&#x27;re up a creek without a paddle...<p>On the upside, the DIY nature makes it harder to produce bad or any abstraction, as trying to write anything you do not understand ends poorly. The problem then with getting the debugger in is that this can let you code with incomplete understanding and depend on things that are not meant to be depended upon. Everything becomes an API. That accidental delay in revision x of hardware? Can&#x27;t get rid of it. Used a slower bus in the past? Oops.<p>Defined interfaces are important too. Which is why VHDL and Verilog exist even in hardware world - and even they are on the soft side of defined.