[jbb_hn]

We wouldn’t make applications. Rather we’d deliver components which could interoperate via a binary contract.

Components would be “snapped” together by non-programmers to make an application.

I suppose that pieces of this became true with the proliferation and adoption of open source. Rather than a binary protocol, HTTP came out on top.

SharePoint brought us WebParts which tried to put the power in the hands of business users, but it turned out they were still too technical and not flexible enough.

I don’t see the role of software developer/engineer going away anytime soon.

[ta1234567890]

> Components would be “snapped” together by non-programmers to make an application.

I’ve seen this with tools like Zapier. I know many non-technical people that put together amazing workflows just piecing things together with webhooks and similar tools.

[vidanay]

> components which could interoperate via a binary contract

COM still underlies an abhorrent amount of the Windows architecture.

[criddell]

In the 90's COM didn't make a lot of sense to me because I never needed it. Then, around 2001, I needed it to solve some problems and I finally invested the time to figure it out. It's actually pretty neat as long as it isn't in your web browser (ActiveX).

Around that time I too thought I was seeing the future - component-based development that's language and platform agnostic.

[Tarucho]

COM was pretty neat indeed

[pjmlp]

UWP/WinRT is basically an improved COM, it never went away, rather took over most of the modern Windows APIs since XP.

Pity that WinDev keeps producing the same tools as back in MDIL 1.0 days though, the only good tool C++/CX, got killed by them.

[ingas]

At least it's possible to write COM in a measurable time. I did it in C++ although that was a pain. It became much easier in .NET.

CORBA - I did not even finish reading "Introduction to CORBA". A book of 500+ pages.

[flukus]

> We wouldn’t make applications. Rather we’d deliver components which could interoperate via a binary contract. Components would be “snapped” together by non-programmers to make an application.

This is how .net got it's crappy generic name. Back in it's early days it (and SOAP) was sold as the glue that would stitch all this together, just add a web reference and you'd have all this functionality in your project. It was incredibly disappointing to get through all this marketing and eventually realize it was just an MS version of java. Enterprise java beans, CORBA, COM and probably some others were also efforts in this direction. These days it's REST and microservices.

[thethought]

There was also OLE before ActiveX/COM and later DCOM. But the DLL’s were always a constant.

[thangalin]

Bret Victor alluded to these pieces in his digs on APIs:

https://vimeo.com/71278954

[jbb_hn]

Wow, thanks for sharing that!

Hearing him name drop terms like markup language, stylesheets and internet is mind blowing. If only the promise of “no delay in response” had been achieved :-)

[rchaud]

> Components would be “snapped” together by non-programmers to make an application.

That's basically what Salesforce is.

[slickrick216]

This is really interesting and reflected in some things like dreamweaver and Oracle Apex.

I can actually see some of this happening in the crypto space. Things like MetaMask and now chainlink combining into some form of low code smart contract app tool. As you say though even in this scenario devs don’t go away.

[astrange]

Yes, it's very profitable for devs because you can just steal everyone's money, since the smart contract language was invented by people who did zero reading about safe program design.

[slickrick216]

So just like normal payment processing code then.

[astrange]

Except half the time the bank is also a scam and there's no legal recourse.

[deviantfero]

sounds like a beefed up unix philosophy, I think command pipes in the shell gave us something very similar to this idea way back, except that it doesn't really lend itself to complex programs like I think you're suggesting