Hacker News Reader

Comment by pjc50 | Hacker News Reader

There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there?

Because the profession is so heavily skewed towards the young and self-taught, people don't seem to know about the solutions of a decade ago and their merits and demerits. This is partly why software componentisation as "parts catalog" has never really taken off. It's easier to reimplement or independently reinvent something than it is to find the right existing solution and learn it.

It's as if it were easier to turn every bolt you needed on a lathe than to go to the shop for them.

(The closest might be npm, but then we see what an engineer would call an excessively large bill-of-materials, as trivial projects pull in thousands of dependencies)

View on HN

Software componentization never took off because every attempt at it either leaks abstractions like a sieve or is so purely functional as to be impractical for real world use.

Shall I list the componentization tech of yore? CORBA, OpenDoc, Java Server Faces, COM, DCOM (oh god, CORBA again!), SGML (the original component framework), XML zoo (oh god, CORBA a third time).. JSON zoo, (a flippin' fourth time, are you kidding?!)

componentization is something we're still figuring out. Alan Kay and SmallTalk were the closest to get to it (see previous comment about practicality though) and the mainstream just now is starting to think of JS and Ruby as "novel". NPM? Please.

We have a long way to go before componentization actually works. So yes, I guess I agree that it's simply easier to reinvent things to a specific context than solve the problem of sharing code context-free.

You forgot microservices. I'd forgotten Java Server Faces, was that related to Java Beans?

I'll join you in a glass of "oh god, CORBA!" At least one good thing about the web is that people have given up hoping that RPC could be transparent.

Heh. https://www.grpc.io

CORBA and DCOM were really not great but I don't think you're qualified to have a go at these things if you think that SGML is related to DCOM or that XML and JSON are "componentization tech".

I'd also note that despite how unfashionable it is and was, COM was a remarkably successful component framework. A lot of Windows apps use COM heavily and not because they were required to do so - they componentized themselves using COM because they wanted to and it delivered real value to them.

In addition, I'm not sure how you are defining "component", but the term is rather similar to library, and modern apps frequently pull in enormous quantities of libraries. It worked out OK, actually.

That's the constant battle. "Oh, this library kind of does what I want, but this behavior kind of sucks, and this bug hasn't been fixed... Do I shoehorn it in and write all the glue and adapter code? Fuck it, I'll just start over, and build yet another grid component, or datepicker, or rich-text editor."

"This is partly why software componentisation as 'parts catalog' has never really taken off."

Well, that and the fact that OO turned out to not be a very good mechanism for building the parts catalog on. In the end I'd judge it as only slightly more successful than procedural programming on that front.

For instance, Haskell's "part's catalog" is somewhat smaller than other languages. But the parts do what they say they will, and generally go together pretty well once the community is done chewing on them and fixing them up. (Here I mean fundamental tools like parsers or text template systems, not merely "libraries to access this API" or "bindings to this particular library.) All those restrictions that go into Haskell are there for a reason.

>There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there?

There is a iternal itteration between reading disgusting Documentation (nonexistant one) and finding the hidden shortconmings of existing solutions - and just doing the only "open source" that is accepted in every company- rewrite it yourself.

   eternal war between "avoid reinventing the wheel" and ahistorical "not invented here"

Did you intend to say something else? Because that's the same thing twice: you reinvent a wheel because the other wheel was 'not invented here', so if you avoid reinventing a wheel, you are suffering from NIH.

It's hard to avoid reinventing the wheel if all you know is what was invented 'here' and 'recently'.

Reply on news.ycombinator.com