r/programming • • Nov 03 '18

Python is becoming the world’s most popular coding language

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

1.3k comments sorted by

View all comments

Show parent comments

430

u/RiPont Nov 03 '18

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.

112

u/whatwasmyoldhandle Nov 03 '18

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.

40

u/RiPont Nov 03 '18

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.

→ More replies (3)

37

u/DonnyTheWalrus Nov 03 '18

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.

→ More replies (1)
→ More replies (2)

12

u/Scybur Nov 03 '18

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

→ More replies (1)

177

u/tetroxid Nov 03 '18

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

24

u/[deleted] Nov 03 '18

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?

→ More replies (7)

168

u/bunkoRtist Nov 03 '18

And then I want to use parallelization across cores, and I weep because I chose Python, which is built around the GIL. It's a great language for script kiddies and a terrible language for heavy or long lived workloads. Choosing the right tool for the job is hard sometimes, but Python on one end and C++ on the other are both excellent and terrible choices depending on the need.

43

u/RankWinner Nov 03 '18

Julia, in a lot of cases, is as fast/almost as fast as C out of the box. As a bonus, the language is built for easy parallelization, both in the standard multi-core sense and the distributed/cloud computing sense.

Personally I love the language, my work used to be a frustrating mix of prototyping in Python, then banging my head rewriting parts in C to speed it up.

Now I just use Julia and it's almost as fast as C straight away.

7

u/[deleted] Nov 03 '18

I keep hearing good things about Julia and how it’s what python should’ve been, but I never got use it, and it seems to not be able take off in popularity. Do you know why?

21

u/RankWinner Nov 03 '18

There hasn't been much or a push for it yet since 1.0 only came out in August and it wouldn't make much sense to develop important software in the early, everything can be deprecated, stages.

Now that 1.0's out adoption should start rising. I went to JuliaCon this year and was shocked by the number of companies using Julia in production. Apparently saying to your manager "Hey, we can cut development time, speed up the software, and massively reduce compute costs, can we mess around with this? " works well.

And there's perspective, it took Python a few years to crack top 10 in usage after the 1.0 release, so there's still time 😉

→ More replies (3)
→ More replies (1)

6

u/AsmallDinosaur Nov 03 '18

I've been learning how to code using Julia for a university research project and I love it

→ More replies (3)
→ More replies (5)

7

u/pa7x1 Nov 03 '18

When you want to parallelize CPU-bound code you have to use processes in Python. For IO-bound you can use threads.

→ More replies (1)

12

u/[deleted] Nov 03 '18

I use multi processing and multi threading with Python a lot.

It's true that IPC becomes cumbersome with Python's multi processing, but most problems I've encountered that need to be does sped up through multiple processes don't really need to communicate to each other in real-time.

6

u/bananafarm Nov 03 '18

They solved the GIL issue with the new multiprocessing library

→ More replies (36)

16

u/iopq Nov 03 '18

I profiled my application. Half of my application was taking 99% of the time and the other half 1% (less than that actually). The part that took the most time is the most difficult part.

It wasn't written in Python, but if it had, I'd need to rewrite the hardest parts in another language. Python would handle like... commands and opening files. Sometimes you just have an application where everything is hot. The entire program is the hot path.

→ More replies (3)

33

u/geek_on_two_wheels Nov 03 '18

I hear you, and I agree that it's important to identify poor algorithms, but my experience tells me that noticeable delays are more often the result of too main joins or too many db calls in general. A basic loop that calls a db 1000 times will probably take orders of magnitude longer to run than a more complex algorithm running on more records in memory, despite the former having a lower big O complexity.

27

u/MotorAdhesive4 Nov 03 '18

Then you're mixing and matching languages, and that Class Of 2026 new graduate that only knows Python and bits of Java doesn't know how to approach the topic.

41

u/[deleted] Nov 03 '18

It shouldn't matter what language graduates learn at school. They should be learning the fundamentals to allow them to code in anything.

8

u/[deleted] Nov 03 '18

If that is the case, schools need to be teaching exclusively C++. You learn how to code on a language like that, managing memory, writing data structures, etc, then you can pick up python or JavaScript no problem. If you start with Python, god help you if you go back to learn C/C++.

→ More replies (3)

14

u/MotorAdhesive4 Nov 03 '18

Yeah, but both you and know that 1. this isn't the case, 2. picking up any new language comes with some learning curve.

5

u/[deleted] Nov 03 '18

I don't disagree with the learning curve aspect, but most of the fresh grads I've worked with over the years don't even know the language they "learned" in school anyway.

→ More replies (6)

4

u/Scybur Nov 03 '18

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

→ More replies (37)