3 ms·

I'm in the middle. I've been using Python since the early 2.x series. The good parts are that the inbuilt data structures and their apis are efficient and clea

I'm in the middle. I've been using Python since the early 2.x series. The good parts are that the inbuilt data structures and their apis are efficient and clean enough to write code that's mostly readable. Most of the heavy lifting is done in hand tuned C and performance intensive external modules are also written in C. There are several good projects that are written using it and while it's not theoretically perfect, it's useful enough. Like Stroustrup said - there are 2 kinds of the languages, ones that everyone complains about and ones that no one uses. The bad parts are that it's very easy to use. Almost in a Visual Basic "producing crap just takes a squeeze" kind of way. It opened up programming to a lot of people (the genesis of Python was in the CP4E project - where this was the aim). This resulted in a lot of bad patterns, inefficient code, badly written but popular libraries. Also, the indentation idiom and other restrictions resulted in a lot of convoluted APIs.There's also a lot of baggage from the pre multi-core CPU era (threading etc.). I still think of it as a great glue language. If there are libraries that are fast and can run well, a good FFI or wrapper which Python can leverage will amplify the reach and usability of the library. On the overall, a language that's older than the venerable Java which people are still using (and hence complaining about) speaks to its longevity. So, atleast by that definition, it is successful.

pjmlp 16d ago
At least BASIC was originally designed as compiled language, only the 8 bit home computers made interpreter versions more widely known due to their hardware limitations. Starting with version 5, Visual Basic "crap" was using the same compiler backend as Visual C++.
- spider-mario 15d ago
  I don’t think the parent comment was complaining about the compiler backend.
  - pjmlp 15d ago
    That is a side effect from Python adoption at scale in the form of CPython, even though there is PyPy crying on its little corner for lack of attention. The slowness of Python based software, and the continuous rewrite of Python into C, C++, and nowadays Rust.
    - skeledrew 15d ago
      > slowness of Python based software I know of very few cases of this. For the most part I find the "slow" to be in the network/IO things. Unless one is doing heavy matrix math or something similar in pure Python, which I'd seriously question.
      - pjmlp 15d ago
        Some people write full blown desktop software in Python, and then get amazed how fast it flies when rewritten into a compiled language.
        skeledrew 15d ago
        This sounds like my experience switching from conda to uv. The speed seriously blew my mind, and sometimes still does today. But then I think about the tradeoffs: I've encountered issues with uv-packaged Python because they've optimized the heck out of it, like a few months ago I was working with tkinter and things were failing hard on ways I couldn't understand, then I switched to conda for those projects and... things just worked. Also package management isn't a thing that's regularly run, so while it's blazingly fast, it really doesn't have much effect on overall dev time. If it was just about speed, I would've stuck with conda, but uv offers a lot of actual valuable features and simplified some of my flows, so it's now my main Python project manager and conda kept as fallback. It's essentially the same re regular desktop software. The performance for a particular bit may be nice, but it really doesn't impact the overall experience as one can only move at a certain speed as a user, and there are still those other bottlenecks. Like with my current project that's using Flet, the UI is extremely snappy and a joy in every way, but the networking bit (using iroh, which is implemented in Rust) has been a constant pain that I have to keep returning to. The speed of Rust is doing 0 to help anything, and I feel like it would've been less painful if iroh was actually implemented in Python as then I could dig into the source to see what's up and tweak to fit my circumstances, instead of dealing with essentially an immutable black box.

pjmlp 16d ago

At least BASIC was originally designed as compiled language, only the 8 bit home computers made interpreter versions more widely known due to their hardware limitations. Starting with version 5, Visual Basic "crap" was using the same compiler backend as Visual C++.

spider-mario 15d ago
I don’t think the parent comment was complaining about the compiler backend.
- pjmlp 15d ago
  That is a side effect from Python adoption at scale in the form of CPython, even though there is PyPy crying on its little corner for lack of attention. The slowness of Python based software, and the continuous rewrite of Python into C, C++, and nowadays Rust.
  - skeledrew 15d ago
    > slowness of Python based software I know of very few cases of this. For the most part I find the "slow" to be in the network/IO things. Unless one is doing heavy matrix math or something similar in pure Python, which I'd seriously question.
    - pjmlp 15d ago
      Some people write full blown desktop software in Python, and then get amazed how fast it flies when rewritten into a compiled language.
      - skeledrew 15d ago
        This sounds like my experience switching from conda to uv. The speed seriously blew my mind, and sometimes still does today. But then I think about the tradeoffs: I've encountered issues with uv-packaged Python because they've optimized the heck out of it, like a few months ago I was working with tkinter and things were failing hard on ways I couldn't understand, then I switched to conda for those projects and... things just worked. Also package management isn't a thing that's regularly run, so while it's blazingly fast, it really doesn't have much effect on overall dev time. If it was just about speed, I would've stuck with conda, but uv offers a lot of actual valuable features and simplified some of my flows, so it's now my main Python project manager and conda kept as fallback. It's essentially the same re regular desktop software. The performance for a particular bit may be nice, but it really doesn't impact the overall experience as one can only move at a certain speed as a user, and there are still those other bottlenecks. Like with my current project that's using Flet, the UI is extremely snappy and a joy in every way, but the networking bit (using iroh, which is implemented in Rust) has been a constant pain that I have to keep returning to. The speed of Rust is doing 0 to help anything, and I feel like it would've been less painful if iroh was actually implemented in Python as then I could dig into the source to see what's up and tweak to fit my circumstances, instead of dealing with essentially an immutable black box.