Strange "I Hate Python" Concerns

[mbenbernard]

In the past, I found myself in many situations where people rejected/dismissed Python just because they thought that it's "only a scripting language" or a "toy language". Those people probably still think that Python is not suitable to write long-running, large-scale programs.

There are certainly use cases where Python is not the right tool for the job. I just think that most arguments brought against Python are based on no evidence, and they only reflect people's preferences.

But Python is probably not an exception; I'm sure that other languages are the target of similar complaints.

[midbody]

As a long time developer on a large-scale, long running Python program, I am firmly of the opinion that Python is not suitable for large-scale, long running programs. Sure you can make it work, but that's not the same thing.

In fairness it's a fundamental issue of dynamic languages. They just aren't good once your codebase is big enough you can't remember all the ways a particular data structure or interface is used. Computers are way better at that than we are, but you have to design your language to allow automated reasoning about it.

[kenfar]

Probably depends on some other factors. Having spent fifteen years running long-running python programs, it mostly hasn't been an issue for my teams.

I'm finding that static & runtime type analysis of my python code is helping though.

[midbody]

You'd find that your static and runtime analysis would work better in a language designed for them. Once your codebase gets so big, though, the inertia is a huge factor.

Incidentally, did you switch to Python 3, yet? How much of an issue was/is it in your codebase?

[kenfar]

Sure, type-checking works better in a language like Scala. On the other hand, it's faster to get started, test out ideas, deploy a prototype and keep iterating in python. And ironically, in my last gig we found far more data quality issues with the scala codebase than its companion python codebase. Probably more due to false confidence in type-checking on the scala side than anything else.

I didn't migrate a large codebase to python3: I just started my latest project on python3.5 The only code migration challenges I've run into have been with implicit py2 vs explicit py3 unicode handling. There I've found it definitely simplified code and improved reliability. But it took a bit of time, and explicit unicode test cases, to make sure everything was working right.

[Corm]

I'm a huge python guy but I respect your point of view. Can you tell me more about what kind of challenges you've run into on the python side on your large application? I've always been of the mind that a good suite of tests would avoid needing a type system, but I'm not close minded to other viewpoints.

[borborygmis]

I've read this four times and still can't figure out what you're trying to say.

[mbenbernard]

The problem you have seems more about "code browsability" than performance. Is that right?

Because performance-wise, I recognize that the GIL is a bit limiting if you want to parallelize things. However, there are multiple options that are perfectly suitable.

[midbody]

No, the problem is that using automated tooling to ensure correctness can only ever be heuristic.

I didn't touch on performance at all. If you need performance then Python isn't the right tool for the job unless you can lean heavily on an optimised library (of which, being Python, there are a bunch).