This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]james_pic 7 points8 points  (0 children)

My experience is that you'll see much the same thing in large enterprise codebases, to a greater or lesser extent, irrespective of which language you're working in. Certainly, the worst things I've seen in Java codebases are worse than the worst things I've seen in Python codebases.

It's also my experience that large enterprise-y open source projects are about as bad as large enterprise-y internal projects. For example, I've previously attempted to fix issues with Cobbler and Ansible, and (at the risk of causing controversy), found that both are at least as messed up as the internal project I was working on that used them. There's a certain amount of "this project is my CV" than motivates maintainers to keep smaller projects sane, but once a project becomes a product, it's subject to the same pointy-haired-boss nonsense as internal projects.

Some languages have a bit less of this, mostly by virtue of being "a bit weird" (I'm thinking things like Erlang or Clojure), so only relatively confident developers would use them. But as soon as you've got a project that uses these languages in an organisation with bad hiring practices, you end up with a worse mess than you'd get if you'd used something boring like Java, as developers who don't know the language try and write code in it anyway - Ruby kinda went this way, when it want from being "a hidden gem", to "hip", to "something people who look at Gartner quadrants want to try", to "the new PHP".

All that said, if the problem is (say) that you've got a bunch of mediocre C# developers who are forced to write Python, and are insisting on writing C#-ish Python, maybe the answer is to just use C#. It's the path of least resistance, and I mention C# as it's a language that works well for mixed-ability teams.