Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Forth Programming

call-with-current-continuation.org

Post reply on HN
Print view View original

61–70 of 97 posts

Re: Thoughts on Forth Programming

#61

Post by [deleted] »

DonHopkins wrote: post #37
it wrote: post #4

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

FORTH has both an "inner interpreter" and an "outer interpreter" (aka the compiler, but that also works interactively like an interpreter). The inner interpreter is the thing that threads between words, and is typically an assembly function named "NEXT", which can be just a few instructions. Here is the FIG-FORTH 6502 implementation of "NEXT" (which is a bunch of instructions since the 6502 has 8 bit registers and si…

[deleted]

Re: Thoughts on Forth Programming

#62

Post by loa_in_ »

cjfd wrote: post #48

The main problem with such a stack based language for 'serious' 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 p…

GForth has a word ALLOCATE exactly for that purpose. Allocates a block on heap, returns address. Works on Windows, Linux, Android, embedded

Re: Thoughts on Forth Programming

#63

Post by zozbot234 »

bcheung wrote: post #52

Forth style is great for writing but very hard for reading. I'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. 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 be…

> Forth style is great for writing but very hard for reading.

It's the lack of type- and structural indications. I like De Bruijn notation for lambda calculus, which gives you a "postfix" syntax like in Forth (only for function application though, not for lambda abstraction!) but is semantically just plain old lambda, with all that implies (easy to extend with types, no weirdness in stack interactions, etc. etc.). Unfortunately I've not seen it implemented in real-world systems, except perhaps in some theorem provers.

Re: Thoughts on Forth Programming

#64

Post by clarry »

jancsika wrote: post #21

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

The code becomes trivial to factor, because you don't have any named variable references that would need to be changed. If you find a sequence of words you want to put in a function, you can literally just cut and paste them out. Likewise, you can inline a word just by copypasting its definition in place.

Re: Thoughts on Forth Programming

#65

Post by coldtea »

Rerarom wrote: post #32
markus_zhang wrote: post #11

I feel like, from the "individualism" perspective, Forth is really a tool for hackers. 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.

What kind of projects are generally done by individuals even inside companies? I'm thinking maybe some simple device drivers but could be others.

Tons of projects. Even many well known today languages, frameworks, etc, started life as one man's initiative and pet project, which they worked on alone, inside a company.

But also tons of official projects in the enterprise. A company needs an X tool, Y is known for his capacity to deliver, they get assigned to make the tool.

Not every project requires a team.

Re: Thoughts on Forth Programming

#66

Post by coldtea »

nvahalik wrote: post #2

> 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. Other than in niche or pet projects, can this even work? If you deal with any sort of multibyte data like Unicode, doesn’t this become way harder? Or do you just punt and use ascii code pag…

>Other than in niche or pet projects, can this even work?

All kinds of projects have been written in Forth, so yes.

Also, regarding "You step down on the level of assembly language which may sound daunting, yet gives you full control over every aspect of memory layout.", until around the 80s, tons of software, commercial or not, including full blown games like "Prince of Persia", was written in assembly, so again, yes....

Re: Thoughts on Forth Programming

#67

Post by coldtea »

majewsky wrote: post #55
g82918 wrote: post #3

Earlier quoted context omitted.

You define words which are like functions which you could use to operate on multibyte data. Most forth code uses large dictionaries of words. So it will look like 'dosomething decode bytes' where bytes is your utf8 and decode is some utf8 decoder and so on. edit: see https://rosettacode.org/wiki/UTF-8_encode_and_decode#Forth for a forth word for decoding utf-8

Looking at this Forth code as a programmer who has never written any Forth code, I can understand how "ordinary" code looks to non-programmers. That whole RPN business means I cannot even figure out where to start reading.

Well, being confused by RPN is a pretty low bar. Kids used to use it in their math class, on scientific calculators...

Re: Thoughts on Forth Programming

#69

Post by rvense »

rabidrat wrote: post #31
jancsika wrote: post #21

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

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. Eschewing local variables means you have fewer things to name.

I heard the two problems are that we have only one joke and it's not funny.

Re: Thoughts on Forth Programming

#70

Post by armitron »

bcheung wrote: post #52

Forth style is great for writing but very hard for reading. I'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. 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 be…

Plenty of valuable things that fall out of the norm can be "hard to read" if one doesn't invest any time whatsoever (e.g. Lisp).

The real question is what happens if one does invest the time. In the case of Forth, one needs to commit to memory the standard words. After that point, it reads smoothly and unambiguously (assuming good coding practices and stack effect declarations, bad code that's hard to read can be written in any language).

Same thing goes for Lisp and parentheses.

Alas it is far too easy these days to dismiss things that do not immediately "click" since fewer and fewer people seem willing to make the effort due to conditioning and network effects. This has led to a proliferation of bad languages and a lowest common denominator approach to programming.

Post reply on HN