Hacker News Reader

Comment by eternalny1 | Hacker News Reader

What is old is new again.

I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess.

Sometimes, if it's not broke, don't try to "fix" it.

I can say the same regarding a lot of what is going on in the JavaScript ecosystem, where people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript.

View on HN

It used to be that people wrote Fortran in any language. Now they're rewriting Java in every language.

The bad reputation that enterprise Java gets, comes from enterprise C and C++ codebases.

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

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

Any language that gets into enterprise architect hands, with projects spread around multiple development sites with several consulting agencies, gets their FactoryFactories and such.

No, Java has its own share of problems that it didn't inherit from anywhere. No custom value types, no operator overloading and the distaste for AOT compilation, to name a few. Also culture of code generation instead of using some kind of macro system.

Custom value types will arrive, that is the point of project Valhalla.

C and Go also don't do operator overloading.

Code generation was a thing in C and C++ during the 90's. Borland C++ 1.0 came with a macro library (BIDS), which was later replaced by a new template based version in Borland C++ 2.0.

And the Go culture of //go:generate goes beyond anything that Java has had on its almost 30 years of existence.

AOT compilation exists since the early 2000's. The only distaste is that most developers don't want to pay for their tools, so they rather used the free beer JDK from Sun instead third party vendors. So only big corporations got to buy the JDKs from IBM, Oracle, ExcelsiorJET, Aonix,....

However now AOT free beer exists on OpenJDK, OpenJ9, GraalVM and although not strictly Java, Android.

It's like a museum of problems. Waves of solutions that became problems after.

The culture of code generation before the culture of XML configuration.

I love my XML, with comments and static type validation, making my graphical tooling and IDE based editing quite comfortable, while observing YAML and JSON formats catching up on XML features.

They are there for a reason.

The joys of JSONPath. Its documentation. Its implementations. Its capabilities.

I'm waiting for more fun with JSONSLT the day someone has the idea to make a first limited and poorly documented implementation.

Spring, Hibernate and other "enterprise" monsters came from Java alone. FactoryFactory123.

Have you ever used CORBA and DCOM factories?

Enterprise ORMs were created in Smalltalk, C++ and Objective-C, years before Java was created.

Poet and Enterprise Object Framework were two well known ones.

In fact J2EE was born of the ashes of a failed Objective-C project at Sun, Neo, after its collaboration with NeXT on OpenSTEP failed apart.

https://en.m.wikipedia.org/wiki/Distributed_Objects_Everywhe...

Things are not created in vacuum, it helps to actually know computing history.

Teaching the parable of Chesterton's Fence to every programmer would save billions annually.

https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

Indeed.

I can't imagine your level of cynicism. I've only been at this for ten years, and the number of times I've seen the wheel come full circle and old ideas come back into vogue, the problems with them rediscovered, reactions to those problems, and then the thing that preceded them again take precedence is somewhat depressing. At best I feel like we are grinding ahead a few inches each cycle.

It's like the movie Benjamin Button but with a case of amnesia every three years.

Sometimes it feels more like Memento

Same boat, same feeling.

Agree with your last point. And as someone who really liked old school callback/prototype/closure based JavaScript, I can say not only would these people have been better off using a better language, they also ruined JavaScript for the things it was great at.

You can still do all that in JS, novel syntactic sugar aside.

He/She cannot do that, at least at their employer, because people would throw up at the sight of the code and cry until its rewritten.

As an example slip some DOM methods into your code and watch people go into convulsions like an angry zombie on cocaine.

There are very real reasons not to use DOM methods assuming you're using a front end framework. Not only is the coding style more imperative than say React, but frontend frameworks have been designed to efficiently update the DOM and have diffing algorithms that can check for necessary state changes. Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020?

> Is there really a compelling reason for writing your own DOM manipulation in a sizeable frontend codebase in 2020?

It is several orders of magnitude faster. It’s also how I prefer to code because managing state isn’t challenging and I am not hopelessly paralyzed by imperative code.

Maybe they don't want to force their users to download several MB of framework libraries in order to use their website.

DOM manipulation is perfectly fine for interacting with styled documents, the web's forté. If your website amounts to a set of configuration forms and a blog then you probably don't need React.

You can turn a bar into a dance club, and I can still drink there. But it’s a little academic to suggest that.

That said, I’m am quite free to choose not to install npm packages that use Babel or Webpack, and I that’s what I choose when I have a choice.

Certainly don’t have that choice at my work.

> people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript.

Do you have a concrete example to illustate this, and what issues it causes?

On the surface I'm not sure I agree, if what you're saying is people wanting a certain feature should switch languages to get it rather than build it into the language they already use.

What new problem was Nodejs trying to solve and why does it exist?

Well, indeed, Node is a good example of the point I'm making - it provided a full environment for writing programs in JS outside the browser.

There were a plethora of other languages/runtimes available for writing such programs, but Node made this available to people who already knew & liked using JS without having to switch to and/or learn a new language.

"What is old is new again."

It isn't really, though. This is Some Guy's Opinion™. There are many Some Guy's, and there are countless anti-monolith articles being penned at this moment (probably).

People have different experiences with different groups and different tech stacks and different needs. Results may vary.

Just to give my own Some Guy opinion, people fail with so-called microservices when it's not really microservices but instead is a monolith with artificial walls (in the same way that firms do waterfall but pretend that they're agile by having incredibly frequent "scrums" that are nothing but status meetings). When you actually divided into lots of different projects and teams and they each get to construct their own internal world so long as they provide the appropriate robust and documented external API, it can be absolutely liberating. For some projects.

Your next to last sentence is spot on but it requires well defined interfaces and engineering which is orthogonal to middle management’s desire to commodities development.

I am fine with that, I miss the simplicity of PHP and Delphi sometimes.

> Sometimes, if it's not broke, don't try to "fix" it.

I'm going to interpret this as "if your monolith is broke, breaking it up into microservices won't fix it"

A implies B does not mean B implies A.

Sometimes a microservice architecture is the best way to fix your problems. Sometimes it’s the worst. But you’ll only be able to tell after your monolith is, indeed, truly good and busted.

Just never start with it. That’s crazy.

Reply on news.ycombinator.com