Well I'll provide a somewhat different story where the lack of change has caused quite a loss in productivity.
At my current employer's a big part of the codebase is in Perl and the boss is a fan of the language, so we keep using it. The problem is, Perl is pretty much dead, and most of the packages out there on CPAN feel like they've been built 10 years ago. Not to mention, the language itself lacks what I would call essential features like exception handling, classes, etc (which has to be tacked on by using "shims" from CPAN like Moose or Try::Tiny)
At some point I had a particular issue in one of our apps where it would be making tons of DB queries and we need to cache them. In Python land there are plenty of packages that give me transparent caching at the ORM level. In Perl land? Oh yeah this post on a mailing list from 2007 about someone having the same problem, and a bit of untested code that may or may not work.
I gave up on that particular issue and it'll probably never get fixed, but let's just say that have we been using an "alive" language things would've gone much smoother.
The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.
> I do not see how a caching at ORM level could give any benefit.
I don't know anything about the Python libraries as such but if they implement pluggable modules like memcache, redis, SysV SHM, etc., for the caching, then you can chop and change as required without having to make any application level changes[1]. Which is also handy for testing because you can supply your own mock cache module to do ... whatever.
[1] A good example would be going from "direct DB access" to "global memcache" to "local memcache backed by global memcache" - all without application changes.
> A good example would be going from "direct DB access" to "global memcache" to "local memcache backed by global memcache" - all without application changes.
I strongly disagree: I'd rather debug something wrong with the lone application level change which added the cache support at the application level, rather than have to enter the long and deep rabbit hole of the path the code takes at the point I ask for a resultset and I get something from the DB-backed ORM, or from a global memcache, or blah.
But then again, I happily develop on mostly-Perl codebase(s) ;)
Well in my particular case it's a read-only app (there are no writes at all from the app itself so no need to worry about cache invalidation) so a caching ORM that can be a drop-in replacement would've been a huge win for less than one hour of dev time, and I could've done it in Python without any issues.
With this obsolete language the only way is to change pretty much all the app to do app-layer caching and that would've cost 20x times that, so we're not going to do it.
At my current employer's a big part of the codebase is in Perl and the boss is a fan of the language, so we keep using it. The problem is, Perl is pretty much dead, and most of the packages out there on CPAN feel like they've been built 10 years ago. Not to mention, the language itself lacks what I would call essential features like exception handling, classes, etc (which has to be tacked on by using "shims" from CPAN like Moose or Try::Tiny)
At some point I had a particular issue in one of our apps where it would be making tons of DB queries and we need to cache them. In Python land there are plenty of packages that give me transparent caching at the ORM level. In Perl land? Oh yeah this post on a mailing list from 2007 about someone having the same problem, and a bit of untested code that may or may not work.
I gave up on that particular issue and it'll probably never get fixed, but let's just say that have we been using an "alive" language things would've gone much smoother.