Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

351–360 of 585 posts

Re: My 20 year career is technical debt or deprecated

#351
post #288

Earlier quoted context omitted.

Java's records are immutable.

And most shops likely aren't using a JVM new enough to use records, and it will be a while before they are able to upgrade. And even then, most 3rd-party libraries out there won't use records, because they want to be compatible with the JVMs their users use. Hell, most popular libraries available on Maven Central are compiled with JDK8, or, at best, JDK11. Aside from immutable instances, it would be nice if 'final' w…

So it sounds like the fix is available with an update. What more do you want?

Re: My 20 year career is technical debt or deprecated

#352
post #230

Earlier quoted context omitted.

I feel like if Java had immutability by default it would be such a better language to work with. It is so hard to determine what actually gets modified where in a large Java codebase.

Java's records are immutable.

Also still extremely hard to use due to basic they are, e.g. there is no "with"-er method or syntax yet to modify existing values.

Re: My 20 year career is technical debt or deprecated

#353

I feel like this is heavily connected with the idea of legacy. I grew up in Scotland, and lots of the buildings, culture, etc, have been around for hundreds of years. It would be nice to feel like something I was building would last as long and outlive me. It doesn’t though. Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business proble…

100% agree. But I like to think that ideas and solutions and products can be legacies. It's semi-uncommon to write code that legitimately lasts 5+ years. But it's very common to work on projects/products/companies that last 15+ years. And I have to be content with that.

Most code that survives 5 years survived for all the wrong reasons. That said, most code that's survived five years is often a profitable product with a reasonable human at the helm telling us needs to not to touch it

Re: My 20 year career is technical debt or deprecated

#354
post #235
post #230

Earlier quoted context omitted.

I feel like if Java had immutability by default it would be such a better language to work with. It is so hard to determine what actually gets modified where in a large Java codebase.

Too bad immutability breaks the quite-ubiquitous-in-JVM-land Bean spec (and I wonder what one was smoking before drawing that spec). I think having proper sum-types with pattern matching would have also made it a much better language.

Java has been around for a longish time. Around the early 2000's there was at least a perception that you should avoid creating too many objects as that carried performance overhead for construction and garbage collection.

https://softwareengineering.stackexchange.com/questions/1495...

Immutable objects often require you to construct a new object to store an updated value and garbage collect the now unused previous object. So a lot of early Java code was written with mutable objects to avoid performance issues.

The Java Bean spec was written in 1997:

https://blog.joda.org/2014/11/the-javabeans-specification.ht...

Re: My 20 year career is technical debt or deprecated

#355
I wish more mid career devs understood this. All those PR review battles over commas in comments are mostly wastes of time. Entropy comes, it's one of the few guarantees we have. Your legacy will not be the software you wrote, but the impact that software had.

Re: My 20 year career is technical debt or deprecated

#356
post #216

> My entire career is now technical debt, or the code has been deprecated. My fellow dev often laugh when I tell them that instead of looking at all the long dead techs that are not useful to me anymore, my way to feel good is to look back at all the long dead techs that I didn't bother to learn . And, geez, is the graveyard huge. > Java Applets were also a big thing once upon a time. They were slow, and having the c…

> And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" (I'm guessing all of the EJB, applets an general 90's Java enterprise stuff). Only irony here is you thinking it is. The 90's Java was a thing to hate. Running fat complex app server…

>> bunch of code-as-XML for configuration

Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).

Re: My 20 year career is technical debt or deprecated

#357
post #203

Earlier quoted context omitted.

> A chefs product only lasts an hour at most. A chef's recipe, which is also something the chef creates, may last hundreds of years.

But tbf, that happens once in a billion recipes. 99% of new recipes are forgotten, often after a week or two.

Even some of the most famous recipes can change over time. I’m sure that things like McDonald’s burgers are slightly different now.

Perhaps the most enduring a chef can do is invent a new technique.

Re: My 20 year career is technical debt or deprecated

#358

> My entire career is now technical debt, or the code has been deprecated. My fellow dev often laugh when I tell them that instead of looking at all the long dead techs that are not useful to me anymore, my way to feel good is to look back at all the long dead techs that I didn't bother to learn . And, geez, is the graveyard huge. > Java Applets were also a big thing once upon a time. They were slow, and having the c…

> And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. Guilty as charged! I hate using Java because everything written in java seems to blend into the same indistinguishable swamp of classes with meaningless names, full of methods that constantly find new and interesting ways to obscure what your program is actually trying to do. De…

I've spent most of my programming life working in OOP. I see people critical of it, but I don't know what the alternative is for the kind of stuff I do for my job (not to say I have a choice in changing how we do it). Does anyone know of an open source project that implements a complex GUI app that doesn't use OOP so I can see what that code can look like?

Re: My 20 year career is technical debt or deprecated

#359

> My entire career is now technical debt, or the code has been deprecated. My fellow dev often laugh when I tell them that instead of looking at all the long dead techs that are not useful to me anymore, my way to feel good is to look back at all the long dead techs that I didn't bother to learn . And, geez, is the graveyard huge. > Java Applets were also a big thing once upon a time. They were slow, and having the c…

I'd rather claim that the main reason is that the author seemed drawn towards proprietary tech stacks that the companies behind them wanted to fully control and that contributed to their demise. It was clear from the start that Flash and VB and ColdFusion and all that wouldn't last long, just because no open ecosystem could form to keep them adapting and vibrant.

I feel that's substantially different with Python, Go, JS and ... C/C++.

Re: My 20 year career is technical debt or deprecated

#360
post #215

I find it interesting how tech that mostly comes out of enterprises tends to have a shorter shelf life than the "more open" options. > Basic, Silverlight, ColdFusion, asp... I'd add > Lingo, Flash Basically if Microsoft, Adobe or any other entrenched player make it easy for you to develop in it and they offer the only Dev stack then its probably going to die quickly. Counter case, apple seems to be doing fine with sw…

>Basically if Microsoft, Adobe or any other entrenched player make it easy for you to develop in it and they offer the only Dev stack then its probably going to die quickly. .NET and C# are heavily used, so is SAP and other corporate proprietary stuff. Enterprise customers prefer entrenched players that own the whole stack.

Agreed. I also think it sort of makes my point. Afaik the .Net ecosystem started getting significantly more traction once they started opensourcing it and giving control to more open bodies.

I don't know why you would bring up SAP though. I've dealt with SAP deployments in the past its usually the type of the project where you have to integrate through some arcane protocol due to reasons(TM) and the end results resembles less a live connection and more a sneakernet

Post reply on HN