"not a game" - well, he certainly hid this well behind a playful and enthusiastic way of teaching, as when he was our Props of Matter lecturing prof at Birkbeck College in the early 70's. And very effective too, not that I followed the Physics path beyond that (the siren call of computers was stronger for me).
I spent many happy years making the Z80 dance, from Summer 1976 through Spring 1989, architecting and writing statistical multiplexors at MICOM Communications in LA. Micro 800 line. That is a Hard Real Time application, and the hardware for the first model was only 4KROM and 4KRAM. I made one Z80 do what the competition (CISCO) swore required 5, and laughed discreetly at us, but it worked, sold out the bottom end market from under them, and suddenly we had a runaway and I got an excellent team to buttress and ultimately take over the baton from me. I would dream in Z80 ASM in those days.
The Z80 had two hardware features that made it possible, and that nobody here has mentioned yet:
1: two sets of working registers, with a one byte instruction to toggle between them. I instruction cyclke to context switch between application and interrupt handlers. Only the TI 9900 came close with its in-RAM working register sets.
2: hardware vectored interrupt dispatch, fully suppported by theor accompanying peripheral line. Just a few clocks from raising an interrupt to executing the first line of code (typically switch context then ...) of not only the device but it's reason for interrupt code. No code wasted interrogating bitfields and scanning registers. 2 usecs interrupt response time. Faster than an Intel i960 with its 50MHz clock, that came along later.
My Lua system uses MOP too, though I never heard that term before. And structured pipes. I like it and wrote it for a dataflow bsased event driven system.
I still use a version of FORTH as an embedded debug tool, have done for several different CPU architectures over the years. I wrote some extensions that help to offset the "double edged sword with no handles" danger, such as local methods, call/return prototypong (basically formalize=ing the conventional word definition comment, which I also snag as is into definitions as a help string) that garuntees stack frame handling on entry and exit. Also wrote an auto-translater for C wrappers of function calls and struct definitions to get symbolc interaction with the code being debugged. Really speeds up behavioral debugging (Real Time systems have to be runnig to diagnose, not halted and flayed open on the operating table like breakpoint debugging does).
I'll echo the observation: datacomms protocol parsing and generation are nothing but state machines.I started in that domain back in 1973 or so, and some configurations - statistical multiplexors for example - may be running upwards of 34 FSM's concurrently and independently. And that with a mix of multiple instances of one protocol. So I developed a cooperative multitasking pattern that ran on a virtual OS scheduler. Indeed in some systems it was the real OS. State variable is a function pointer to a function that returns its own protoype function pointer. Arguments include event, plus data plus state context. Supports submachines too. Still using it. No switching complex stack contexts, runs fast.
Forgive me, but I recall, with some decades of practice, a major point in FORTH is that one constructs a vocabulary and syntax specifically for solving the problem at hand. Compiler primitives are just as first class as regular word (aka function) definitions, including how to compile itself as well as what to do when executed (DOES> keyword, which can itself be redefined). FORTH may have a clunky and primitive reputation, but it seems to me it qualifies as a programmable programming language.
Sure. But the degree of clunkiness matters. Forth doesn't have the ability to build linguistic _abstractions_ the way Racket does. But if you want to add Forth to the evidence of the paper's thesis, that's fine, more the better.
Started in 1967, in support of my job as commissioning technician (bean counter title - I was only 19 and no degree) at Elliott Brothers Elstree on their 4100 mainframe computers production line. Did hardware design and supporting software/firmware for a decade before switching primary job to RTOS's and firmware. Still employed. I've posted my general CV elswhere here.
50 years. Somewhat different to most. Mixed hardware/firmware/software, niche talents matched to niche markets. And practically all self-taught. Along the way got a BS and most of an MS in CS but none of it was applicable to my career, nor required for it, except the one class I keep alive was the FSM class. Perfect for Hard Real Time Event Driven applications. My metier. Almost all of the 50 years qualifies as nostalgia, even current, because it has all been fun, all been coninuous learning, all been continuous invention, and except for some esoteric math in my current Audio DSP path there has never been a book about it.
1967-9 accidentally hired at Elliott Automation UK as comissioning technician, finding bad wires/doa components in their 4100 series mainframes as they came to the end of the production line, prep for shipping. Completely discrete hand built machines, right down to hand-woven 48K x 24b main magnetic core memory. No prior experience outside of hobby electronics, only 19, CS did not exist then. This experience probably seeded all my first principles of computing, I had to teach myself in intimate detail how a room sized computer works, and how to program it. Both good and bad.
1969-71 (I know, by decade, but my trajectory does not fit decades easily) design engineer at an EG&G UK subsidiary called Nuclear Measurements. Another accident. Made instrumentation for the two main Nuclear Fusion labs Daresbury and Culham. Got to climb around inside the Zeta Pinch 1MF capacitor and the Tokamac. By chance visited a PCB layout researcher using my old 4130 with vector graphics, thesis on rats nest automatic layout techniques.
1971-5 Another poach, this time into data communications world. I'll note here that although I was then a hardware nut, programming computers is always an essential skill to have. And also in those days of really tight resources, doing it efficiently was default, whatever Tony had to say about premature optimization - the code has to at least fit before it can be made to work. In this phase I even had to design and write an ASM a custom computer a bit more featured than a Z80, only in SSI 7400 series TTL. And in 8008 days, no Z80 when I started.
Still a big-eyed kid, somewhat bemused that folks wanted me to actually pay me to do all this learning. Learning that even today seems to be missing from CS/CE, at least as I can tell from graduate hires since then even up to today. Got very good at "Making it up as I went". There was no book, really, for what I was having to produce.
1975-89 moved to sister company in LA - poached again - got even deeper into data comms, designing Statistical Multiplexors and protocols for University time share computer centers. Employers made their $Ms but neglected to mention stock options to me. OTOH as a founder and tech lead I had a blast, and seeded a great dev lab culture around me, many of whom are still in touch.
1989-97 This was a really fun time; I and buddy did our own start up (Lone Wolf Technologies) based on a mission critical deterministic protocol we had dreamed up and a product using it to network MIDI synthesizers and controllers in large venues and pro studios. Moto 68HC11 box did 4 ports, glass fiber networking physical layer allowed up to 2 Km separation, multiple boxen, each with a mirrored virtual 16x2 config LCD onto the network as a compound entity (edit any box from any box), full soft topology routing and filtering and remapping. Yet more learning OTJ, and inventing. And the customer base was, well, rarified. Herbie Hancock, ELP, INXS, that rarified. Not actually a Good Thing as it transpired. No volume. But oh what fun. Then Paul Allen invested. A long story not for here. But moved us all to Seattle.
1998-9 designed a FPGA for autonomous isochronous multi-medial FireWire transport (AFAIK the only one that did not funnel channel data through the CPU). Was missing hardware, this was an intense but ultimately successful gig, eventually made its way back into music world as control surface driver/interface.
2000-7 Second time Lone Wolf, soon renamed SingleStep, designing a graphical programming/delivery platform aimed an large scale network management. Again great OJT learning and invention but customer base not so much fun.
2008-present now this one is a fun employer with a fun product. Not just fun to my nerd core - fun is their product. I refer to Nintendo. Worked on Audio engines for WiiU and Switch.
The two big gaps: "Consulting Years". Nail biting, more like. No nostalgia for those.
So, not your typical career path. No front end / back end / full stack crowded job market. I'd have been out of that and unemployable probably 20 years ago if that were the case.
Native WinAmp has two dropin extension systems. The one everybody seemed to use was MilkDrop, but they also had AVS (Advanced Visualization Studio), for which I wrote a bunch of extensions about a decade ago. These included several composition dlls (multi-lane video pipes, MIDI control, joystick control, 30 sec rolling video recorder/playback) and also a number of effects (image animations, placers, blenders, oscillators). This made for a very engaging interactive experience, especially flying through using the joystick to control pretty much any set of parameters. Turns out the visualizers have hidden strange attractors that never appear when just using passive mode. That was in XP, I have waiting a Windows 7 build TODO.
I'm semi-guessing the browser re-implementation does not support these. Pity.
