whartung

I always thought the essential feature of an emacs was its extensibility. I never felt that emacs was just a collection of keybinds and split buffer windows.

Note, I'm not talking about Lisp per se, just some kind of mechanic within the editor to allow the user to make extensions to it.

Oh, absolutely.

First, they're more granular. Segment represents 16 byte blocks, most banking systems had 4K blocks.

Second, the segments can overlap. The most basic example is the Tiny model where CS and DS are identical. 64K of shared code and data. Separate them, and you can have 64K of code and 64K of data with almost no code changes. (The Small memory model).

Third, you can move memory between segments. With banks, the typical setup if you wanted to move data from Bank A to Bank B, you had to move it out of Bank A, enable Bank B, and then move it back in. Obviously with more sophisticated banking architecture, you can do whatever you want. Eventually you creep into more of a MMU logic than simple banking.

Finally, somewhat related to the previous, you have the ES, Extra Segment. While more limited than the CS/DS in terms of capability, it was enough to let you shove things around without having to clobber your CS/DS if you didn't want to. Saved a bit of juggling there.

Regarding the part about code spanning, yeah, that's an issue in terms of continuity. You simply couldn't have code that was larger than 64K, the PC will wrap on the CS.

But, you had direct support for "far pointers". You could "Jump" to SSSS:XXXX, storing the entirety of the pointer, and do a far jump directly. The jump resets the CS for you. You can't do that with a banked system. You're responsible for banking things in at the right time. So, if you commit to far pointers for all of your function calls, the code just links and it "just works" without you having to do anything manually.

More expensive of course, so folks would make internal little worlds of code and data and contextually bounce between them. But you have the option of not having to do that if you didn't want to.

The superpower of the PC over the previous generation was an order of magnitude more memory.

The machine itself was not necessarily faster, but the extra memory was a real game changer.

Even segmented like on the 8086 was a better solution than the banking options on 8 bit hardware. The ‘86 segment registers were much more flexible.

Long term, 640k may not have been enough, but in a text based environment, 640k is just so much more from both a data and code aspect to be really empowering.

256k and Lotus 1-2-3 was much more capable than anything an Apple could do. Having much more room for more capable code aspect as well as richer and more data.

You could do gymnastics with code overlays and data paging, but that was hard software to write and just painfully slow.

Extra memory just made things that much better.

At a glance, the string templating system they were trying out looked pretty good to me.

And clearly a lot of work and time went into it with the previews.

The fact that they pulled it back suggests they looked down deep into an abyss that looked back at them, and what they saw scared them.

I don't know if there has been a published deep dive post mortem on the whole string templating thing, but I am quite comfortable with the team yanking it out if they felt it wasn't right.

This is beautiful.

We used to feed the ducks at the lake in the park.

We bought poultry food at the local tack and feed store.

There were dozens of them. When they got spooked and all started flying, the breeze was notable.

Park eventually put in a sign to stop feeding them and took out the benches.

FORTRAN was a very important language for me.

Growing up on early micros, with BASIC, my father had Fortran for the TRS-80.

I took a stab at learning it, but the documentation was reference for calling the compiler, not so much learning the language. And when I found a FORTRAN book, it was quite dated and talking about things like tapes and punches and what not.

So, that effort stalled.

But, my first quarter in college, I took a FORTRAN (77) class. FORTRAN taught on the schools CDC Cyber mainframe.

This was quite a change from 8-bit PET BASIC.

But, most importantly, it was exposure to much of the same concept that an 8-bit computer has, but from a different tact.

This gave me more of a way to view things from a higher level, since I had to make them fit the two different views of how FORTRAN looked at things, how the Cyber presented things, and how BASIC and the PET were "same thing only different".

It also gave me access to a multi-user system, and all of the interesting capabilities it offers.

I remember when they put in their first lab of PCs, and how they started teaching folks Turbo Pascal on micro computers, and I just felt that the users were missing out on a bigger world. "Anyone" can access a PC or micro computer at home, but mainframe or multi user mini access, not so much. It's just a much bigger world out there, and we tend to baby duck what we first see.

Different world today, never had to use FORTRAN professionally, but I am most grateful for the experience of learning it and its environment. Very powerful medium for broader learning.

Also FORTRAN was the only notable computer thing I had "taught" to me (outside of my 20 minute introduction to BASIC by my high school teacher), pretty much everything else I self learned from books and such, even knowing the bulk of it before taking classes in school.

The reason 'i' was the first letter available was because by default identifiers starting with, I think, I-N were integers instead of float.

When I first started, with BASIC, my variable of choice was T simply because it was easy to type NEXT T in the FOR loops (why not R? I dunno...T just stuck).

No, the hot tip is to REA a patch to stop showing the ads, keep the rest.

Just tape your CC to the back of your phone, and your muscle memory will work the same.

It just reminds me of a cartoon in my head.

First pane has a supervisor, a plumber, and a robot, with the supervisor pointing to the robot.

Next pane is the robot watching the plumber work.

Next pane is the plumber watching the robot work.

Final pane is the robot with a bloody wrench standing over the dead plumber.

I dunno.

When it comes to back office business programming, there’s just a lot of code tasked with copying a litany of bits of data from one structure to another.

Whether it’s copying a web form into a database, or converting Their JSON to Your JSON, it’s a lot of detail that does not abstract well. It’s all shapes and sizes and formats, and it almost always has to be enumerated in excruciating detail and, typically, twice.

Sure, there’s logic and whatnot involved, but it, too, is specific to some subdomain of the larger system and it, too, does not abstract well. Not in the large context of the overall system.

Accounts Payable and Accounts Receivable, at 10,000 feet look almost identical. They’re almost literally the same thing with the sign flipped. But in practice, they don’t share code well. You end up with two similar systems, but not similar enough where sharing is actually worthwhile.

At best they can leverage a common API to the GL.

Turns out a lot of languages can manifest a decent level of abstraction. But even then, folks push back.

Consider the love/hate relationship with ORMs. Or the annotation driven markup in Java programs and the underlying “magic” that they enable. Like scribing mystic runes onto things.

Those are both very powerful, yet folks experience that and toss their hands in the air and throw out the baby with the bath water and jump into something “magic free” like Go.

Just because you can use something like CL to “make your own magic”, doesn’t mean it’s a good idea. Doesn’t mean it scales. Doesn’t mean it communicates well to others. AI or no.

It’s not the AIs world yet. We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own. I’ve already seen crass examples of “code only an AI could love”. Completely impenetrable, at least to me. May as well have represented it as a color image and collection of RGB values. Opaque to me, but the AI could “read” it.

There is much more to programming and systems than token density, and AI is still getting cheaper by the day, so less reason to even pre-optimize for it anyway.

I'm sure it helps to have some design sense, or something. Whatever it is, I don't have it.

Each time I've tried to get some Web UI going with the AIs, they all look terrible. They may work, but, they're terrible. I know they're terrible. I can't really express why they're terrible, just that I don't like them. So, I cannot really explain to the AI why they're bad so they can fix it.

Its just a blindness of mine that I've had forever.

To be fair, some of the stories he told me are horrific enough not to share, and its amazing that those weren't the issues that made him leave. They certainly could have had a cumulative effect.

There was one "gallows humor" story of an obviously fatal bicycle accident. As paramedics, they could not declare the victim dead. They had to have authorization from the hospital.

The hospital insisted they send the EKG data back.

They said "Ok", and rather than going through the effort of connecting up the victim, they just stuck the leads to the truck and said "here it comes".

Then they got the OK to declare there at the scene.

Friend of mine was an EMT, and he advanced on and became a paramedic.

The work seemed to suit him, he enjoyed it. I'd hang out with him at his base of operations (he was a private paramedic in LA County).

Then, one day, he quit.

He quit, and didn't renew his certification.

And he won't talk about it, and, boy, yea, did he have some stories.

But something got to him.

Folks like to cite how capability OSes are a great thing, and I certainly appreciate the concept, and, no, MacOS, is not a capability OS.

However, it feels like one to the User. Having to get constantly prompted to grant permissions they don't even necessarily understand to random programs.

There's been chatter about how system like iOS are not "document based", they're app based. Many apps do not present their data as "files", users don't know where their data resides, just that the app knows and that's their window.

I don't know where an application on MacOS can "save their files" if they don't have "Full Disk Access". I don't know if they get some directory "for free" that they can use much like iOS does.

Then, of course, there's the Apple Document model where data auto saves to Somewhere. You have versioned files you can work with. But until you actually "save" the file to "the disk", its living in some unannounced space. My TextEdit app has dozens of "Untitled-XX" files that are...somewhere.

And its great! There's a peace of just having "stacks of stuff" that you can leave "unmanaged". "Where would you like to save your work?" "Oh, great, cognitive load just exploded as need to think about the minutia of data organization, when, mostly I just "don't want to lose this".

But, the constant prompting is exhausting, to me. Again, I have to "think about it". I need to question everything, when I really just want to Get Stuff Done.

And, in time, we become blind to these prompts. "ok, Ok, OK!! GO ALREADY! JUST WORK!!".

Exhausting.