Hacker News Reader

Comment by blowski | Hacker News Reader

> 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.

View on HN

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.

Reply on news.ycombinator.com