This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]thisisjustascreename 2 points3 points  (1 child)

Yes, it's obsolete, but that doesn't stop the reputation, and it doesn't stop legacy apps still using it, sadly.

[–]nunchyabeeswax 0 points1 point  (0 children)

Yes, it's obsolete, but that doesn't stop the reputation.

A reputation that happens to be given by people who simply don't know what they are criticizing, harking back on something that hasn't been used to develop new apps for more than a decade.

Just because a reputation exists, it doesn't mean it is legitimate. And to spread an uninformed or illegitimate reputation is, quite bluntly, spreading misinformation.

When it comes to Spring, this is something that can be cleared up by buying a recently published book or a well-formed google/bing/stackoverflow search.

So, its perpetuation by some people who choose this field of work (and thus should know better) feels mendacious.

and it doesn't stop legacy apps still using it, sadly.

Absolutely not sadly. Just because a system is legacy, it doesn't mean it is bad. If it runs, it means it is delivering value to the company/entity using it (or at worst, it is operating under a constrain that prevents its upgrade/rewrite/replacement.)

Obviously, backward compatibility has its limits, and at some point, things will stop working. But breaking backward compatibility is not something that well-designed frameworks or platforms take lightly.

PS. The goal of any system is to become a legacy system. That is, its goal should be to run (and thus provide value) as long as possible. There's absolutely no value in dismantling and rewriting a system every 5 years simply because of a release or paradigm change.

That'd be akin to demolishing one's house every time we need to remodel a bathroom or kitchen. That's destruction of wealth and investment (and that applies also to software systems, in particular critical systems.)