It is not "I like to write code in this language" but "If I am handed down a production ready system, I would prefer it to be written in this language".
A lot of people won't say the same answer to the first and the second question.
It is not "I like to write code in this language" but "If I am handed down a production ready system, I would prefer it to be written in this language".
A lot of people won't say the same answer to the first and the second question.
Indeed. And the latter, that is, taking over and maintaining code written by someone else, is the more common concern in day-to-day jobs. More likely that you will get to build and improve an existing system than create one from scratch.
For example, I'm happy to maintain Python codebases with type annotations and type checking enabled. Those without better have a pretty solid docstring culture and be willing to add progressive type checking. It doesn't so much matter what version of Python it is.
"Python codebases with type annotations and type checking enabled" is not the norm. Consider a random file from the famous `pytorch` framework.
https://github.com/pytorch/pytorch/blob/main/torch/_functorc...
Even this file does not have type annotations everywhere.
I found this article with some numbers [0], with the top one being that "95% of ATM swipes rely on COBOL code". If you just need to maintain something in production, and only occasionally update the business logic, without having to upgrade the architecture, COBOL is the way to go.
[0] https://www.pragmaticcoders.com/resources/legacy-code-stats
1. COBOL systems are typically written on a much shallower software stack with less room for unreliability
2. banking systems have a ton of effort put into reliability over decades of development.
In fairness, it’s pretty fundamental stuff. But… the company has been working on moving to some Oracle bs for 5-6 years.
/s but also true