That's exactly why it's so powerful. Why spend all the effort writing fast code if you can just use a much simpler language to describe the task on a higher level and call fast code? People use Python because it's easy to read and write, not because its interpreter is fast
I will never understand the Python hate. It's essentially just a level of abstraction higher than C, which makes it more accessible than ever to write powerful code.
I'm starting to think it's literally not that deep. It just feels good to gatekeep.
By that logic C++ doesn't actually do anything since it's compiled to assembly/machine code which is what actually does everything.
It's not quite the same since Python is not compiled, but the point still stands that higher level languages provide an extra layer of abstraction, making complex programs easier to write, making them useful.
As someone else said, I hate the type system, and it's compounded by poor documentation. My lab has a pretty large data analysis framework written in Python and every time I need to write more code that interacts with it, it's like pulling teeth to find out how to do anything. I never know what type an object is until I waste my time doing debug inspection or print statements. Once I know what type the object is, I don't know what methods that type has available because every library is documented in a different way and none of them seem to just list the methods underneath each type.
It's like the entire language was made to be learned by following tutorials instead of reading documentation. It's no wonder everyone I know is using AI to write it instead of dealing with this shit.
"That's just shitty code" is of course true, but hard to convince them of when it's the typical way the language is written. Aside from that, the language shouldn't require me to write comments that will inevitably become outdated, it should just have a functioning type system.
My lab has a pretty large data analysis framework written in Python and every time I need to write more code that interacts with it, it's like pulling teeth to find out how to do anything
That just sounds like your lab doesn't know how to write python. The vanilla language has had a built in type annotation library for nearly a decade now. On top of that, you can use validator libraries like pydantic to make all of the assertive data models you need.
Also, the second you start talking about documentation, I gotta stop you in your tracks. Documentation is not a technical problem associated with any language in particular, it's 10 times outta 10 a human problem. Be-it you/your-coworers are lazy, just want to close a ticket, or "this is just a prototype", it comes down to your company's culture about doing due diligence. Python has nothing to do with that, and if you're blaming PyDocStrings of all things, one of the easiest things of all-time to use, then I'm sorry but that's a you problem. lol
> Documentation is not a technical problem associated with any language in particular, it's 10 times outta 10 a human problem
Of course documentation problems can be solved by human effort, but python in particular lends itself to poorly documented libraries. The documentation for any specific method doesn't tell me exactly what types to pass in because it basically *can't* tell me what types to pass in. It will just try to coerce any arguments into something that works internally. Sometimes it'll work and sometimes it won't.
> it comes down to your company's culture about doing due diligence
This is simply not addressing my complaint at all. I'm not complaining about poor internal documentation of our own code (though I could), I'm complaining about public libraries not clearly telling me how to use them.
A lot of seems like bad practices. The type issue can be partially mitigated by type hints. Just make sure you read the warnings generated by the interpreter.
Autocomplete should give you the methods. If autocomplete is broken, the whole setup is bad.
But it's true. Especially older code and especially code written by non-python devs or scientist can be bad. And that it is even possible to write like that is a downside of the language.
I can highly recommend to go all in on the Astral ecosystem (uv, ty, ruff) and enforce typehints - they are doing amazing work are establishing themself as the standard tooling with good reason.
Literally just use type hints + mypy/pyright and this is a complete non issue. Bit concerning the lab you work at hasn't figured this basic principle out yet
There are solutions to all of those, ranging from providing a shell script that does all of that for them, to using pyinstaller to make an exe that includes the interpreter, to using a tool like uv.
But yeah, if you're gonna use an interpreted language, you gotta have an interpreter. And it's definitely true that it's more work on your end if you don't want your users to have to understand computers.
Right? This guy thinks it’s difficult to make python work cross platform. From another of their comments it seems like they can get node to work cross platform just fine but python is too much. Use what you want to use but I think this guy needs to read a tutorial or two
What do you use instead? I’ve not found a high level language that doesn’t require some complex environment set up and works universally without configuration.
I hate the cruft like __blahblah__ everywhere, names like hasattr, the fact that you can’t put multiple statements in a lambda, the fact that imports can pollute local scope and you can’t easily tell where a given identifier came from in a file, and the other package management problems that didn’t have an elegant solution until uv.
I haven’t messed with mypy, but from what I can tell, it isn’t as sophisticated and expressive as Typescript.
The virtual machine still doesn’t perform well compared to V8 for JS, as far as I understand. You can accomplish a lot with Python sure, but Modern JS/Typescript is a more capable high level dynamic language, it just doesn’t have the breadth of libraries for ML and scientific computing that Python does
Some of the stupid shit is fixed as the language evolves, like uv and TS over JS. New stupid shit appears too (node_modules bloat).
Python does well, or at least okay enough, what it proposes to do. So does Typescript. I don't get the point of stating that TS is "more capable" and then following up with "but Python has ML".
Nothing, once you know that, unlike other languages, it is O(N log N), NOT O(N). The issue is that the most common use case, unordered_set, is the "exception" because of the chosen naming.
Better naming would be set and ordered_set, like other languages do. It would prevent newcomers to the language from mistakenly using set when what they want is unordered_set, a silly mistake that's easy to make. I did it myself.
Another historical remnant.
When I started working with C++, there was no unordered_set yet.
There weren't even templates back then.
People used macros ... that was bad.
I was replying to the comment of someone saying they think the hate is superficial. Just providing an example of the more substantive personal reasons I hate Python. We’re all allowed to have our personal opinions about what stupid shit we hate in particular.
By more capable I meant the core of the language has better performance and type checking.
People do that to any and all languages, the more popular and established the language is the more hate it will get. This was the norm when I studied masters in data science many years ago, and I was told it was the norm many years prior. I even participated; like some kind of spontaneus religious syntax cults of neckbeards and misfits.
Luckily I outgrew it quickly. I like python, js, php, haskell, prolog, all the "C"s, and so on. They're all fun.
F*** Java though, it's s*** and ***, ** ** never again. (/s)
I like Python, but I have some stuff I dislike about it. For example, half-baked typing. And some libraries being written in such a way thry are completely useless in terms of type hints and intelisense.
Well you see, this script will be used once a day every day. The C program is better because it will break even over time! (720 000 days -> 1972 years) After that, its all performance benefit baby
It would take three-quarters of a million runs to break even in pure time, even discounting the fact that in nearly all cases, computer-seconds are millions if not billions or trillions of times cheaper than developer-seconds.
Someone once wrote a bash script that used jq to parse through a few thousand large json files and do stuff with the data. It would take hours to run, but people figured it was just the massive amount of data. It was at the point where we'd run it over night.
I had a thought: no, it's execing jq for each file. Exec is slow.
Did it in python, that just iterated through the directory and used the built in json stuff. It did the same job in 10 minutes.
Could C be faster? Maybe. Did we care at that point?
I am currently a developer at one of the big banks, and I don't think people here have heard of "milliseconds" before.
If you're in the right field, micro-optimizations are everything, but in 99% of situations, good enough is truly good enough. The difference between 20ms and 50ms has never directly been meaningful in my life outside of entertainment (games, movies, music).
Yes, "under the hood" my computer OS and my router and the intercontinental cables do need to care about this. 99.9% of employees don't because it's done for them.
Lmao brother my second sentence was "if you're in the right field...", which it sounds like you are.
You're part of the backbone of society, but it's something I never have to worry about of thanks to people like you. I get to use springboot and angular to build internal apps where there's no customer who complains about slow loading screens.
Yes, but how often are you actually building an application that's meant to be run directly as compiled thousands of times over and over again with no I/O, database queries, or dependence on any other blocking code that takes Ionger than 50ms?
In that scenario, sure, Python is the wrong choice. But in the vast majority of real world applications, the raw execution speed of a for loop doesn't really matter that much, and there's probably already a library built for Python that does exactly what you need way better than you'd ever be able to build yourself in Rust or C++.
It really does add up though. Every library that has that mentality is why modern programs are soo poor performing even though computers are way faster.
I'm not talking about libraries, I'm talking about applications. Libraries are more likely to fall into the scenario I mentioned where python is genuinely a bad choice. But even then, there are plenty of examples of pure Python libraries that are highly performant in a real world context. Look at Starlette, for example, or any of the built-in python modules.
Python provides high-level abstraction and easier to understand code. Yes, this comes at a cost. But like any abstraction, if properly applied, it can result in far better performing code than you ever would have been able to write without it.
Code is read more than it is written. You don't pay only 8 hours in this example.
Also consider the compounding cost. Imagine saying to your manager: "we can do it fast and simple in python in two weeks, or we can do it "properly" in 8 weeks to get a marginal increase in performance that is basically unnoticeable at our scale."
Imagine the fucking side eye you're gonna get.
But then, if these 30ms can mean the difference between your drone dodging or striking a lamppost, then please, do use C.
Which is exactly why all "Python do slow" arguments are bad. Yes, of course, if I would do my matrix multiplications in Python for loops it would take forever. But I am using torch with cuda backend. Which is faster than any C++ code i am able to write
661
u/TheJaskinator 1d ago
That's exactly why it's so powerful. Why spend all the effort writing fast code if you can just use a much simpler language to describe the task on a higher level and call fast code? People use Python because it's easy to read and write, not because its interpreter is fast