I can imagine corporate Java codebases can end up in the billion LOC as well. I mean it MIGHT be easier to read, or easier to find developers for...

I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.

Ha ha no. Sorry to disappoint :)

Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it.

This isn’t an indictment of Java. Just resume driven design.

That's why I left Java 5 years (after like a 12 year career in it) ago and plan on never getting another Java job. It's just making classes have "some" kind of use no matter what the task is, there's no coding to solve problems, it's coding to make structure.

To be fair, I’ve seen this in c++ as well. Building an entire structure of classes like “java” and then using “design patterns” on those abstractions. All to implement a simple 7 step socket communication protocol. It was a “wtf is going on here moment”?

I was also part of it. I did my own share of - well if we design it this way then we can have a second "type" that does X with the same interface. And it just keeps on iterating like that. It's still a useful pattern, but often at least in my own case, overused for really trivial stuff.

Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.

There's a spirograph guy in the corner, the only one left that knows perl, lurking out and trying to entice people with its merits.

Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff.

To be fair if I walked away from Rust for a year I'd probably be similarly lost.

I still will reach for Perl for the occasional quick one-of text-processing application, but I do spend a lot of time in perldoc when I do.

>> I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java.

The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way.

It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.

With Java? I usually think of Perl as a glue language, like bash scripting. Java would not be my choice to glue components together.

Nah, Perl can be a perfectly fine applications language. Some things get kind of ugly with it (object-orientation is notoriously hacky and there are two different approaches to classes that take inverse (literally) approaches to how to represent the objects in terms of Perl’s scalars, arrays and maps. It does suffer a bit from being an early mover so there are questionable choices like the fact that library code is traditionally installed system-wide so good luck if application A needs library v3 an application B needs v2 and v2 and v3 have some subtle incompatibility, but Perl is no less capable than Python and arguably more capable than PHP, both of which have plenty of applications written in them.

Perl was the primary application-layer language at Amazon. It was used for most things that didn't need to be in a low-level language for performance or other reasons (for those, C++ was used instead).