Cleaning out some old boxes of papers, I came across one of those humor bits that circulate in any profession. Back in the day, it was usually by fax. Then it was email, and now Tweets and other social platforms. (The song remains the same.)
This one concerned “rare” (i.e. made up) languages loosely based on existing languages. The humor depends, mostly, on recognizing parodied languages and certain other topical references (like “Valley Girls”).
In other words, a lot of the funny has sailed, but I found parts of it cute enough to record here…
In the process of cleaning out boxes of old paperwork, I found this company memo, circa early 1980s, that describes a “simpler” way to send email. At the time, email systems were mainframe-based text systems you logged onto and typed at — actually not terribly unlike the web-based email systems today.
The memo reminds me of how it was back then and of how far we’ve come since. Here it is, reproduced as is:
The Hard-Core Coder (blog) just went WordPress Premium. No more ads!
Hate — really truly deeply hate — the damn ads.
Happy Christmas and a Merry New Year!!
In the first two parts of this series I’ve introduced state engines and taken apart a specific instance of an engine. Now it’s time to tie together the design idea with approaches to building a variety of such engines.
Because the programming logic is in the state table, the engine can be fairly generic. That means it’s possible to create a state engine framework you can reuse for a variety of applications.
Last time I introduced state engines and state tables. I showed parts of a simple implementation of one in Python. It parsed the language introduced in Little Programming Languages. This post continues that, so be sure you’ve read that first article.
I got as far as the state table implementing the process, and that’s where this post picks up. I’ll also get into the
SourceReader class that does the heavy lifting.
At one point in my career, the state engine (SE) was one of my favorite AWK hammers. At the time much of the work involved text processing or, in some cases, serial byte processing (which is not quite the same thing). That sort of thing is right in the wheelhouse for a state engine.
They are a very useful tool and an important part of any programmer’s toolkit.
In the Unix world you sometimes hear someone mention an “AWK hammer” or an “AWK nail” — usually in reference to an unexpected, possibly suspect, way of using some tool. In that history repeats itself, in the corporate world, one might have (but never did) hear reference to a “Lotus 1-2-3 hammer.”
The implication is that someone has fallen in love with a particular tool and is using it everywhere. In particular it applies to a situation where using that beloved tool may not have been the ideal choice.
Here’s the last of the oddball Little Programming Languages (for now). This one is a little like LPL-2 in using a three-part syntax (which turns out to be non-ideal). Unlike LPL-3, neither of these are particularly usable languages — more along the lines of being something a language designer amused himself with on a rainy afternoon.
A key goal in LPL-1 was to minimize the use of punctuation characters. No brackets or parenthesis to create syntax blocks. (Square brackets for array indexing and parentheses for expressions, but that’s it.)