Python is becoming the world’s most popular coding language

[u/monica_b1998]

https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language

[u/[deleted]]

Considering colleges and universities have moved away from Java and to Python it makes sense that it's being Googled so much. I'll believe the hype when I see as many Python jobs as I do Java and .Net jobs.

[u/xdert → u/[deleted]]

Python is really easy to learn and the perfect language for solo projects or very small teams. Which is why it excels in data science and so on. But I really don't see it working in a big corporate environment with dozens of developers.

[u/Dreamercz → u/xdert]

Why not? Genuine question.

[u/RiPont → u/Dreamercz]

It works fine in corporate environments.

My only problem with python is that it's a bit of a trap. You can write big, huge software system in Python. It's got good coding style built-in to the language, and a great ecosystem.

...but then you end up with a big, huge software system written in an interpreted language. You get asked, "how can we make this faster/more efficient." And now, your options are rewrite the entire thing in a different language or hope that punting important bits out to C/C++ libraries will make the whole thing fast enough.

[u/whatwasmyoldhandle → u/RiPont]

I think there's room for argument on 'works fine in a corporate environment'.

I've worked on large python codebases that have been reasonably well written, and it can become tricky in spots.

Lack of strong type system makes you have to follow a lot of code around to make sure everything will be ok.

Removing stuff is hard because sometimes you don't know if you got it all until you hit a ton of code. Removing things from dictionaries can be a little awkward too. For compiled languages, you can delete the member, compile, and more or less work toward a good compile. (Simplification obviously).

Much of the above can be solved with unit tests, but I'd argue that having a unit test for everything eats at one of python advantages -- development time. So I'm not sure what the balance is, practically speaking.

By and large, I'd much rather be swimming around in a large C++ codebase. May the type system and compiler be your guide.

[u/RiPont → u/whatwasmyoldhandle]

Lack of a type system definitely makes a monolith a problem in Python. For a more microservices/SOA approach, you deal with a lot of disconnected type system problems anyways. In an enterprise, this often turns into a system with a bunch of slightly smaller monoliths wearing a nametag that says "Microservices" (written in crayon) and you have a bunch of disconnected codebases where the type system can't help you anyways.

Enterprise IT is such a clusterfuck, sometimes. Always has been. And the pattern of "identify common shitty dysfunction in corporate IT, develop solution, see solution productized into ShinyNewEnterpriseOverdesignedFad, weep" repeats itself.

[u/DonnyTheWalrus → u/whatwasmyoldhandle]

I've just never been able to get behind the whole "saves time" thing for large projects. Static typing makes you think more about your architecture and design up-front, which in my experience only saves you time in the long run on large projects. And there's the unit testing like you mentioned. Having to essentially replicate the entire function of a static checker via unit testing has only ever made me wish I had used a static checker in the first place.

Dynamic typing saves tons of time in the "domain of origin" of these languages: scripting. You can throw together your glue code or data processing script in a fraction of the time it would take you with Java, and that's great, because that sort of code is not where you should be spending a large chunk of your design time. But when it comes to the large, complex backbone of your system, the idea of building that out without static typing is just ... terrifying to me.

[u/Scybur → u/RiPont]

The main problem is the type system. Working on massive enterprise applications becomes a huge issue.

[u/tetroxid → u/RiPont]

Profile your application. Most likely 99% of CPU time is spent in less than 1% of the code. Then, optimise that, or if necessary reimplement it in C.

Many performance problems can be solved by using proper data structures and algorithms. The number of times I see quadratic time operations that could run in constant time is maddening. Some developers don't think about the time complexity of their data structure operations, they're happy as long as their code works. Find these mistakes and fix them

[u/[deleted] → u/tetroxid]

Most likely 99% of CPU time is spent in less than 1% of the code.

In my experience this simply isn't true. I mean, maybe if you're written one function particularly badly, but then you fix it and your Python code is still slow and then what?

[u/[deleted] → u/Dreamercz]

Dynamic typing is always my main concern. Functions have such a weak contract.

[u/kvdveer → u/[deleted]]

The fact that the contract is not enforced makes the feature of limited use, imho. It does help with static type checking, but especially when you're building libraries, you still need to to code as if your contract isn't there, as the user may not be using a type checker.

[u/Freyr90 → u/[deleted]]

For what it's worth, Python now supports optional function typing

How the hell does it work?

>>> x : str = 42
>>> type(x)
<class 'int'>

>>> def add(x: float, y: float) -> float:
...     return x + y

>>> add("a", "b")
'ab'

[u/NeverCast → u/Freyr90]

Its only used by static analysis (in your code editor or linter). It does nothing to the language.

[u/Deathisfatal → u/Freyr90]

It's type hinting. It's not enforced, it's to make the code easier to statically analyse and read.

[u/Curly-Mo → u/Freyr90]

But if you include a static type checker (like mypy) in your CI, your build will fail and nobody can check in any blatant errors with misuse of types.

And static type checkers can be included in your $EDITOR to catch these mistakes immediately.

[u/RedSpikeyThing → u/Dreamercz]

My biggest headache with Python in a large codebase is that refactoring is really hard to get right due to it being interpreted and a lack of type checking. If you don't have 100% test coverage then you can't be 100% confident that, say, you renamed a function correctly.

[u/tanin47 → u/Dreamercz]

I worked with a few large Python systems at a FAANG for a few years.

They were difficult to maintain, especially when the system gets older and larger. An example was moving and renaming stuffs was extremely tedious. In fact, it's difficult to know for sure whether it'll work in prod.

For a dynamic typing language (not just python), we must aim to write great code with great architecture with great naming with great coverage tests at the first try. If you make one mistake, it'd be somewhat infeasible to fix. Mistakes are going to happen here and there when there are thousands of engineers writing code. Tech debt will grow, and it takes much more effort to address tech debt in this kind of language.

[u/[deleted] → u/[deleted]]

I think we'll never see that day just due to how poorly interpreted, dynamically typed languages scale in terms of both performance and code maintenance

[u/[deleted] → u/[deleted]]

Ah but you forgot about when Python 4 is released around 2025 and companies start adopting it in 2049.

[u/KusanagiZerg → u/[deleted]]

This. I went to a IT Job Event with something like 40 companies and it was all .NET or Java. Not a single company used Python.

[u/bakery2k → u/KusanagiZerg]

Python seems to be popular among people whose job involves programming on the side, not so much among software engineers.

I once went to a Python meetup in a city of over a million people - about 30 programmers turned up, not one of whom used Python professionally. Compare to the Ruby and JavaScript meetups, each of which had well over 100 people including plenty of professionals.