Forums  > Software  > Forth in a non-embedded setting  
     
Page 1 of 1
Display using:  

gax


Total Posts: 17
Joined: Apr 2011
 
Posted: 2017-06-21 19:27
Having a few free days at work (while I switched teams) I decided to play around with some Forth. I'm still trying to see the point of Forth outside of an embedded environment. Most Forth use cases I read about seem all related to embedded stuff. Out of curiosity I would be interested seeing if anyone (in a past/present life) used Forth in any non-embedded setting.

jslade


Total Posts: 1136
Joined: Feb 2007
 
Posted: 2017-06-23 05:42
Some Brazilians I went to school with used to debug postscript using their forth knowledge. I assume they learned it because Risc was the big thing at the time.

Call me crazy, but I was thinking of learning Ada-SPARK.

"Learning, n. The kind of ignorance distinguishing the studious."

gax


Total Posts: 17
Joined: Apr 2011
 
Posted: 2017-06-23 20:47
Never got around to learning Ada, but anything used in commercial aviation gets my respect. The thing I found appealing about Forth is that its fairly straightforward to implement your own interpreter in a weekend (I converted to C this guy
https://github.com/AlexandreAbreu/jonesforth/blob/master/jonesforth.S
).
The downside is that due to years of being subjected to C/C++ my brain struggles with the implicit parameter passing via the stack. You have people like Chuck Moore claiming extreme productivity in Forth, but the learning curve seems real steep.

jslade


Total Posts: 1136
Joined: Feb 2007
 
Posted: 2017-08-17 02:28
I think you can get productivity speedups in exotic languages (I became fond of APL, thanks to TonyC touting it on here, and did some time with a weird lisp). The problem is always, what do you do when you have to share code with somebody. Or what if your exotic language goes away?

Ada interested me for safety reasons, but alas I have no time for such things. I think if I ever do get the time, I'll write statistics papers or something instead.

"Learning, n. The kind of ignorance distinguishing the studious."

sbmassey


Total Posts: 1
Joined: Sep 2017
 
Posted: 2017-10-10 03:47
The trick to writing Forth is to keep as little as possible on the stack, and to put most things in global variables, which obviously goes against the grain for pretty much any modern programming language these days.

I doubt the language has much to offer outside of barebones computing environments, although I do fantasize about combining the best parts of Forth and q in occasional perverse moments.

kc11415


Total Posts: 44
Joined: Mar 2005
 
Posted: 2018-01-03 21:50
As noted by others, handcoding PostScript is the closest I've come to Forth. I played around with binary tree fractal graphic designs, using recursive descent to walk (and render) all the branches of said trees. When the depth became more extensive, the printer would have to work for several minutes or longer to do the page render.

Back when I did that, the CPU's in most laser printers were not so different from the CPU's inside typical unix workstations. Nowadays, printer CPU's are puny compared to desktop PC's.

Forth and stack-oriented architectures tend to be efficient & effective for resource-constrained platforms.
Even many small embedded microcontrollers have an embarrassing excess of spare resources, just for the sake of reducing how many different SKU's must be stocked.

From this observer's perspective, the only apparent modern situations where extremely limited resourcing might still need a stack-centric software model might include:
1) minimal soft-core CPU's implemented in an FPGA;
2) a custom chip CPU design to be sent to a foundry, while avoiding the design complexity of a modern CPU architecture.

Motivations for pursuing such could include: ancillary co-processors, or else an MPP grid of many small cores.

Others may rightly have other perspectives on this.

1) Standard disclaimers apply, and then some.
Previous Thread :: Next Thread 
Page 1 of 1