I think this sentiment underestimates the amount of work people do on existing codebases.

The most reviled languages are often previously loved languages that made writing code easier at the cost of reading and understanding it.

Team 1 secretes reams of instant legacy code, but get money and promotions for shipping it. Team 42 gets handed a steaming pile of manure that is beyond understanding. They then pick up the pitchforks because it is obviously the language's fault.

So, yeah, it isn't the language so much as the average incentives and behaviors around development.

> The most reviled languages are often previously loved languages that made writing code easier at the cost of reading and understanding it.

You claim someone actually loved Objective C or Perl? Or even Scala?

Hahah. I like Objective-C with ARC (in spite of its complexity and limitations), but Swift is more compact and I'm probably never going back (except maybe for hobby projects like writing something for GNUstep.)

I also like how Objective-C++ can mix in C++ code bases. It's an amazing chimera of a language.

That's funny because to me, Perl, is the epitome of a fun write-only language!

I'm sure at least their "parents" did.

$tongue in @cheek

> You claim someone actually loved Objective C

The problem with Objective C is that it requires skill. The average developer really is better off using a more remedial language like Swift.

Most professional programming is done in already existing code and new projects often have to respect existing standards. You rarely get to choose what language to use.

I was recently asked to recommend a language for a new team. My boss (who won't be writing or even reading any of the code) suggested Python. His reasoning: it's what the kids are learning in college these days.

So here I am as the team Senior, looking at current and future team members and deciding on whether to be selfish and choose what's good for me, or trying to figure out what makes something good for the team. Is it better to pick something with a large hiring pool? Is it better to pick something with fewer footguns? Is it better to pick something with higher performance? Is C# really ok if we need Mac support? Is Swift ok for one-off glue apps that run on Linux? Is Zig too young? If a team of five has a Java geek, a Rust zealot, a C# fan, and somebody who only knows Python, can we just agree to all learn and use Go? If I know my replacement will undo whatever I choose, does it really matter?

The safe bet is C#, followed by Go. Swift, Rust, Zig, Python have their problems.

I love Zig and Nim but constantly pick C# or Go.

If time, money, support and performance are not an issue, you can pick anything but I guess someone of the above will always be an issue.

Unless you rewrite it in Rust and link an article on HN.

Surely you can appreciate that the language you're using isn't always your choice.

Not always, but the most languages I have used professionally were my choices.

That means x86, assembly, C, C++, C#, Python and half of Javascript. For Javascript I mean half because I enjoyed doing simple things in JS on front-end long time ago, but these days I kind of dislike JS frameworks and I've learned them because I had to after I signed some contracts. I could have stayed 100% with backend work, but now is too late to complain.

I managed to steer clear of Perl, Objective C, Cobol and other languages I don't enjoy. I managed to learn F# and some Ocaml which I would like to use but never got the chance (personal projects excluded).

Yes, I do understand that, having programmed in business environments with legacy code for over a decade.

I've hated the poor decisions my predecessors had to make, the corners that were cut. I've hated that it's not maintained or documented. I've hated that it doesn't have tests.

Never have I hated the language.

And that sometimes, you make the wrong choice, and grow to hate that language.