Python is quickly taking the crown for low-barrier to entry, slow, buggy code supported primarily by stackoverflow copy pastes from a never-ending supply of “data scientists”
Quickly seems like an overstatement; you've always been able to write low-barrier to entry, slow, buggy code. Is there a low-barrier language that doesn't end up with a lot of less-than-ideal code samples?
I support over a million lines of powershell. It's pretty hygienic, for the efforts of a hundred low-skill contributors.
The language has flaws. But the function parameters are an joy and incredibly powerful. The validation and type coercion is excellent. The functions are extremely composable.
Overall, it's the epitome of "pit of success".
The same team that has all this powershell also has about 50k lines of Python. The Python has the stench of swamp farts, so I don't think it's team skill that makes the powershell work so well.
Meh, Python really shines at I/O and gluing together C/C++/Fortran code. It's reasonably fast for most tasks, and if it isn't there are tools like Cython that make it pretty trivial to write Python code that achieves C-like execution speed (because it effectively compiles to C code).
I agree that Python is a great glue language (so are Perl and Python).
However, Python really doesn't shine when compared with other memory safe languages like Go, Rust, and Java.
Ultimately, Python is single-threaded by design. There are some hacks to get around this design contraint (multi-processing), but then you are adding an entire additional Python runtime to your system's memory for every "thread" you want to run. Even with asyncio, Python performs the worst when it comes to I/O.
I love Python, but it's important to understand that due to specific design considerations it is not and will likely never be a performant language.
If you can write code twice as fast then you'll write twice as many bugs.
Having been a C++ and python developer I see just as many footguns in both languages and have spent many many many hours dealing with slow, buggy code in either.
There's a lot of nice Python code out there, mostly written by disciplined and experienced systems people.
But I agree about the hordes of data scientists making copy and paste spaghetti. This is evidenced by companies deploying Jupyter notebooks in production, which essentially witnesses the fact that they've given up on getting data people to write quality production Python, and instead they treat their prototype spaghetti as sandboxed blackboxes that can be tested on inputs and deployed if they perform well enough.
robervin|4 years ago
psd1|4 years ago
The language has flaws. But the function parameters are an joy and incredibly powerful. The validation and type coercion is excellent. The functions are extremely composable.
Overall, it's the epitome of "pit of success".
The same team that has all this powershell also has about 50k lines of Python. The Python has the stench of swamp farts, so I don't think it's team skill that makes the powershell work so well.
ThePhysicist|4 years ago
bloblaw|4 years ago
However, Python really doesn't shine when compared with other memory safe languages like Go, Rust, and Java.
Ultimately, Python is single-threaded by design. There are some hacks to get around this design contraint (multi-processing), but then you are adding an entire additional Python runtime to your system's memory for every "thread" you want to run. Even with asyncio, Python performs the worst when it comes to I/O.
I love Python, but it's important to understand that due to specific design considerations it is not and will likely never be a performant language.
reference: https://medium.com/star-gazers/benchmarking-low-level-i-o-c-...
reedf1|4 years ago
Having been a C++ and python developer I see just as many footguns in both languages and have spent many many many hours dealing with slow, buggy code in either.
shrimpx|4 years ago
But I agree about the hordes of data scientists making copy and paste spaghetti. This is evidenced by companies deploying Jupyter notebooks in production, which essentially witnesses the fact that they've given up on getting data people to write quality production Python, and instead they treat their prototype spaghetti as sandboxed blackboxes that can be tested on inputs and deployed if they perform well enough.
ransom1538|4 years ago
dreyfan|4 years ago
ww520|4 years ago