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…
My 20 year career is technical debt or deprecated
351–360 of 585 posts
Re: My 20 year career is technical debt or deprecated
#352Earlier 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.
Re: My 20 year career is technical debt or deprecated
#353I 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.
Re: My 20 year career is technical debt or deprecated
#354Earlier 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.
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
#355Re: My 20 year career is technical debt or deprecated
#356> 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…
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
#357Earlier 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.
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…
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 feel that's substantially different with Python, Go, JS and ... C/C++.
Re: My 20 year career is technical debt or deprecated
#360I 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.
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