18 years now, maybe longer, but it still turns on and has yet to burn out. Of course, we don't use it much, and it's only something like 30 watts (clear bulb).

Someday, maybe, it'll get replaced.

So you end up with accumulators called "A" and "B", but are composed of registers "AX" and "AY", and "BX" and "BY", with each being one byte (or word) wide; X and Y being high and low bytes/words of the register (and dependent on "endian-ess" too).

Sometimes you even get where multiple registers can be referenced by a singular name - "D" is a popular choice, and may be made up of "A" and "B" (being low/high "registers" of the larger word). IIRC, the 6809 was like this (?) - A and B were 16 bit registers, but could be referenced as a 32-bit word "D" (or maybe I am thing of the 68k or some other architecture - it's been a long while).

The only other time I have ever seen singular letters used for registers in assembly was for very old pre-microcomputer systems (beasts like the Univac and System/360 - though I think the PDP-8 had similar style). Also some of the very early "microcontrollers" (which were more like glorified sequencers with some extra memory and rudimentary branching, if any) had similar "registers" (Radio Shack once sold, as a part of their "Science Fair" electronic kits, a "Microcomputer Trainer" that was something like a very small 4-bit microcontroller with 128 bytes of memory or something like that - to teach assembler and a bit of hardware interfacing - it had "small" registers like that referred to in single letters).

I found the system to be easy to use, and relatively high performance. The only thing that was an issue - at the time - was something very strange, which kinda impacted another app we were building:

Corona had a map component, for google maps - but for some reason, it wouldn't work for Android - only for iOS! So - you could create an app with that component, but if you compiled it to install on Android, it would fail, but you could compile it for iOS and load it on an iphone and it would work fine.

At the time, we had an app idea from a client that we wanted to use Corona for, but because it needed mapping, and that didn't work, we were forced to go with another option (PhoneGap and Bootstrap Mobile), that wasn't nearly as performant - but we could embed a google map easily.

Contact with Corona revealed they were working on a fix to get the map component to work with Android, but it came too late for our purposes (and actually didn't happen until about a year or so after I had left that position and had moved on).

Anyhow - I'm glad that the system will live on, although today there are a ton of other options available for easy cross-platform mobile development. Still, I haven't found anything that worked quite as well as Corona.

It was all web-based - we even had a version for "mobile" (at the time which meant a ipaq personal assistant, running a version of Windows CE and a browser that made IE6 look sane).

The idea behind it was "patient-centricity"; the patient could manage, view, and "edit" their own healthcare records, and any physician on the system could have access to that patient's records (the patient would have to give approval to share with the provider).

It wasn't ever going to replace EPIC or any of the other large medical record systems, but the fact that a patient could control their own data was a significant part of the core marketing behind it - provided you could get other providers and support people on-board.

Things were going rather smoothly (but not very quickly) in the progress of the development of this app, until the client wanted to make the entire thing HIPAA compliant. At the time, this meant taking it off our in-house shared hosting environment, and get it on something else. What we found was, at the time the only option was to lease a full rack from Rackspace and use their services (and servers), as they were (supposedly) fully HIPAA compliant.

The client balked at the cost to implement such a system, and instead opted to roll their own. Then the client decided to hire their own developer (without telling us), and wanted us to backdate some HIPAA "compliancy documents" to say their system was fully compliant on a date when it wasn't. My employer thankfully decided not to go down that road, and instead to drop the client and contract (probably the best decision he ever made).

Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision...

When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner.

They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business.

So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department).

Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then.

As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done.

Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.

However, due to their entrenchment in various other markets (and who knows if there is any graft or other under-the-table business going on), they continue to manage to exist, and scary enough sell their products to new victims (ahem - customers).

SAP is the old-is-new-again-we're-IBM type of business; nobody ever got fired for buying SAP (but the golden parachute was nice)?

Ok - hyperbole and I don't really know what I'm talking about, so the above should probably be ignored...

...that said - I don't think I'm too far off, either.

Unless it's something that would cause an error due to memory/register size constraints, or cause the calculator to sit there forever on some of the other larger squares or test values due to 1986 speed of the ALU or whatever is in the calc?

My gut assumption is that it's some mathematics inside joke of some sort...

I'd argue that it changed once smaller businesses could afford (and have room for) their own computer. My best guess would be somewhere around the PDP-8 era (late 1960s-early 1970s).

Once things started to move away from large-scale computer rooms and consoles of blinking lights, towards a more "hands-on" and interactive approach, where the programmer didn't have to wait between "batches" of runs to see what their code did (correct or not), that is when (from a software development point of view) so-called "engineering" went out the window.

https://www.smiffy.de/dbkda-2018/

Were you not around for newsgroup flame-wars of the early 90s (and probably long before that, if you were among the lucky few that had access)...?

Twitter has a hard, small limit. Most other platforms either have no limit, or the limit is fairly large.

The problem is, people don't use it.

Worse, those that do use it are ridiculed, or their words are ignored (TL;DR anyone?)...

Thinking about this, I wonder if any of it has to do with people's "inner monologue" that was discussed yesterday here on HN? If you didn't see it, the gist was that there are some people who don't have such a monologue, and it came as a surprise to one person. Similarly, those without such a monologue are often surprised that others have it; one person commented that they often wished that the voiceover of characters in a movie, expressing their inner thoughts, was a real thing - and were shocked to find out that for most people - it is!

Anyhow - does this play into how people write online? Do they tend to write less or smaller messages, because their inner monologue is too loud or constant? Do those without such monologue write more thoughtful and longer posts? Then I think of myself; I have an inner monologue, but I tend to write long things (case in point - this post?) - but I don't find my inner monologue a burden.

But some do - I know I have read of people who either must always have some noise around them to drown out their "inner monologue", or if left in silence, even for small moments, will declare themselves "bored", perhaps because their inner monologue isn't perceived as interesting (whereas I and others have no problems thinking and pondering things, in silence, with no boredom)...?

Does this effect how people compose and type their messages? Does it help or hinder understanding? Does it facilitate or does it block meaningful conversations?

Twitter may have tapped into something that was always there to begin with, and in essence has helped foster that communication style - making it acceptable widely - conversation as "sound bites" - which has perhaps led to our present situation.

https://en.wikipedia.org/wiki/FCC_fairness_doctrine

"The fairness doctrine had two basic elements: It required broadcasters to devote some of their airtime to discussing controversial matters of public interest, and to air contrasting views regarding those matters."

This doctrine was eliminated in 1987, after a series of lawsuits about it.

Arguably, it's part of what started this whole mess we now find ourselves a part of.

I noted in another comment that they have a similar problem with people wanting VB6 open sourced, because so many businesses rely on VB6 apps - some written internally or exclusively for their business.

Windows 10 (from what I remember) almost didn't support VB6, but in the end they included the runtime DLL to allow for the apps to work. I wonder if this is a part of the 32x thing? Seems a likely possibility...

VB6 and the companies relying on it might be an albatross around Microsoft's neck; for how much longer, I'm not sure.

Instead, Microsoft has been virtually forced to continue to include the VB runtime DLL in every version of Windows since, because there are so many businesses out there that rely on software developed in VB6 that can't (easily or cheaply) switch to something else.

Windows 10, from what I understand, almost became the first version to ship without it, but Microsoft relented under the pressure (maybe I'm misinformed here, though).

VB.NET is sufficiently different enough that conversion either isn't possible, or due to the source code not being available (or the 3rd-party company that wrote it not existing any longer as an entity - or the source code assets not available or whatnot due to dissolution) - conversion becomes nearly impossible, short of a very expensive reverse-engineering effort by another 3rd party.

I believe that people aren't ever going to trust self-driving cars, unless they are "perfect". Even ten 9s of reliability (no driving errors or accidents) would probably be too imperfect for people to accept (and I don't believe humans have ever made anything that close to perfection).

I believe the reason this is probably so has to do with assignment of blame and guilt. Something easily done with human drivers, less so (or maybe impossible) for self-driving vehicles.