pt == point, r == rect, h, v == horizontal, vertical, BSR(...,1) is a fast integer divide by 2, ORD4 promotes an expression to an unsigned 4 byte integer

The algorithms are extremely common for 2D graphics programming. The first is to find the center of a 2D rectangle, the second offsets a point by half the size, the third clips a point to be in the range of a rectangle, and so on.

Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case.

(Mac Pascal didn't have macros or inline expressions, so inline expressions like this were the way to go for performance.)

It's like using i,j,k for loop indexes, or x,y,z for graphics axis.

Also, breaking things down to more atomic functions wasn't the best idea for performance-sensitive things in those days, as compilers were not as good about knowing when to inline and not: compiler capabilities are a lot better today than they were 35 years ago...

For clarity and to demonstrate, this is basically what this function is doing, but in css:

.container {

  position: relative;

.obj {

  position: absolute;

  left: 50%;

  top: 50%;

  transform: translate(-50%, -50%);


}

Because it's quite clear, everything is well named, and the filename also gives the context.

ORD4 = cast as 32bit integer.

BSR(x,1) simply meant x divided by 2. This is very comment coding idom back in those days when Compiler don't do any optimization and bitwise-shift is much faster than division.

The snippet in C would be:

    pt.h = (r.left + (int32_t)r.right) / 2;
    pt.v = (r.top + (int32_t)r.bottom) / 2;

    pt.h -= (width / 2);
    pt.v -= (height / 2);
  
    pt.h = max(0, min(pt.h, fDoc.fCols - width));
    pt.v = max(0, min(pt.v, fDoc.fRows - height));
  
    if (width > fDoc.fCols) {
      pt.h -= (width - fDoc.fCols - 1) / 2;
    }
  
    if (height > fDoc.fRows) {
      pt.v -= (height - fDoc.fRows - 1) / 2;
    }

I'm sure the code would be immediately obvious to anyone who would be working on it at the time.

Comments aren't unnecessary, they can be very helpful, but they also come with a high maintenance cost that should be considered when using them. They are a long-term maintenance liability because by design the compiler ignores them so its very easy to change/refactor code and miss changing a comment and then having the comment be misleading or just plain wrong.

These days one could make some sort of case (though I wouldn't entirely buy it, yet) that an LLM-based linter could be used to make sure comments do not get disconnected from the code they are documenting, but in 1990? not so much.

Would I have used longer variable names for slightly more clarity? Today, sure. In 1990, probably not. Temporal context is important and compilers/editors/etc have come a long way since then.

Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion. It’s an excuse to name things poorly, because “good comment.” The purpose of variables should be in their name, including units if it’s a measurement. Parameters and return values should only be documented when not obvious from the name or type—for example, if you’re returning something like a generic Pair, especially if left and right have the same type. We’d been living with decades of autocomplete, you don’t need to make variables be short to type.

The problem with AI-generated code is that the myth that good code is thoroughly commented code is so pervasive, that the default output mode for generated code is to comment every darn line it generates. After all, in software education, they don’t deduct points for needless comments, and students think their code is now better w/ the comments, because they almost never teach writing good code. Usually you get kudos for extensive comments. And then you throw away your work. Computer science field is littered with math-formula-influenced space-saving one or two letter identifiers, barely with any recognizable semantic meaning.

Edit: Disappointed is really not the right word but I am failing at finding the right word.

And, for purity/completeness, avoid Maxx Desktop and/or NSCDE; EMWM with XMToolbar it's close enough to SGI's Irix desktop.

https://fastestcode.org/emwm.html

It nailed it, first try.

I cannot, unfortunately, share a link to the website it created because of the license.

LLM translations of historical software to modern platforms is a solved problem. Try it, you'll see.

I used https://exe.dev/ and their Shelley agent to drive Claude. Give it a try, it is jaw dropping.

They weren’t like textbooks, which have knowledge that tends to be relevant for decades. You’d get a new set with every software release, making the last 5-20 lbs of manuals obsolete.

You did lose some of the readability of an actual book. Hard-copy manuals were better for that. But for most software manuals, I did more “look up how to do this thing” than reading straight through. And with a pdf on a CD you had much better search capabilities. Before that you’d have to rely on the ToC, the book index and your own notes. For many manuals, the index wasn’t great. Full text search was a definite step up.

Even the good ones, like the 1980s IBM 2-ring binder manuals, which had good indexes, were a pain to deal with and couldn’t functionally match a PDF or text file on a CD for searchability.

You might expect now and again to get some optional updates/patches later, but that was rare - and rarer still for most people to even know about them.

These days, software is never complete. Nothing is done. It's just a point-in-time state with a laundry list of bugs and TODOs that just roll out whenever. The software is just whatever git tag we're pointing to today.

I understand how/why it has become like this - but it still makes me sad.

Back in time, black were ordinary, and only white/grey ones were for licensed software, thus more desirable.

https://computerhistory.org/wp-content/uploads/2019/08/photo...

Whereas Photoshop and other "mainstream" software use terms and procedures non-programmers are more likely to be familiar with: heal this area with a patch, clone something with a clone stamp, scissors/lasso to cut something out (not saying GIMP doesn't have those)...

Unfortunately, designers are rare among the FOSS community. You can't attract real casual or professional users if you don't recognize the value of professional UI/UX.

> To change GIMP to single-window mode (merging panels into one window), go to "Windows" in the top menu and select or check "Single-Window Mode"; this merges all elements like the Toolbox, Layers, and History into one unified view.

could you please show me a good textting tool plugin for GIMP, then?

you can check their forums & other sites: the textingtools is on top of their discussion lists?