Adobe Photoshop 1.0 Source Code (1990)

That particular code is idiomatic to anyone who worked with 2D bitmap graphics in that era.

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.

As other comments have mentioned, context does matter, and as someone with a lot of 2D image/pixel processing experience, other than the 'BSR' and 'ORD4' items - which are clearly common in the codebase and in that era of computing, all that code makes perfect sense.

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...

This actually looks surprisingly straightforward for what the function is doing - certainly if you have domain context of image editing or document placement. You'll find it in a lot of UI code - this one uses bit shifts for efficiency but what it's doing is pretty straightforward.

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%);


}

BSR = bitwise right-shift

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;
    }

It’s not a myth, it’s a sound software engineering principle.

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.

The code's functionality is immediately obvious to me as someone who works a lot with graphics coordinate systems.

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.

Man I just don’t know who to believe, you or the Chief Scientist for Software Engineering at IBM research Almaden.

I was talking about more than just a literal port, running with it is broader than just a literal port. I guess my general point is that I am disappointed that all these releases of historical code have so little to show for being released.

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

It is open source but not free software.

Photoshop was ported to IRIX using Latitude, Quorum Software's implementation of Mac OS System 7. Apple later acquired the Quorum's code and it became part of Carbon.

If it uses Motif and IrisGL (now MESA3D) the amount of porting effort it's near NIL.

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

As an experiment, I gave the source zip file to Claude and told it to make a WASM version of the app, by translating the Pascal to Go.

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.

There are many things I feel nostalgic for in that era, but chunky manuals for specific software are at the bottom of that list.

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.

Also, you were far more likely to get actual documentation back in the day. You're never going to get a detailed first-party technical reference for today's Apple computers (at least not without being Big Enough and signing a mountain of NDAs); compare that to the Apple II having a full listing of the Monitor ROM, or the original IBM PC Technical Reference Manual.

Manuals like AutoCADs have certainly felt valuable https://i.ebayimg.com/images/g/Gm8AAeSwwIZowjzn/s-l1600.jpg It's not even complete, for instance the ADS manual is missing. It's also a bit more expensive with roughly 3700 USD in 1992.

Image.

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...

UML used to be a staple of job interviews.

This is just my personal experience, but even with the current UI, there can tend to be a learning curve with GIMP. Alot of it probably comes from figuring out where tools and functionality that are readily available upfront in other paint programs are hidden 2-3 menus deep in GIMP

That’s what happens when you let people do other people's jobs. UI/UX design is a profession, and there is a reason for that.

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.

I've never understood the negative comments around UX for GIMP. It always feels just fine for me. Some stuff is in menus, but its a complex application with a lot of parts so I understand that

Blender feels like an outlier amongst open source software. Outside of programmers tools the great majority of open source feels mediocre. I wonder what the Blender people did differently.

A simple trick to make GIMP perfectly usable (exists since ages):

> 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.

For texting I recommend using a mobile phone or desktop instant messaging program. While it's not the case with all of them, graphics editing tools tend to have texting utilities as a second-class citizen at best

Can you detail what you mean by good texting tool? What features are missing?

for the downvoters:

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?

FTFY: the funny thing with GIMP is: even while its a very powerful tool, it still lacks a good image editing tool until today

Nothing stops you from creating a PR :-)))