I find Python is quick for the first 30 minutes. If you need any kind of libraries, or assistance from an IDE, or a distribution build, or you’re more familiar with another language, then it isn’t quicker.
It does, but the lack of static typing means it is more difficult to interact with foreign code (correctly).
When I pull in a library in a JVM language or Rust etc., I quickly glance at the documentation to get a rough idea of the entrypoint for the library.
Like, let’s say I want to create a .tar file, then the short “Writing an archive” example tells me all I need to know to get started: https://crates.io/crates/tar
If I need to find out more, like how to add a directory, then having the tar Builder initialized is enough for me to just ask my code completion. It will tell me the other available functions + their documentation + what parameters they accept.
If I make a mistake, the compiler will immediately tell me.
In Python, my experience was completely different. Pulling in a library often meant genuinely reading through its documentation to figure out how to call it, because the auto-completion was always unreliable at best.
Some libraries’ functions wouldn’t even tell you what types you’re allowed to feed into them, nor what type they return, and not even even diving into their code would help, because they just never had to actually specify it.
PyCharm a super powerful IDE, VSCode has tons of Python extensions that L rival PyCharm’s functionality, lots of other IDEs have decent python support
Yes, PyCharm is a super powerful IDE when compared to Nodepad++. But it’s a trashcan fire compared to IntelliJ or even the much younger RustRover.
Half the time it can’t assist you, because no one knows what types your code even has at that point.
The other half of the time, it can’t assist you, because, for whatever reason, the Python interpreter configured in it can’t resolve the imports.
And the third half of the time, it can’t assist you, because of what I already mentioned above, that the libraries you use just don’t specify types.
These are problems I’ve encountered when working on a larger project with multiple sub-components. It cost us so much time and eventually seemed to just be impossible to fix, so I ended up coding in a plain text editor, because at least that wouldn’t constantly color everything red despite there being no errors.
These problems are lessened for smaller projects, but in that case, you also don’t need assistance from an IDE.
or a distribution build
Not sure exactly what you mean by this
What I mean by that is that Python tooling is terrible. There’s five different ways to do everything, which you have to decide between, and in the end, they all have weird limitations (which is probably why four others exist).
or you’re more familiar with another language
Yeah this can be said about any language. “You’re quickest in the language you’re most familiar with”. That’s basically a tautology.
Yes. That is all I wanted to say by that. People just often claim that Python is a great prototyping language, to the point where the guy I was responding to, felt they’re doing the wrong thing by using the familiar tool instead. I’m telling them, they’re not.
Look, it’s fine if you prefer other languages to python, I won’t besmirch anyone’s preferences. But literally everything in your post exists in nearly every programming language (minus some of the typing stuff, I’ll give you that, but it’s getting a lot better). Like, every language has some learning curve to setting up tooling, or configuring your IDE the way you like it, or learning how to navigate documentation so that it’s useful, or trying to decide on one of the multiple ways of doing things. I guarantee, as someone with limited experience with Java, I’d have a difficult time setting up and using IntelliJ, and figuring out which build/packaging system I need to use, and figuring out how to use whatever libraries I need, simply because I’m unfamiliar with the ecosystem. That’s all you’re describing - the initial learning curve in getting familiar with a new language. Which is why I pointed out all the things I pointed out. It’s where I start when I’m introducing developers to python.
I find Python is quick for the first 30 minutes. If you need any kind of libraries, or assistance from an IDE, or a distribution build, or you’re more familiar with another language, then it isn’t quicker.
PyPI has a huge selection of libraries
PyCharm a super powerful IDE, VSCode has tons of Python extensions that L rival PyCharm’s functionality, lots of other IDEs have decent python support
Not sure exactly what you mean by this
Yeah this can be said about any language. “You’re quickest in the language you’re most familiar with”. That’s basically a tautology.
Oh boy, you really wanna talk about it?
It does, but the lack of static typing means it is more difficult to interact with foreign code (correctly).
When I pull in a library in a JVM language or Rust etc., I quickly glance at the documentation to get a rough idea of the entrypoint for the library.
Like, let’s say I want to create a .tar file, then the short “Writing an archive” example tells me all I need to know to get started: https://crates.io/crates/tar
If I need to find out more, like how to add a directory, then having the tar
Builderinitialized is enough for me to just ask my code completion. It will tell me the other available functions + their documentation + what parameters they accept.If I make a mistake, the compiler will immediately tell me.
In Python, my experience was completely different. Pulling in a library often meant genuinely reading through its documentation to figure out how to call it, because the auto-completion was always unreliable at best.
Some libraries’ functions wouldn’t even tell you what types you’re allowed to feed into them, nor what type they return, and not even even diving into their code would help, because they just never had to actually specify it.
Yes, PyCharm is a super powerful IDE when compared to Nodepad++. But it’s a trashcan fire compared to IntelliJ or even the much younger RustRover.
Half the time it can’t assist you, because no one knows what types your code even has at that point.
The other half of the time, it can’t assist you, because, for whatever reason, the Python interpreter configured in it can’t resolve the imports.
And the third half of the time, it can’t assist you, because of what I already mentioned above, that the libraries you use just don’t specify types.
These are problems I’ve encountered when working on a larger project with multiple sub-components. It cost us so much time and eventually seemed to just be impossible to fix, so I ended up coding in a plain text editor, because at least that wouldn’t constantly color everything red despite there being no errors.
These problems are lessened for smaller projects, but in that case, you also don’t need assistance from an IDE.
What I mean by that is that Python tooling is terrible. There’s five different ways to do everything, which you have to decide between, and in the end, they all have weird limitations (which is probably why four others exist).
Yes. That is all I wanted to say by that. People just often claim that Python is a great prototyping language, to the point where the guy I was responding to, felt they’re doing the wrong thing by using the familiar tool instead. I’m telling them, they’re not.
Look, it’s fine if you prefer other languages to python, I won’t besmirch anyone’s preferences. But literally everything in your post exists in nearly every programming language (minus some of the typing stuff, I’ll give you that, but it’s getting a lot better). Like, every language has some learning curve to setting up tooling, or configuring your IDE the way you like it, or learning how to navigate documentation so that it’s useful, or trying to decide on one of the multiple ways of doing things. I guarantee, as someone with limited experience with Java, I’d have a difficult time setting up and using IntelliJ, and figuring out which build/packaging system I need to use, and figuring out how to use whatever libraries I need, simply because I’m unfamiliar with the ecosystem. That’s all you’re describing - the initial learning curve in getting familiar with a new language. Which is why I pointed out all the things I pointed out. It’s where I start when I’m introducing developers to python.
I won’t feel bad about it then, lol. At least not until I’m collabing on something and they want to use Python.