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

51–60 of 97 posts

Re: Thoughts on Forth Programming

#51

Post by cjfd »

DonHopkins wrote: post #50
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…

I wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware: https://github.com/openbios/openfirmware/blob/d5cc657ce81c0f... \ Forth dynamic storage managment. \ \ By Don Hopkins, University of Maryland \ Modified by Mitch Bradley, Bradley Forthware \ Public Domain \ \ First fit storage allocation of blocks of varying size. \ Blocks are prefixed with a usage flag and a length count. \ Free blocks…

Fair enough, sounds like a workable solution.

Re: Thoughts on Forth Programming

#52

Post by bcheung »

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 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.

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.

Some kind of IDE could let you interactively write. But once you save it, you can read it in a more traditional prefix / infix syntax.

Re: Thoughts on Forth Programming

#54

Post by exikyut »

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.

Low-level hardware bringup?

Perhaps the reason this only ever ends up being managed by one or two people is that >2 people simply do not need to manage the fussy details once they've been abstracted/normalized out.

Also, I lurked in comp.lang.forth for a week or so a while back and learned that Mattel were using Forth as a runtime for their toys back in 2004, at least: https://groups.google.com/d/msg/comp.lang.forth/omi6PUvymEE/..., https://groups.google.com/d/msg/comp.lang.forth/LzOasFOyIMg/...

Re: Thoughts on Forth Programming

#55

Post by majewsky »

g82918 wrote: post #3
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…

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.

Re: Thoughts on Forth Programming

#56

Post by AstralStorm »

Ultimately, programming languages lie on a few spectra. Extremes are annoying, lack of access to them is sometimes too.

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.

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 "discipline" 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're up a creek without a paddle...

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't get rid of it. Used a slower bus in the past? Oops.

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.

Re: Thoughts on Forth Programming

#57

Post by [deleted] »

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.

[deleted]

Re: Thoughts on Forth Programming

#58

Post by DonHopkins »

lukego wrote: post #45
DonHopkins wrote: post #41

Earlier quoted context omitted.

Here's the interview with Mitch Bradley saved on archive.org: https://web.archive.org/web/20120118132847/http://howsoftwar... I've previously posted some stuff about Mitch Bradley -- I have used various versions of his ForthMacs / CForth / OpenFirmware systems, and I was his summer intern at Sun in '87! Mitch is an EXTREMELY productive FORTH programmer! He explains that FORTH is a "Glass Box": you just have to memori…

I love your posts about this stuff :) I was also an "intern" of sorts for Mitch as recently as 2009 or so. I wrote the audio driver for OLPC XO 1.5 and went to Taipei to help with the bringup. I was amazed to watch Mitch using Forth to interactively tweak the DDR memory settings, find bugs in the motherboard, and find bugs in the CPU which was a godawful x86 from VIA that had seemingly only been debugged enough to bo…

That must have been a fun and unique opportunity! His programming and debugging process has to be seen to be believed. OpenFirmware is definitely a highly polished work of love. Its well-commented and meticulously organized source code reads like fine literature or classical music! Stuff like the metacompiler and kernel, for example:

https://github.com/MitchBradley/openfirmware/blob/master/for...

https://github.com/MitchBradley/openfirmware/blob/master/for...

Re: Thoughts on Forth Programming

#59

Post by DonHopkins »

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…

Here's a cool dynamic WebAssembly based Forth:

https://el-tramo.be/blog/waforth/

>The Interpreter

>The interpreter runs a loop that processes commands, and switches to and from compiler mode.

>Contrary to some other Forth systems, WAForth doesn’t use direct threading for executing code, where generated code is interleaved with data, and the program jumps between these pieces of code. WebAssembly doesn’t allow unstructured jumps, let alone dynamic jumps. Instead, WAForth uses subroutine threading, where each word is implemented as a single WebAssembly function, and the system uses calls and indirect calls (see below) to execute words.

>The Compiler

>While in compile mode for a word, the compiler generates WebAssembly instructions in binary format (as there is no assembler infrastructure in the browser). Because WebAssembly doesn’t support JIT compilation yet, a finished word is bundled into a separate binary WebAssembly module, and sent to the loader, which dynamically loads it and registers it in a shared function table at the next offset, which in turn is recorded in the word dictionary.

>Because words reside in different modules, all calls to and from the words need to happen as indirect call_indirect calls through the shared function table. This of course introduces some overhead.

>As WebAssembly doesn’t support unstructured jumps, control flow words (IF/ELSE/THEN, LOOP, REPEAT, …) can’t be implemented in terms of more basic words, unlike in jonesforth. However, since Forth only requires structured jumps, the compiler can easily be implemented using the loop and branch instructions available in WebAssembly.

Re: Thoughts on Forth Programming

#60

Post by Rerarom »

exikyut wrote: post #54
Rerarom wrote: post #32

Earlier quoted context omitted.

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

Low-level hardware bringup? Perhaps the reason this only ever ends up being managed by one or two people is that >2 people simply do not need to manage the fussy details once they've been abstracted/normalized out. Also, I lurked in comp.lang.forth for a week or so a while back and learned that Mattel were using Forth as a runtime for their toys back in 2004, at least: https://groups.google.com/d/msg/comp.lang.forth/…

Thanks, I did not know the word bringup
Post reply on HN