I had a teenage phase as a computing history enthusiast, which was centred specifically around Multics and other MIT developments of the seventies, particularly Lisp machines and ITS. (Separately and concurrently I have a soft spot for the C64 and the Amiga. I usually win at retrocomputing trivia.) My admiration for PL/I is one unfettered by any actual experience with it, although when one understands the differences between it and C, the motivation between new projects like Rust and Go becomes blindingly obvious. In the nineties all of the software engineers who had the necessary expertise to reverse C's momentum were working on Java, so only now, after Oracle has ruined Java, has the brain drain been over for long enough to move attention back to putting the other academic discoveries of the seventies and eighties into real use. Rust has a built-in fixed-precision library, so even COBOL's day in the sun could conceivably end.

One other thing about PL/I: it was somewhat infamous in its heyday as being cumbersome and overly complex, but compared to Java and mid-nineties C++ it was quite small. Anything you might read about PL/I being obnoxious or baroque is propaganda written by people with access to, at best, a few hundred kilowords of core, i.e., less than a megabyte of RAM. You might not want to use it for embedded programming these days, but the most important implementation, Multics EPL, was a systems-oriented subset that didn't include all of the language's features.

Anyway. I assume this was brought up because I casually made mention about tinkering with Octavia. To be honest, programming a basic language interpreter isn't really that hard, though it does require some creative problem-solving if you've never taken a course on it. Clean tokenization was something that took me a few tries to understand properly; the first few designs I wrote in high school were based on string prefix-matching, which invariably led to problems when function notation and infix operators were combined. Even Octavia's implementation of tokenization, which was written all the way back in 2009 when I was still a first-year undergrad, had some deficiencies in this regard for the longest time—it would occasionally do bizarre things like abort parsing because of unmatched parentheses inside string literals. I haven't actually coded a language from scratch since that time (Sappho's p3 interpreter was written around the same timeframe, in an even worse language) so I'm somewhat looking forward to doing a new implementation, especially one with less of a post-hoc attitude toward functions and objects.

Programming language theory and linguistics have a lot in common, but unfortunately enthusiasts of both are scarce. PLT does a lot of work with formalizing concepts of a statement's context that are potentially a gold mine for conlanging, especially philosophical languages. As far as I know Lojban and Ithkuil never approached these subjects and have mostly concentrated on providing the tools that their respective authors felt they needed to describe their own thoughts—by far my favourite is that Lojban wasted a three-phoneme word (which is prime real estate from a Huffman coding perspective) on a connective that indicates the Cartesian product (every pairwise combination of elements from sets X and Y), which I sincerely doubt anyone has ever used or will ever use.

So... yeah. Look forward to that. I'll try to make it interesting without making it too hard to convert Octavia code.