The First Rule of Forth¶
Like the film “Fight Club”, The first rule of Forth, is to not talk about Forth!
I read this interesting article recently which does echo my own experience since starting Forth in 2014.
The Polarizing Effect¶
Source: https://github.com/narke/colorForth/raw/master/cf2019_colorForth.pdf Page:13 and reproduced in part below.
IMO Forth is a polarizing language because it can dramatically increase productivity in software development. This has several effects :
Non-Forth programmers feel uncomfortable when a Forth programmer produces a program in a half or a quarter of the time that they would take. Nobody likes to be made to feel like an idiot.
Forth programmers have a significant advantage, so they naturally love “…one of the best-kept secrets in the computing world.”
Programming in Forth is fun it is creative rather than mechanical work
Forth is different and can have a steep un-learning curve
Warning
People either love Forth or hate Forth there is wide distance between the two extremes
An anecdote¶
In the late 1990’s I was working on a three month contract, programming an LCD drive in C.
There were four special constraints :
The interface was I2C and the power consumption was critical, so only the minimum information must be sent, that is required to update the LCD
There were two LCD driver chips, one for the left half of the display, the other for the right
The whole display is mounted upside down the graphics mode x,y = (0,0) coordinate is in the bottom right hand corner.
The 8x8 character glyphs have to be rotated by 180 degrees.
The interface is similar to ANS Forth’s TYPE and AT-XY, but in C.
To solve this problem I first added a simple talker program, written in C that connected the devices serial port to its I2C bus and memory something like PEEK and POKE, I2Cread and I2Cwrite.
Then I used SwiftForth to create the other side of the talker interface and words to display characters and the memory map in the device that was used to store the current LCD data. I also a word to rotate the font data and save it as a C file.
Having developed the program in Forth on a PC, testing all the while on the actual ARM target device, Itranslated the Forth program to C. Since I knew that I would be doing this I did not use any fancy Forth features such as CREATE …. DOES> or EVALUATE , and I kept the Forth word names compatible with C no “% & * + - . > < “ etc. characters.
The timescale for this was roughly three weeks of fun Forth development, about a week to convert to C. Then I cleaned up the code a bit, improved the documentation and so on, and after about 6 weeks I presented the finished code to my colleague an experienced and competent C programmer. He was surprised that I had completed the work so quickly, but was embarrassed that I had shown that his original time estimate was so wrong. No one likes to feel that they are inferior to anybody else, or that their career based on C is maybe not the most productive. My contract was not extended.
