> That paper seems like a window to an alternate reality in which everything that's currently hot in tech has been done 20 years ago, except programming language-agnostic, using saner (i.e. binary) protocols, offline-first, and with advanced security built in from the start.

Honestly this happens all the time. Not only do we seem to reinvent the wheel but we almost invariably reinvent it worse. Take 'dark mode' for instance. Everybody lauds that they can switch to a different theme that they feel is easier on their eyes, apparently oblivious to the fact that we could do that in Windows 95 with significantly greater and more granular control at the OS level. This industry is overrun with complexity fetishists who keep piling on more and more abstractions and calling it progress when they manage to catch up with the less-abstracted past.

I think we should separate ideas/proof of concepts that were in the field and presented as having potential, and implementations that are largely adopted and reliable.

There will always be a lag between the two, and it won’t just be ‘reinventing the wheel’.

I had a look at CORBA and it was horrible in many ways. Interestingly it’s something that works and is proven at large scale but nobody would want to have it for small/middle scale non enterprisy applications, and it might not even be a good idea at large scale depending on what properties are valued. In no way I’d see kubernetes with services as a worse version of it, we didn’t choose it just by ignorance or hype.

Same with “dark mode“ on win 95. Most programs couldn’t even properly handle text sizes, it was a i18n nightmare that was just brushed under the carpet. Changing text and background colors was the same, with some apps somewhat working because they Mostly relied on default widgets, and a mess of unusable apps on the side that just had text colors baked. You had a better chance to have it work by plain inverting all colors through the accessibility settings.

To be fair it’s still partly a mess now, but we are in a way better situation that in Win95 , it is understood at an application level, it actually makes sense now.

You could have "dark mode" in Windows 3.0. Provided programs used the standard widgets and the correct "named" colours, everything would pick up the colour changes from the operating system.

How on earth can anyone think that each application having to individually implement support for a bespoke "dark mode" is a better situation than having more granular controls in the OS and applications just follow the UI guidelines is beyond me. It's bullshit like that that makes me want to leave IT forever.

It's probably the unfortunate consequence of a typical software vendor's perspective.

There's a deep conflict between the interests of users and software vendors, a conflict for control over presentation. It's blindingly visible on the web, and half the reason it's in such shitty state it is, but it also applies to desktop software. The problem is that for a vendor, application's UI and UX are marketing space, and they want total control over "user's journey". For the user, UI/UX are things that stand between them and the work they want to get done, so they want it to be effort- and bullshit-free. For non-tech-savvy users this implies "consistent with all other software they use"; for power users, this means "able to be altered or removed" - but both of those viewpoints require vendor to not have the final say about presentation.

In context of dark mode, an OS-level control over UI styling is a user-friendly feature. Unfortunately, it got defeated by vendors who want the UI to be their branding space, and now they have to begrudgingly add dark mode themselves.

EDIT: see also https://news.ycombinator.com/item?id=24918296 upthread, it seems to be a quite accurate description of what will happen if we let the vendor side win.

It’s because reality is complicated.

Most people don’t want “dark mode” as a pure accessibility feature in the sense of “whatever color scheme is fine as long as it’s dark everywhere”. That’s the reverse color feature in most OS.

Instead I/they want dark themes but with pleasing colors, adjusted depending on the screens and the widgets, having sane defaults for content that is usually supposed to be white, with exceptions.

Yes, that’s a tall order, it’s context dependent, and we might actually want to decide app by app if the dev did a good job and/or if dark mode makes sense, and sometimes change the theme in the app because it’s otherwise not great.

We end up in a patchwork of apps following dark mode and others not, with different themes applied that might not be triggered by the system.

For instance I use youtube, reddit and editing apps in dark mode only, while the rest of the system is in light mode. As you say it could be handled by the system in a super granular way, but it would add that much more complexity, and I actually chose the exact themes to be used in most of these apps, so centralization wouldn’t help anyway.

How on earth is the same set of UI icons supposed to keep their readability against vastly different background colors? If you want to do a proper job of that, your application needs to become aware of dark mode anyway and ship with a separate set of icons.

Yes, in terms of raw flexibility exposed to the user, customizable color schemes look great on the surface. They work to some degree, but fail utterly for a wide range of cases in practice. Not having them is progress after a fashion because it means giving up on an flawed idea. I will admit, though, that it is not easy to see why it is flawed when you haven't tried to design custom controls that have to convey more state than can be expressed using the standard OS colir palette.

The problem with the fine grained user control over individual theme colors is that the OS theme is never complete enough for applications with visually complex UIs. At some point, applications have a need for extra colors to denote things in different ways. So they would need to provide their own configuration UI that allows the user to update these colors to be usable with any custom theme they're running. Unfortunately, most software developers never bothered to implement something like this and assumed the user would be running the default theme. So the users ended up with lots of broken UIs after trying to adjust the system wide theme.

A lot of stuff were "microservices" before the name was coined. SOA (as in service-oriented-architecture) was definitely a thing.

I worked for a company whose software was/is based on CORBA and let me tell you, that thing really smells like microservices-before-it-was-cool.

You had a naming service, and each component would connect to the naming service on startup and resolve the endpoint for the components it needed.

And each piece of software had a component called ORB (object-request-broker) that was used to represent remote stuff (remote objects/endpoints). You could invoke method calls on this object (kinda/sorta, i'm making it simpler here) and it would forward the call in background, hiding the networking/serializing/deserializing details.

That whole things kinda reminds me of protocolbuffers, etcd and microservices. By using a cluster manager (Veritas Cluster Manager) you had a service groups, something that looked like a pod, in a way.

-----------

It's been a while, but I've started thinking that there's nothing really new. The problems we're facing are pretty much always the same, it's just that the solutions improve on different areas. Kubernetes for example helps a lot on the scaling problem and the standardization (both ops team and dev team have a common lingo, the kubernetes object model -- pods, deployments, services, requests&limits etc).

EDIT:

Just skimmed the article... Yup, DCOM was a competing alternative to CORBA.

Interestingly enough, the "N" in "GNOME" was due to the fact that it was initially based on CORBA, and used a C-language ORB called orbit (IIRC).

If someone older than me would like to chime in and add some details, that would be lovely.

KDE and GNOME agreed in the early days that both desktops would be based on COBRA and use standard object names so the two would be compatible.

After fighting COBRA for a while KDE said this is too complex/slow and wrote DCOM (I might remember this name wrong) which gave them the parts they wanted without the overhead. GNOME stuck with COBRA longer, but I get the sense that they half agreed and were just hoping they could find a solution without abandoning COBRA (GNOME also had more corporate backers even in those days so there was probably non-programmer architects demanding they make it work). Evenually both agreed that they needed something more lightweight to solve the desktop needs and DBus came along.

CORBA, not COBRA :)

Also, iirc, KDE's thing was named DCOP

The issue with KDE was that Qt was nonfree so there was also a few efforts to replace Qt with something else.

That is why gnome existed (now it is large enough to have a place), but a completely different issue from the corba one.

GNU Harmony and GNU NOME are two different projects from around the same time.

The thing holding DCOM back was that the protocol was closed source and unspecified. It’s very difficult to make Microsoft’s version of DCE RPC work with other implementations let alone their proprietary object extensions.

If they had wanted interoperability, they could have implemented something more standards based as IBM did with SOM. But requiring Windows for all parts of distributed systems is very limiting.

Visual Studio of 20 years ago was in many ways superior to Xcode of today, but you need Xcode to make iOS apps, and iPhones are cool. Moral of the story is better technology does not always win. It’s a fallacy that technology is a continuous positive progression.

So I say this having used XCode about 10 years ago, but is XCode really that bad?

Around 2000 or so, I was installing the Visual Studio -- Pre .NET Version -- on a number of new developer workstations. I was not a Helpdesk or Desktop tech, but worked supporting servers -- they sent me over to do the installs because invariably "something wouldn't launch". Different IDEs were used depending on what language you were writing in with this monster of an app that was used to write programs in Visual Basic[0]. And the program was 5-10 times larger than the largest installed application and came with 2 CD-ROMs worth of documentation that needed to be installed locally[1]. I remember I'd start all of the installs at the same time because they took several hours to complete.

[0] If it isn't obvious, this was a one-off job that I don't recall very much about. I didn't start using a Microsoft IDE until the first release of Visual Studio .NET (retroactively renamed "Visual Studio .NET 2002", I think).

[1] For the younger among us, that's about 1.5GB in a world where two years earlier 16GB of HDD was very expensive.

It may have been language-agnostic, but it was never going to be OS-agnostic. Like everything Microsoft it only worked with Microsoft implementations on both ends.

> saner (i.e. binary) protocols

.. which only had one canonical implementation on each end.

If I remember rightly, the protocol for accessing Exchange from Outlook was MAPI over either DCOM or DCE/RPC. Despite some reverse engineering efforts, this is why there were no Open Source drop-in replacements for Exchange, and clients accessing Exchange always did so over IMAP, thereby losing features.

Similarly SAMBA is DCE/RPC. https://wiki.samba.org/index.php/DCERPC

This still exists! COM serves as the foundation of modern windows apps you currently see on Windows 10 (WinRT). And still actively developed in its form as WinRT.

COM sadly has a number of unfortunate characteristics though: it's quite complex to learn and it's not very secure actually (de-serialization of complex types in C anyone?)

But I think it's a wonderful technology.

I'm currently having an opportunity to learn it, as I need to interface with a piece of legacy software that works over DCOM. I thought this would be a nightmare, as all my previous brief encounters with COM/DCOM left a bad taste (obscure errors full of GUIDs, registry hacking), but now that I'm actually trying to learn what the thing is, I'm becoming more and more in awe of it.

This is true for a great number of things. Our industry has a terrible collective memory - we're at such a rush to push aside the old in favour of new shiny stuff only to have to rediscover why it was useful (or not) later.

I felt the same with components.

I was using encapsulated components with internal state and defined interfaces more than two decades ago and it was old technology even then.

The web is a funny place, they grab something and claim it's revolutionary but often forget to mention where it came from.

It's not a bad thing but I have often joked if you want to see what is considered state of the art in Year X go see what the academics where doing in (X-20) years.

If you are interested in those properties, you might like something i'm working on that i'm about to launch.

Its nothing like COM, but a vision of what moderns browsers engines could turn into (focusing on the properties you have mentioned).

We should not let "them" dictate dumb clients (and apps) to us that consume from the fog that "the cloud" is.

This is a corporate trend that will take a lot of freedom from us, and if we let them have their way, it will be pretty hard to get us all out of this nightmarish future we are heading to.

I'm interested. Please, tell us more, and/or drop me an email (address in profile).

Good. Will drop you an email.

As far as I know SOA is a concept and DCOM and CORBA are implementations of this concept. Microservices are a more lightweight variant of SOA, but basically the same idea.

> using saner (i.e. binary) protocols

For some reason that I fail to understand, it seems that most computer protocols and most computer file formats are designed under the unstated assumption that those using them will not have access to a computer.

It often happens when the technology satisfies a need the market haven't really felt yet. Microservices are hot now because many companies and individual developers have already felt the pain on their own experience. Without such experience, advanced technology just seems "unnecessary complicated" compared to the simple LAMP-based monolith that "just gets the job done".

You will probably have a good time reading about the history of the Mach OS.

link to the paper?

Provided in an edit.