cross-posted from: https://piefed.jeena.net/post/33729
Time codingπ€ runtime: the other way aroundπ
this post was submitted on 18 Aug 2024
66 points (92.3% liked)
Python
1914 readers
3 users here now
A community for talking about the Python programming language.
founded 1 year ago
MODERATORS
async enters the chat
"Hardware cycles are cheap. Wetware cycles are expensive."
- Paraphrased from something I once heard Jacob Kaplan-Moss say but don't remember his exact wording at PyCon many moons ago.
Then why do Python people insist on having the programmer do so much stuff instead of letting a compiler do it?
Examples?
Verifying that your different pieces of code actually work together. With a static type system and similar compiler features you can lighten the mental load a lot compared to languages like Python where you need to keep it all in your head.
Python has (optional) types now.
The problem with optional typing is that it has all the downsides of both but gives you very little of the advantages of a strong static type system, e.g. being able to rely on types catching certain kinds of errors when refactoring because you don't know for sure that all APIs have types. It is really nothing more than an admission by dynamically typed languages that static types are so useful you can't really do without them while at the same time not admitting that it might be best to move to a language and library ecosystem that was designed with static types from the start.
Such as?
...and 5 min in chatgpt. Only you spend 3 days making it work because you never understood coding in the first place.
And honestly, even if you do understand coding, you'll probably spend more time testing the code than it would've taken to write and test it yourself.
We had an applicant use AI in an interview, and they made the same mistake twice in 5 minutes, because that's the code the model spat out. This was someone with several years of experience (I think they even ran a team for a couple years), so they certainly understood coding, they just trusted their tools too much. We even gave them a softball question, "How confident are you that your code is correct? What would you need to feel more confident?," and their answer was, "I'm 100% confident that it's correct" when they should have answered, "I'd need to write some unit tests."
I love C and Assembly as much as the next guy, but implementation time to the optimal solution matters.
And something between 1 and 300 minutes in Haskell.
...and often 10 minutes in bash
Rust:
2 days, most of it fighting the compiler.
I did a POC in Rust vs Python. Rust took longer to write, would be harder to maintain by our team, and with numba, the performance difference was small. So we went with Python.
If you are fighting the compiler you are probably trying to write unidiomatic code (maybe Python-like code?).
Or you're just new. This is, afterall, a Python community.