←back to thread

272 points abdisalan | 1 comments | | HN request time: 0s | source
Show context
mvkel ◴[] No.42175730[source]
> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

replies(21): >>42175799 #>>42175818 #>>42175826 #>>42175846 #>>42176217 #>>42176305 #>>42176788 #>>42176958 #>>42181497 #>>42182299 #>>42182564 #>>42182778 #>>42183020 #>>42183093 #>>42183501 #>>42183725 #>>42184814 #>>42192770 #>>42193606 #>>42194518 #>>42211558 #
mattgreenrocks ◴[] No.42175799[source]
Other ecosystems usually do not have problems to the extent the author had.
replies(2): >>42175953 #>>42177000 #
hathawsh ◴[] No.42175953[source]
I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated versions, so they just don't. That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.
replies(3): >>42176165 #>>42181256 #>>42184012 #
tmpz22 ◴[] No.42176165[source]
> That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.

I disagree. This is an easy problem to avoid with minimal due diligence, people just choose convenience and make unnecessary tradeoffs.

* Use the standard library (ironically not available for Node projects). It will be built with better backwards compatibility almost every time. What deprecations do occur will likely be VERY WELL documented with much quicker adaptions.

* Limit third party dependencies. Do you really need an ORM for your apps 40 sql queries? How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM? 1 hour? 5 hours? 20 hours?

* Pick technologies with better track records. Maybe don't use Beta software like Swift Data for your iOS App. Maybe choose golang for your API even though it'll take a little bit longer to build it.

replies(3): >>42176297 #>>42182193 #>>42210256 #
1. pjc50 ◴[] No.42182193[source]
> How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM?

Having a machine do codegen to map your queries to objects is still an ORM, except now it's nondeterministic and not updateable.

(mind you, I come from C# where you simply use LINQ+EF without worry, or occasionally Dapper for smaller cases)