I think of it as a time when people became so entranced with the idea of the emerging object-oriented zeitgeist that they imagined that making things OO and component driven would just hand-wave towards success. People rushed to make infrastructure to support this model, and, well, it was no magic bullet. Complexity, fragility, and a lot of hard work remained.

the thing I'd like to see is for software to expose functional/"rest"-like interfaces. similar with websites and the content/user data.

if you look at what accessibility software achieves by simply looking at the screen/hooking into the OS, now imagine any and all software could be connected like that.

some of this functionality is now provided in individual silos, e.g. an email with an appointment in gmail can go into your Google calendar. a ticket from your train company can be added to Google wallet.

but if you look at a flight booking system and want to compare the total price of a given set of dates for travel, including hotel and other things at different times - you're back to doing it on paper (or use somebody's website where 20% of the flights or hotels you want aren't included).

> the thing I'd like to see is for software to expose functional/"rest"-like interfaces. similar with websites and the content/user data.

You mean, COM?

Office is probably the largest consumer-facing application to use COM today. It's honestly a great technology -- which came from the Cairo project.

You would have enjoyed AREXX IPC on the Amiga.

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

Isn't that the SmallTalk model, but everyone decided to use C++ instead?

Not everyone, IBM OS/2 SOM had support for Smalltalk, C and C++.

Smalltalk was OS/2's .NET, so to speak.

Unfortunately it all died alongside OS/2, followed by IBM's pivot to Java.

Java on the AS/400 is the weirdest thing. The whole platform was designed to be compile once to near assembly and then run cached byte code or whatever. Java is just too late compilation is clunky in comparison imo.

I believe Tribes 2 did something similar just at a higher level

TIMI is compiled at installation time usually, the bytecode format is used only as portable executable format.

While initially Java on AS/400 did take advantage of TIMI, IBM eventually moved away from it, into regular JVM design on now IBM i.

Most likely because IBM z doesn't use TIMI, rather language environments, and they want a more straight design, or due to Java dynamic capabilities using TIMI wasn't the best approach.

On AS/400 (IBM i), only Metal C, and the underlying kernel/firmware, written in a mix of PL.8, Modula-2 and C++, are pure native code.

> if you look at what accessibility software achieves by simply looking at the screen/hooking into the OS

Unfortunately that's kind of a pipe dream... in the real world, the first organization to flagrantly violate the OS vendor's human interface guidelines is the OS vendor itself, who ships some application with custom-schmustom, owner-drawn widgets that cannot be queried according to the standard OS APIs for querying them for content. So the accessibility software literally has to OCR the screen to determine what's written in the text fields and buttons.

Source: Knew a guy who worked on Dragon NaturallySpeaking, he had some war stories.

> now imagine any and all software could be connected like that.

As other commenters mentioned, there's COM, but that's a hairball to code for and a hairball to configure. The nicest systems that worked that way historically were the Lisp machine and Smalltalk environments, but the closest day-to-day software is probably Emacs. Everything in Emacs really can be connected together through the power of text buffers and Lisp. Objective-C is Smalltalk semantics retrofitted onto C, and originally NEXTSTEP, later macOS, really was a promising environment for this sort of integration... but in recent years Apple has been so focused on "apps" that it's doubtful they can keep supporting that vision.

It's funny how cancelled projects are somehow making people almost more "nostalgic" than projects that actually shipped. One of the reason may be that cancelled projects don't need to be completed, to ship with a reasonably good quality, to have an easy to use interface, to be sustainable for a long enough period of time, etc.

I rather see a reason that many such cancelled projects had very elegant architectures/structures, which is something that hackers love.

If you want to ship a product so that it becomes commercially successful, you often have to "deeply taint" this clear vision to make the product compatible with the multitude of very inelegant (industry) standards that customers expect/require.

Thus the nostalgia is not about shipping vs not shipping, but about keeping an elegant vision or be willing to taint it to be compatible with a "depraved" world.

Right. Most cancelled projects are beautifully architected and discount tons of installed products with all their decades of cruft.

Then you start trying to bring the New Thing(r) into the Real World(tm) and there are 5000 edge cases the original project dealt with in a 42-page if/else block for 270 different OEM patches that were sold by some JV team in another building who have never written a line of code in their lives.

"Brother, it's edge cases all the way down" - Alan Tuna Turing

There's a concept in political theory about why people become nostalgic for lost causes, failed movements, etc - kind of a backwards looking utopianism?

If only we had done X, if only this group had succeeded instead of failed in the past... I do agree that it's a way to avoid looking at the actual implementations and details of a real thing, and just go to what might have been directly.