Monday, November 08, 2021

On The Timelessness of Coding

I have this hypothesis that if you can write clean, elegant, modular forth code to solve a problem, then you truly understand the essence of problem solving.

I suggest this because forth is so flexible that while it is possible to build something beautiful, it's much easier to go terribly wrong and create an unreadable, unmaintainable, monstrosity.

To test this hypothesis, I've been carefully making my way through the 1984 text Thinking Forth, a classic book that tries to teach problems solving through the lens of Forth.

In the section on sharing components, there's an example of coding a feature within a text formatter. While the example is not the most arcane in the book, it still seems dated to say the least. Here's some of the sample code, found on page 294:

: [DISPLAY] ...
( the original definition, always does the output) ... ;
VARIABLE ’LOOKAHEAD? ( t=looking-ahead)
VARIABLE ’TOC? ( t=setting-table-of-contents)

Old school, right?

The day after I read this section I received a feature request from one of my customers: a PDF file was occasionally rendering with a page break at just the wrong location. The result was a legal document with the notary's signature block on page two by itself. The request was to detect this scenario, and move some of the previous page's text to the second page, thereby making the document kosher.

I'm using PHP's fpdf library to build the PDF and it provides no built in way of handling this scenario. I am going to have to craft a custom solution.

What struck as remarkable was how the example from the forth code was surprisingly similar to the problem I was solving today. Both called for the ability to execute layout code in an invisible way and then re-execute that code in a visible fashion, this time informed by what was learned during the first execution.

So much as changed in computing since 1984. And yet, the problems and their solutions remain eerily similar.

No comments:

Post a Comment