Hacker News Reader

Comment by pjmlp | Hacker News Reader

Might be arrogant, but after rewriting the same stuff over Sun RPC, CORBA, DCOM, DCE, XML-RPC, SOAP, WebServices, BPEL, RMI, Remoting, REST, gRPC,.... eventually it gets tiring.

Or deploying stuff over HP-UX Vaults, J2EE/JEE containers, mainframe language environments, VMs, Docker, k8s, lambdas (CGIs just got rediscovered),....

View on HN

I mean, I totally get your point, but these protocols/technologies solve specific problems quite well. In most cases is not an arbitrary decision.

A different case would be rewriting your Angular app in Vue just because the latter is more shiny.

The problem being how to sell new tech, books, consulting contracts....

There's probably no better language on earth to build a data warehouse in than java yet i fully expect to see a BI book on Javascript OLAP technologies within my lifetime. You use what you grow up with.

> There's probably no better language on earth to build a data warehouse in than java

Slightly OT, but I'm curious why that is?

Because so many data warehouses has been built in it. Most significant problems have been solved traditional star schema/snowflake schema fact table oriented systems. And a change in language ins't going to open new doors that otherwise remain closed now.

Not sure I agree. SIMD instructions, vectorized query, and low-level memory management are hard to implement in Java. Plus there's genuine uncertainty about the future of the language. I would not implement a new data warehouse in Java at this point.

Intel and Linaro have contributed SIMD support, although it might be harder than using something like C++.

Not only is the language open source, while during Sun days it was only free beer, there are several contributors, and Microsoft has acquired jClarity, started contributing to OpenJDK, gives parity with .NET tooling on Azure, alongside Red-Hat supports Java on VSCode.

Ah, even Java has had more talks at Build 2020 than F# or VB.

The only uncertainty is from the anti-Java, Oracle hating crowd, for everyone else, companies using IBM, Red-Hat, Adobe, SAP,.... products, it is business as usual.

The category "RPC framework" solves a specific problem quite well, but it's doubtful that each incarnation is really a sufficient improvement on all those that came before it to justify re-learning and migrating.

Angular vs Vue is not an arbitrary decision either, the developer experience is massively different.

Try adopting a perspective of curiosity: "How does this new tech work? What new benefits might it provide?" Or at least one of professional duty. All knowledge workers have to keep up with the latest developments in their field; lawyers have to study up on the new case law, doctors have to read medical journals.

If you've decided ahead of time that it's a drudgery, you're only going to make yourself miserable. You don't have to spend all of your free time on it, but you do have to remain flexible and open-minded. You may as well try to find something there to enjoy.

Most of this new tech is mostly created with the purpose of generating new business, that is all.

As Alan Kay perfectly puts it, fashion driven industry, and naturally one must keep themselves fashionable.

So up one goes rewriting that working WCF service into gRPC, because fashion.

But is ok, after all someone needs to pay those consulting rates and keep projects rolling, book industry happy with introduction and best practices books, and new themes for conferences, and most importantly blog posts with postmortems regarding technology migrations.

You're just reiterating the cynical mindset that I'm recommending against, because it's:

a) Atrophic to one's career

b) Just a generally miserable way to live as a programmer

I don't believe things are so bleak, and I think people would benefit from being open to that possibility.

I do enterprise consulting, if it generates new business opportunities I am all ears, regardless my cynical view.

> a) Atrophic to one's career

Career growth after entry level rarely hinges on acquisition of technical knowledge. If anything, technical knowledge is the easiest to acquire which is why entry levels can claim it without much work experience. Organizational navigation, team work, delivering actual results, knowing how and when to apply those skills (and when not to) mostly come with experience, and those are going to be the determining factors for promotions beyond entry levels.

> b) Just a generally miserable way to live as a programmer

I would argue it is more miserable to not have developed those tacit skills so that keeping up with the latest and greatest is the only element of competitive advantage to stay relevant. I would also speculate this might be the reason why juniors tend to over-emphasize the latest tech as the greatest tech, because they don't think they have anything else to be competitive in the job market.

Curiosity is not an algorithmic virtue, it doesn't apply to every case. It needs to be tempered with a dose of conservatism to deliver results in real world.

> Try adopting a perspective of curiosity: "How does this new tech work? What new benefits might it provide?" Or at least one of professional duty. All knowledge workers have to keep up with the latest developments in their field; lawyers have to study up on the new case law, doctors have to read medical journals.

I think part of the problem is that some fraction of "new tech" is substantially just a reinvention of the wheel and/or oscillating fads, but it's all presented as "new therefore obviously superior" to what came before.

Others have probably said it better, but tech needs more study of history.

Like I said, often it's not that simple. Each iteration on re-inventing the wheel usually incorporates some new lessons learned. I won't disagree that more perspective on history would be a good thing, but that's no reason to dismiss it all wholesale.

Reply on news.ycombinator.com