Comment by tragomaskhalos | Hacker News Reader

Comment by tragomaskhalos | Hacker News Reader

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule.

It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. The fact that such blatant silliness actually met with knowing nods gives the insight into how technologies that promised to wire this brave new world together became hot properties almost regardless of their details.

It is telling that J2EE became at least mildly sane when people started ignoring entity beans and working exclusively with session beans, inching towards the realisation that the api was the thing that needed to be remote. Imo the current status quo with REST (in its usual bastardised guise) and json as the language neutral representation, alongside aids like Json schema and OpenApi, while by no means perfect, are workable enough and certainly light years ahead of these earlier fumbling efforts.

> "I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. "

One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stuck in one .NET process]" there was COM. From Python, from VBScript, from ActivePerl, even in Powershell to break out of .NET, from C# and Java, you could do their language equivalent of:

    $snmp = new-object -ComObject olePrn.OleSNMP
    $snmp.open('127.0.0.1', 'snmp_community', 2, 1000)
    $snmp.get('.1.3.6.1.2.1.1.3.0')

and voila, pluggable SNMP engine into any script in any Windows scripting or programming language. Use it in Excel in Visual Basic for Applications and update your spreadsheet with SNMP results. Then embed the Excel spreadsheet in a Word document. Ppen PowerShell on Windows and run this code[1] to query all registered ones, 1744 on my system, surely some are useful or fun?

Want to read JPG headers? Lean on Explorer to do it, without needing a JPG metadata library in every language. Want to integrate with Windows Text to Speech, or Excel, or Dyalog APL or send a fax from JScript or automate a browser or whatever? COM objects are there.

And it's a world being thrown away in favour of "simply download a Selenium wrapper for every language" and "simply do an OAUTH login to a web service to interface with a styled sluggish CRUD text system". And that's a shame, because web developers, macOS users, Linux users, smartphone users, don't know what they're missing. I'm sympathetic to it being apparently horrible to program the backend in C++, but this world you're scoffing at actually existed and has good features especially for the casual hacker who wants to use system-wide standard interfaces to large and powerful engines, with client and server written in differing languages.

[1] https://stackoverflow.com/questions/660319/where-can-i-find-...

On the other hand, programing those dynamic dispatch COM interfaces was really not so fun. There must have been 20-30 interfaces that all implemented IUnknown, but there's only one REAL IUnknown.

If I could upvote you 100 times at the expense of not being able to vote for the rest of the year, I would do it right now.

COM was awesome tech! I wish we had an equivalent today.

I did a ton of python-com projects for a big aerospace company in the late 90's and it was amazingly easy to get a lot of well-integrated functionality for little time and effort. Really sad that it's not more common now.

COM is the main Windows API since Longhorn ideas were redone as COM.

It isn't going anywhere, even if the tooling keeps as clunky as ever.

Sorry, I wasn't clear in that post -- I'm on Linux, and I wish Linux had an equivalent tech.

not exactly same, but dbus

>don't know what they're missing

Maybe you don't kow what you are missing by just using pipes with small binaries for everything :)

Take the video player MPV, it can be controlled by sending commands into a named pipe, which is good, so you can control it from a Python script - but now instead of having a system-wide standard like COM where you have PyWIN32 which works with any COM object to any COM program and you call methods from the MPV documentation with Python numbers and strings, now you have to have a Python-to-MPV-JSON-Schema serializer in your code, and if you want to use C# you need a C#-to-MPV-JSON-Schema-serializer in your code. All you're really doing is triggering some code inside MPV - calling some library functions - but instead of a convenient system-wide standard way to do it, there's a different inconvenient non-standard way of doing it from every language to every program. Strictly worse.

On macOS you can take advantage of Objective-C runtime or XPC.

On mobile OS, entitlements or OS IPC like Binder.

In what concerns Windows it is still pretty much present tense, how COM is spread all around the OS, specially since Vista.

The J2EE 1.0 spec was so goddamned infuriating, owing to the fact it was introduced by the company who penned the 8 Fallacies of Distributed Computing. At least half of which it was obviously in violation of. I walked away from it. Or tried to. Every successful implementation violated the spec, because the spec was idiotic. So we were all doing “J2EE” and with each revision what they said we should do looked a bit more like what were were doing already. But by the time it was almost good it was captured by industry.

Then Rod Johnson lambasted it famously and then lived long enough to become J2Ee.

I still have his book here somewhere. I keep meaning to sit down with it and the Spring spec and see how badly the abyss stared into him.

Reminds me of how little love the SOAP that came between had for the XSD that actually did all the heavy lifting. A bazillion ways of reinventing elaborate communicative acts and surrounding ritual, and a big handwavy "yeah, xsd, whatever" to the actual content.

REST was a huge change in perspective in how it put the representation in the spotlight. It seems ironic that this happened on a schemaless baseline, but perhaps that was a fire it needed to go through, "this is the important part and if we put too much automated tooling in this corner you won't give it the attention it deserves".

It was truly insane. I still remember seeing in my book example of container that could host excel inside of my program and save files etc.

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

I often think about many things that were explored in that time as Birds of paradise. The desktop as it was seen then was mostly solved, and new challenges of internet didn't yet materialized - many engineers need to do something. So they started to do very weird things

Totally different things, distribution of objects is stupid but as a USER I do love what OLE and it's descendants (and what's inside f.ex. Open/Libreoffice) actually provides in terms of actually working plugin API's.

The best example of OLE the ideas that OLE enabled (even if not implemented by it anymore?) is how you can embed spreadsheets and drawings into a Word document, it becomes super useful for me doing my annual report since I can stick a proper spreadsheet that has automatic calculations in the middle of running text.

(Would I be fond of having to implement all of it? Probably not, and there was also probably many stupid usages of it but for what it was for initially it was a win)

> one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application

Every time I consume a third-party’s REST API, I’m doing that, no? Albeit the article may have oversold the idea in the work ending there.

Well yes that's true, however that's in the spirit of a 3rd party providing a specific service to your program, whereas the object zealots intended objects in the sense of entities with identity being these off-the-peg consumables. Imagine if in a code review every time you declared a class to represent some feature you were challenged as to whether there wasn't some component you could shop for instead. The Aircraft example was egregious - does a company doing in flight catering want the same thing as an air traffic control simulation?! It's also about boundaries - a typical 3rd party REST api has a clean and obvious boundary, but how would one of these Aircraft objects sensibly interoperate with my program, as it can't know anything about the rest of the application. The hand-wavers never thought to explore these critical problems.

What about when I install a library or use a framework? When I use Spring Boot, it's calling my code. I install libraries which dispatch events to which I subscribe and that come with pre-defined objects I pass around. I use SDKs to talk with REST APIs. I even use objects that persist their data in my database, and have their own migration files.

I'm being somewhat disingenuous asking this. I realise most of the code in any application will be bespoke, but I don't think we should deny that the vision you describe has become reality in part.

Yes, it had became reality in many environments like .NET, Delphi and even Windows COM. The problem is however, they are only good in homogenous environments. Services on the other hand, could be easily consumed by all systems because they don’t need to know your system to work with and you don’t need to take care of the memory, threading and life cycle issues as you need to with objects.

In other words, it boils down to the objects vs interfaces, OO vs functional programming arguments in the last decades.

In reality, we still do both. But it’s clear by now that we don’t want remote objects anymore but remote services.

There's the idea, and then there's its execution.

You're saying someone else's successful (and partial) execution of an idea somehow validates the original failed execution.

DCOM was far more practical, mostly because the scope was smaller. I used very successfully with a trading system back in the nineties.

In the same institution, the corba guys just built themselved giant messes trying to unify 4 different languages and the kind of network dependency hell that only corba could allow.

DCOM was never cool, but it also wasn't as ambitious, so good systems got built with it.

I vaguely remember those spinning balls in Windows 2000, XP etc. to know your DCOM components were working. Are they still a thing? We did the 3 tier DNA thing, using VB because in VB it was simple, in C++ it looked hellish.

VB was denounced as infantile nonsense fit only for the GUI by us C++ jocks, until we'd done COM in both C++ and then in VB - then we realised what a huge favour VB was doing in insulating you from so much of the complexity. Sure there were Don Box-level things you could probably only do in C++, but for us working stiffs doing business apps it was like day following night.

I loved Don Box's books on COM and SOAP. But "Essential COM" sure made my brain hurt once it started talking about DCOM.

https://news.ycombinator.com/item?id=29593432

>Earlier I posted an article by Don Box comparing SOM and COM, and I mentioned that WebAssembly is going through a similar evolution, and might benefit from some of the lessons of COM and SOM: [...]

https://news.ycombinator.com/item?id=20266627

>This article comparing SOM and COM was written by Don Box. (first archived in January 1999, but doesn't say when published): [...]

>Don Box wrote an excellent in-depth book about COM: "Essential COM": "Nobody explains COM better than Don Box" -Charlie Kindel, COM Guy, Microsoft Corporation. [...]

>Here's a synopsis of COM I wrote in response to "Can someone link to a synopsis describing what "COM" is? It's hard to search for. (e.g. microsoft com visual studio)":

https://news.ycombinator.com/item?id=12975257

>Glad you asked! One of my favorite topics. ;)

>COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.

https://news.ycombinator.com/item?id=22282936

>Apple's OpenDoc based browser, CyberDog, was also quite amazing and flexible, because it was completely component based and integrated with OpenDoc. But that plane never got off the ground, because Steve Jobs rightfully focused on saying "No" and "put a bullet in OpenDoc's head".

There was also a thread obsession. However, luckily, 'Threads' magazine is about sewing. I had an issue on my desk.

Ah yes apartment threading and all that. Read so much about that stuff, but will go to my grave having never understood it!

Apartment threading means that your component has a thread in, which doesn't call into other components. It receives the requests via messages, same if it were running in another process. I believe there is marshaling of arguments to an apartment thread, like in the out-of-process case. Thus you don't have to deal with the possibility that two or more calling threads are executing the component's code.

The world is still obsessed.

REST, GraphQL and gRPC language specific SDKs aren't any different, and now we have containers and kubernetes in addition.

NIH killed OOP. Nobody wants to use someone else's object, because that isn't FUN and programmers get paid in FUN.

Reply on news.ycombinator.com