paulrpotts

A couple of years ago I worked on a project that involved parsing the very idiosyncratic output of a lot of different command-line commands. Not standard or semi-standardized commands like cat, ls, etc. - a vendor-written command line interface running on a microcontroller, for testing a board. Because apparently a number of different engineers worked on it, all the commands had "ad hoc" output formats, with very little commonality in the way the output was formatted, so there was not a lot of opportunity to write common handlers. I wound up using a lot of Python regular expressions that captured specific fields in the output, handling IIRC about forty different commands.

The best I could do was to break the regexes down across multiple lines and comment each line, and break the handlers down into a hierarchy of smaller functions. Each function had a number of sample strings right in the code, and each file of code for handling the variations on output of a single command also had a unit test right in the same file which fed all the samples to the regexes. So the handling of the 40 different commands could be unit-tested very quickly with a single pytest command line. This was a godsend to help keep my change things-test things-change things again "loop" very quick.

The alternative might have been to actually write parsers, but I don't think that would have been more readable and it certainly wouldn't have been as quick.

I don't think language designers should get rid of regexes and I don't think programmers should stop using them. I do think there is definitely room for languages that implement regexes with more syntax. People might argue that this is just needless syntactic sugar, but so is spelling out keywords like "else." We ought to be looking at prior art. The history of programming languages is a very deep trashpile containing a lot of gold that can be mined with a little effort. SNOBOL's syntax for pattern matching was maybe too wordy by modern standards but I'm sure a lot of younger programmers would be pretty surprised to find how early a lot of things like regexes were invented, and how inspirational it can be to look at old languages.

>"It doesn’t matter where you work, as long as you get the work done."

Having worked with a number of overseas teams in China and India, it's actually somewhat difficult for US-based teams to work with teams up to 12 hours "distant" and also who have different sets of official holidays. I've been in so many status meetings that are either late at night for me or late at night for overseas team members so we can sync up, only to have bad network weather make it difficult to hear each other. Management tolerates these difficulties and added delays and inefficiencies because the labor cost difference is so large. While I love the idea of relocating overseas myself I don't think they'd tolerate continuing to pay what I earn as a US-based person once I was no longer US-based.

Well, I never actually said I really approved of their "walled garden" app store. I will say that I use Signal, and once I've installed it I can sign out and continue to use it. And there's no need to stay signed in to use the cell network for either voice or data.

You need to sign in to an Apple account to get it going for the first time or to buy apps through the app store, or to do software updates. But you don't need to stay signed in or use the cloud services. Granted, it will pop up annoying notifications, but (at least so far) you're not required to use their servers. I have a second iPhone which I bought unlocked and don't have any phone service set up for. I bought it specifically to use as a camera. I can use it on my WiFi, not signed in, record video, AirDrop the files to a different machine, and never connect to iCloud. The day Apple starts doing what Microsoft is trying to do with Windows and remove the possibility of access without using the cloud will be the day I stop using iPhones.

I have not had a breakdown quite like that - I never had hallucinations/delusions. But in my 32 year career I have gone through stages where I became:

- Extremely depressed and anxious. (Still able to function at a pretty high level at work, but outside of work, spent all my time sleeping or crying, was very lonely, etc.) I eventually came out of this after a long series of antidepressant medications and counseling but ultimately I think a lot of the improvement came from adding traditional fats back into my diet. I had been on low-fat food for so long I think I was starving my brain of necessary fats. My mom had followed the food advice of the time which was to reduce butter, eggs, etc. I kept up with that through my twenties and it did not serve me well.

- Extremely stressed. I have worked for some very demanding bosses in startup environments. I'd wind up sleeping badly, grinding my teeth producing TMJ pain, reflux - wound up in the ER for a suspected heart attack in my early 30s (after tests it seemed like there was no actual heart problem, just very bad reflux due to stress).

- "Lost it" at a co-worker due to a COVID gaslighting/minimizing boss and co-worker. Due to a daughter who was high risk due to Down Syndrome/congenital heart disorder, I took COVID very seriously and my supervisor... did not. In fact he made a mockery of both CDC and company safety guidelines; he'd wear his mask on his chin, pull it up over his nose briefly when he rolled his chair to within 6 feet of me, then pull it down again as he rolled away; he got the whole team in a room for a Christmas party and proceeded to give a speech with his mask off. Co-worker who worked next to me was monkey see, monkey do. I was already stressed, putting in a lot of long hours, and was constantly asking him to please comply with the mask rule. One evening after a week of way too little sleep and asking him the third time that day to please keep his mask on, I lost it and really blew up at him. I was fired "for cause," the first time that ever happened to me. It meant I was not able to collect unemployment.

I regret the last one; I should have been able to walk away and take it up with HR. The thing is, by the time a work situation gets to the point where you have to involve HR, that job situation has likely gone irredeemably sour. I had no growth path in that job after almost 7 years; the software development efforts were being migrated to a new division in China run by a nepotism hire. Really, I should have left the job earlier. I have a tendency to really, really want to complete projects I have put years of work into, even when the company does not treat me properly, and I enjoyed the work I did there. It's sometimes bad to love your work, especially when combined with an excessive work ethic that was beaten into me as a child. It has taken me years to be forced into healthier a work/life balance so if I had any advice, it would be to seek that balance earlier than I did.

Great article, no notes. I think you are correct about Stroustrup and want to amplify on that a little bit.

I will add that I'm in my mid-50s and have been programming since childhood and so I've had a chance to observe the evolution of C++ since the not-quite-C++ implementations such as those in THINK C (Object Extensions to C) and TCL (Think Class Library). I've used quite a few C++ frameworks and libraries that existed pre-STL including Borland's OWL 2.0 and the old Turbo Vision framework, as well as the first version of MFC (Microsoft Foundation Classes - I still have nightmares), and later worked extensively with the massively useful and very nicely designed Metrowerks PowerPlant class library. I used to subscribe to the old C++ Report magazine and read them cover-to-cover. The best of these articles are still available if you can track down old copies of the books _C++ Gems_ and _More C++ Gems_. (One of the fascinating things to be learned from those articles is how practitioners discovered that the exception mechanism in C++ really could only _theoretically_ be made to ensure safe and easy error-handling and recovery, but in practice made it impossible, because the total state of the program and its resources had to be considered at every point in the program in which an exception could occur; at one job, I tried unsuccessfully to convince my co-workers not to use exceptions for error-handling in embedded multi-threaded client/server code in vehicle infotainment devices.)

I have owned every edition of Stroustrup's _The C++ Programming Language_ and read his _The Design and Evolution of C++_. I used to buy, print out, and bind, copies of the C and C++ standards so that I could try to answer hard questions about whether compilers were broken, or the code was broken. If I had kept every book I've ever owned on C++ programming, I estimate it would be about 12 feet of shelf space. It is probably a blessing that I have only kept about 2 feet, which now has books on C++17 and C++20 for those times when I have to read some modern C++. At one point (about 1999) I considered myself to be a pretty expert C++ programmer, but because of language churn, those days are gone. (How many times can one re-learn the proper way to write a managed pointer class, or what methods should go into a "standard" kind of class to make it useful and safe? For me, the turning point probably came when I bought a brand new book on STL programming and tried to run the chapter 1 examples. Every compiler I had access to at the time on several platforms crashed when trying to compile the programs, which was a really vivid illustration of just how far the cutting edge was from the reality of working programmers.) I also once went to a talk by Stroustrup on the campus of the University of Michigan, and left frustrated and bored.

Given all that, I don't believe Stroustrup's ever been quite the thinker and visionary that some might think he is. He will not be remembered as a great language designer but more a formalizer, implementer, and promoter of ideas mainly borrowed from other languages and other people. He's certainly not a great writer or a great speaker, as I learned at his talk.

That itself is not my real criticism of him and his work; there are a lot of great ideas in language design to borrow from. My real criticism of him and his work is that along the way he has not been able to maintain a coherent vision of how language features would work together in real programs. To be fair to him, I think a lot of the people behind incredibly useful and active real-world computer languages such as Guido van Rossum and Yukihiro Matsumoto find themselves in similar positions, but Stroustrup seems to have a particular lack of self-awareness of the limits of his contributions and role in the design and evolution of a language which is now an irredeemable mess filled with too many Ph.D. theses. C++'s metastatic growth began with the early incorporation of Stepanov's Standard Template Library, a very nice design that, initially at least, was grafted into a language not well-suited to implement it. And things have continued from there, with massive, widespread adoption, and many successful projects, but insufficient attention paid to the unsuccessful ones. Meanwhile I have watched so many better languages fail to gain momentum. People choosing languages for implementing important pieces of software would be wise to look at the minority reports of the most experienced engineers - for example, see Torvalds' comments on C++ over the years - rather than the propaganda from the language promoters.

It kinda depends... my purposes have changed a lot over the years! So here are a couple of instances where computers were underpowered/powerful enough for my purposes.

My TRS-80 model 1 did not have enough memory (4K). Writing early BASIC programs like a program to maintain D&D character stats, I very quickly ran out of space. When I upgraded it to 16K it was adequate as far as RAM. Cassette storage reliability was another issue entirely - none of my old programs have survived.

My college roommate's 512K Mac was way too painful to copy files between floppies - you had to swap them at least a dozen times. It became difficult to manage files and back them up. My later Mac SE was a lot more usable once it had an internal drive.

My PowerBook Duo 230 was surprisingly adequate for writing and programming especially when I started using a magneto-optical drive to back things up.

My later PowerBook G4 was inadequate for audio stuff - I was trying to record podcasts and mix things. I had endless trouble getting a clean recording with an extern USB microphone or headset and mixing audio really strained my hard drive space.

Wi-fi bandwidth was not adequate for what I was trying to do, about 2006 through 2012 or so - I was not able to serve my iTunes library to a different machine across Wi-Fi, and have that different machine stream the audio to an AirPort Express to listen to, without breaking up or stuttering. It's still tricky to get this to work even with much faster Wi-Fi with a 7th generation iPod Touch, although it works great with a recent iPad.

A very old Intel Mac Mini was not really adequate for recording and mixing my podcast projects although it worked better than the the G4.

My 2008 Mac Pro was great for all my video and audio projects with added RAM and 4 internal drives. It's still my workhorse machine for my big e-mail archive and producing podcasts.

I am using several little Intel NUC machines, i3 and i5. They are surprisingly fast. I use one as a headless build server for personal projects using VSCode. My kids use a couple of them for gaming even though they have pretty minimal GPUs. But they work just fine for a lot of games, especially games that are a few years older.

My M2 MacBook Air is shockingly powerful enough for anything that doesn't require a huge amount of storage, so it's my new workhorse for writing, programming, Logic Pro mixes, etc. I can even generate Stable Diffusion images on it. The big archive of projects lives on a Synology now. The battery life is finally long enough!

I'm planning at some point to replace the 2008 Mac Pro with a machine set up specifically for video projects. It might be a new Mac Mini...

Since getting into embedded firmware, I've had to write some very "critical" pieces of low-level code, often very low-level.

For example, I took over a piece of code that ran on a DSP on an audio card. This code handled PCI bus transfers and I needed to change the shot size and optimize it - a lot. So, parts became Motorola DSP assembly language. I had to find a lot of tricks, using unused bits in wide registers as cycling counters, fun stuff like that. But I got it working and it became very reliable.

I've written low-level code for other DSPs, particularly code that handles audio mixing, does filtering and sample-rate conversion, and things like that.

I also have written low-level driver code for various embedded processors in C, including code that drives SPI peripherals.

One of the more interesting challenges is writing driver code that allows writing to on-chip flash memory. The code is executing right out of flash memory, but then you need to program pages from a write buffer into the same flash memory. To do this you have to jump to a function that is guaranteed to be in RAM, change the chip configuration such that the memory mapping behaves differently, write the page, put the chip configuration back to normal, and then continue executing the out of flash.

Other fun "critical" code includes bootloaders that upload a new version of the firmware, and it's interesting what they have to do, to then start executing the firmware. They have to stop interrupts including clocks, set some critical registers, and then NOT re-enable interrupts, but take a "soft reset" and launch the new program, which then will re-enable interrupts after it gets itself set up.

I really enjoy this kind of low-level stuff, which I guess makes me an outlier, but on the other hand it's been good for my career to carve out a niche doing stuff that a lot of people don't want to do.

Oh - for a slightly different definition of "critical," I've also been employed writing test code for medical devices (and found bugs in medical device firmware this way).

Don't try to buy all your books at once. Purchase them over time as your tastes evolve and you discover what you like.

That said, if you want to start out with a very nice set of "classics" to dive into, consider getting a set of the Harvard Classics. I've got a very nice set that I picked up for a couple hundred. There are several editions. For example, on eBay: https://www.ebay.com/itm/The-Harvard-Classics-1980-Collector...

You might also consider Brittanica's Great Books of the Western World. I don't have a set of these yet, but would like to get one, at some point. Again, there are several editions, but you can pick up an older one within your price range: https://www.ebay.com/itm/Britannica-Great-Books-of-the-Weste...

If you mean _classic_ classics, as in the classical Greek and Latin canon, search eBay for "Loeb Classical Library lot." Those will definitely give you some challenging works to sink your teeth into.

Get a subscription to the Library of America and get great writing by American authors for $30.90 per volume delivered according to whatever schedule you want. The books are very nice small boxed hardcovers. I've got almost 100 now.

If you like things a little flashier and don't mind trade paperbacks, I recommend the Penguin Classics Deluxe Edition trade paperbacks. https://www.penguinrandomhouse.com/series/254/penguin-classi...

I read and collect books from the New York Review Books Classics series. It's an amazing series of reprints of mostly 20th Century literature, some that has fallen unjustly into obscurity, and a lot of it in translation.

I also pick up used sets from the Folio Society, for example Orwell's "Reportage" boxed set: https://www.ebay.com/itm/GEORGE-ORWELL-REPORTAGE-5-VOLUMES-I... which is a very nice edition that I love to hold in my hands and read. Watch prices for a while and get a sense for them, save some searches, then jump on one when an exceptional deal pops up.

Your library should reflect your mind and personality as it grows and develops over time!

"Keeping up with your brain" is an underrated concept here. I used to type about 120 wpm, although that number has come down a lot over the years due to carpal tunnel syndrome and tendonitis. But I still think it's important that I can type out code almost as fast as I can think it up. It's important that I not have to think much about getting the idea drafted, because this gives me a lot more time to clean it up and revise it. It's like I have a chance to write and test several revisions of my code in the time it would take a very slow typist just to key in the code once. I have worked with hunt-and-peck programmers and it is painful to watch them work.

So, what's the title for a person with 43 years of experience programming computers - not just GUIs, applications, or programs, but whole systems, comprising tens or hundreds of thousands of lines of code across several platforms and languages, and that often include writing specs, designing protocols, drawing UML sequence diagrams and state machine diagrams, memory maps, writing documentation, assembly procedures, and sometimes marketing materials?

How about when my work includes reading datasheets and writing low-level drivers, designing and implementing bootloaders, designing schematics, laying out PCBs and ordering PCBs, and then soldering together the prototype boards I designed, and testing my code not just with IDEs and debuggers but with voltmeters and oscilloscopes and logic analyzers?

Serious question -- I don't actually have an engineering degree and so agree that I'm not qualified to use the title "Engineer." But what's the job title that conveys what I do?

You can search for parts like this on Mouser:

https://www.mouser.com/Semiconductors/Switch-ICs/Multiplexer...

This one seems to be "dual" - there are two sets of control pins. I'm not sure from your description if that is exactly what you are looking for, though.

Yes, an antibody test (a blood test) can do it. A swab test looking for the virus in your saliva probably wouldn't find any.

I implemented a streaming deserializer for MessagePack data in C for small microcontrollers. It is quite small and not complete.

Then I tested it with test data streams generated by the reference C++ implementation and Python implementation.

It's actually kind of a pain, because the C++ serializer generates a variety of different data types depending on the values you are packing, not the type of the values you are packing. Let's say I encode a uint32_t field. The stream might get a uint8, a uint16, a uint32, or even an int32 (for reasons that completely elude me).

Also, C++ strings come out as the 'ext' type while Python strings come out as the 'string' type, so I have to accommodate both, even though they are both basically byte strings.

So, I want to tell the deserializer what kind of output field I'm expecting, for each struct member or array, and then look in the data stream to see if there is a data object there that came from the same type. But this is impossible, so the per-type decode functions have to be quite complicated to handle a variety of types.

So - it works but I can't do much on the deserialization side to verify that the data I'm unpacking really matches what was encoded. I can only detect very broken cases, like when I'm unpacking a uint32_t and in the stream there is an int32_t with a negative value.

I guess this is mostly done for optimization, but two things would make it a lot better:

- if the spec actually specified how data types in different languages were allowed to be encoded

- if the encoded data contained _two_ type fields, one indicating the original source data type and another indicating the type it was encoded into.

Basically the spec is just way too "loose" to make it usable for the use case I'm trying to use it for, which is to easily generate data that is sent to a micro and stored in EEPROM, then deserialized out of EEPROM later.

That's probably not very close to a use case the original designer had in mind. But I haven't found anything that works better (less decode logic).

My main computer is a 2008 Mac Pro.

If the phone is accidentally left off the hook (or if there is an electrical problem with the wiring so that it is _reading_ as off the hook), the exchange may drive it with a very loud fast BEEP-BEEP-BEEP-BEEP sound. That's just part of how POTS (plain old telephone service) lines work. Traditionally a user would not want to leave the phone off the hook accidentally, because then that line could not receive calls, and if it was a party line, no one else on the line could receive calls or make calls.

If it stays off-hook long enough, eventually this will go silent.

See: https://en.wikipedia.org/wiki/Off-hook_tone

And: https://en.wikipedia.org/wiki/Permanent_signal

"It's not the fault of this horrible product, it's simply that no one should have been stupid enough to trust it and go on vacation!"

Yes, by the standards of most employers and schools it is very late. I am fortunate in that I can often sleep until past 8, and I'm much saner and healthier for it. But all through high school I had to get up at 6:30. Since I was _also_ an extreme night owl and used to do all my schoolwork after everyone else in my house was asleep, I'd usually get to bed by 1:30 or 2:00, which meant I was severely sleep-deprived all through high school.

I've had to take various contract gigs where I had to start my commute at 7, or be at meetings that started at 7, and it's terrible. Employment arrangements like this wind up getting a version of me that is at my lowest, least-focused, least-productive ebb, no matter how much coffee I pour down my gullet.

These days I still get my best, most focused programming work done between about 4:30 p.m. and 8:30 p.m. It's a constant strain because it means my time at home with my family is foreshortened every single weeknight.

Good analysis. Didn't Knuth famously say that his job was to get to the bottom of things, not to stay on top of things?

If I were writing a one-off program to do this once for a paid project, the shell script is absolutely the way I would go about it.

If I were writing it as a computer scientist, accustomed to teaching students how to find optimal solutions, something like the Knuth program is absolutely the way I would go about it (although in 2020, I would likely use C, not Pascal). I also would likely roll my own approach if I was writing it for the kind of target machine I work on now - a very small one (an embedded microcontroller). And Knuth made his bones when computers were (physically) huge but (in memory and speed) tiny.

Howdy Walter! I'm Paul R. Potts. You were very generous with your time answering my endless questions about how NewtonScript worked under the hood back in the day, and I still remember that. It got me into Scheme, Dylan, Common Lisp, and basically widened my world view a lot, and led to me doing several different projects in the nineties with embedded interpreters (Kawa under Java, etc.) These days I am a senior embedded developer. You described Landon Dyer as a "very careful programmer" for the way he wrote the flash card drivers, and I still remember that, and try to apply that to drivers for SPI, EEPROM devices, DACs, and ADCs.

Anyway not really a question... just glad to hear you are still around and kicking and thanks for the inspiration!

I am a leftist whose exact ideology is a work in progress, but I'd generally call myself an anarchist in favor of localized gift economies, food production, and devolved government, so distributism and worker-owned collectives are both things I'm very interested in.

I work mainly in embedded development and I'm not really sold on blockchain or IoT or, really, using TCP/IP for much of anything. My recent paid work involves control systems on small microcontrollers, either using FreeRTOS or that are so small they use no OS. I'm interested in building driver stacks on these chips for writing things like bootloaders and serial interfaces that support remote control commands.

I also have a little bit of PCB design experience, although I'm not trained as an EE. So, I have no idea if my skills might be of use, but I've been thinking of how to apply some of my work to future open-source hardware devices. I keep coming back to how some of this might be useful for fully open voting machines, and I know everyone jumps to thinking about blockchain for that, but I think it is overkill and too heavyweight for what I want to do. I'm thinking more of writing data to redundant EEPROMs and verifying it with something older and simpler like message digests or digital signatures.

I realize that maybe there's not a lot of overlap there but I guess if you need any low-level drivers I might be able to help...

Well, sort of.

Specifically, printf is an oddball function because it uses the varargs mechanism, and the whole format strings mechanism is inherently risky because it effectively bypasses the type system and says "trust me." Back when I was learning C, on a Mac with THINK C, misusing printf was a sure-fire way to crash the computer very quickly, especially since misaligned accesses of 16-bit or 32-bit words caused crashes. Compilers now go to a great deal of trouble to try to do additional safety and consistency checks.

Don't get my wrong, I grew up using printf, and it is massively useful. But it was designed when computers were much smaller and simpler, and design tradeoffs were made back then that probably wouldn't be chosen today. So printf, along with a whole family of related functions, has been a seething mess of a security and safety hole longer than most programmers have been alive.

This is terrific. My own personal C coding standard has evolved over the last few years to include quite a bit of "useless" whitespace including vertical space. I'm no longer coding on an 80x24 terminal or something like that, so why force myself to continue to code as if I was?

I've been using Macs since 1985 and I've owned several, going back to the SE, PowerBook Duo 230, PowerBook G4, and 2008 Mac Pro, which is still my basic workhorse machine. I've also done a lot of development for "classic" MacOS, MacOS X including applications and audio drivers, and the deceased Newton platform.

As far as I'm concerned, the usability of MacOS X peaked with Snow Leopard. That was an amazingly reliable build. My uptime was months and months without shutting down or crashing. With that build, I recorded and mixed a number of songs from scratch, with Logic Pro X. I imported and edited a number of videos. And I scanned and edited hundreds of photos with Photoshop and Aperture. I also could still run some vintage applications.

In my opinion, just about every update of MacOS X since then has made it dumber and less usable. I loved the "vision" of what the Mac could be back then - a "digital hub" to organize, create, and edit things from my other devices.

The ongoing attempts to push me and all my content into the cloud and turn everything into a scheme to extort money from me monthly is not something I've ever liked or wanted to participate in.

I am impressed by the hardware design of the new Mac Pro, but it clearly isn't aimed at me. I think I paid $4,000 for my 2008 Mac Pro, with the beautiful monitor that still works. But the new Mac Pro has gone up in price far more than inflation would justify.

I've gradually moved much of my regular writing work to a series of semi-disposable new and used laptops running either Ubuntu MATE or Windows 10 and all open-source workflow (NotePad++ instead of BBEdit, my favorite editor, and Pandoc). I'm not sure what I'm going to do with my music production, Aperture, and iTunes libraries. It's frustrating.

>You could get pretty far by reading scripts and trying things out in Hypercard.

I think that's true - but my experience was that it was a good language for beginners, but didn't "scale" well as you started working on more complex programs. The English-like syntax could get in the way as soon as you started to assemble more complex expressions, and you'd be left hunting for the right syntax as if you were playing an old Infocom game. It gave the impression that the parser was more accommodating and sophisticated than it really was, when really it had a rigid syntax like most other programming languages. And because most of the documentation was aimed at beginners, it was hard to find clear answers about _exactly_ what the syntax had to look like when assembling those more complex expressions. It has been a long time since I was writing HyperTalk, but I remember being very frustrated that I couldn't find a formal language spec (in BNF or a bubble diagram or something) the way I could for languages like Pascal.

Still, it really should get a lot of credit for encouraging a lot of beginners to write code and build quite sophisticated little databases complete with all kinds of animations and visual effects that would have been monstrously difficult to code from scratch in C or Pascal. I should also remember that as a programmer and Computer Science student, _I was not the real target audience_ for the language design.

>Are you the Paul who worked at Computerland?

No, but I wrote a couple of articles on how to write XCMDs/XFCNs for the Washington Apple Pi Journal, then also some stuff for MacTutor. I was a student at the College of Wooster then (in Ohio) so I never actually _went_ to a WAP meeting... but my roommate Ken Knight was from the DC area.

Really disappointed that I couldn't get the pigs to jump across the floating platforms. Maybe I didn't do it right?

All very true - I also wrote XCMD/XFCN plug-ins back in the day, and my first published technical articles, in MacTutor and Washington Apple Pi magazine, were about how to do that.

HyperCard had more innovations that I miss. One of them was the ability to paint on the card background and foreground layers separately. This meant that you could cover black pixels in the background with white pixels in the foreground.

The HyperTalk language was kind of an oddball, quirky mess; it was designed to closely resemble English, but this actually tended to make it harder to come up with just the right syntax to do what you wanted. But that object-oriented model was carried over into AppleScript, and the whole scripting model for writing scriptable applications. It was not exactly easy to write code that would follow the OSA scripting model, but applications that supported it could be "puppeted" to do some amazing stuff. For example, I wrote a C++ program in PowerPlant which would "puppet" Quark XPress to generate customized newsletters.

Atkinson deserves a lot of credit for making a 68000 do things people could barely believe could be done without custom graphics hardware, and his whole region model (described in a patent) is amazing. And you can now browse the source code for MacPaint and QuickDraw: https://computerhistory.org/blog/macpaint-and-quickdraw-sour...

It's not really legible if you don't have some expertise in 68000 assembly language, but even if you don't, it's still a model of clarity and an inspiration.

I still use this method, except I lean towards very large binder clips and several stacks of cards (work, personal general, personal writing project). I keep piles of blank cards on my desks at home and work and I stock up when they are BOGO or on closeout. The key is to have so many on hand that you have absolutely no mental barrier to using them up or recycling them.

The main things I like about it: I generally have a pen around so it's very easy to add a note without fumbling around for any more window real estate on my computer. I can review/purge/recycle stuff in a diner or cafe over coffee without using a laptop. If I spill coffee on it, it doesn't matter. And it feels good when I can recycle a card because the work it represents is either finished or now unnecessary. Also, I don't have to worry about being unable to look something up or organize some tasks if a battery goes dead.

Ah yes, the first video game I had ever tried that I simply _could not play_ because after just a few seconds, it made me feel like I was going to throw up. To put that in perspective, I had been a big fan of many previous 3-D games, including Doom.

Cool game if your stomach will tolerate it, though!