3 ms·

Python needs to be in less places not more. I believe Python has done more harm than good to the industry. Its by nature very inefficient, it leads you in the

by bnchrch 17d ago

Python needs to be in less places not more. I believe Python has done more harm than good to the industry. Its by nature very inefficient, it leads you in the direction to some very poor abstractions (inheritance, monkey patching, mixins etc) and as a result code that is very prone to subtle bugs and issues. It deserves all the love it gets as an approachable language, but it deserves a lot more flack for everything else.

skeledrew 16d ago
Big disagree. I've been following this project since it's early days, and have made a few projects based on it. I haven't been bitten by any "inefficiencies" in such a way that'd make me give up the language. And at this very moment I'm working on what's essentially a Python REPL that can build and return Flet controls (as well as the traditional string result), making writing and running adhoc native "applets" fully on mobile a possibility (haven't seen anything else that does this).
- noufalibrahim 16d ago
  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 16d ago
      I don’t think the parent comment was complaining about the compiler backend.
      - pjmlp 16d 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 16d 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 16d 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 16d 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.
deleted 16d ago
[deleted]
deleted 16d ago
[deleted]
unsungNovelty 16d ago
But when it comes to GUI toolkits, which of them are efficient? React Native, Tauri, Electron. I don't see a efficient one other than Native toolkits. Even they have their own problems. PS: Loved your website's (https://ben.church/ https://ben.church/) messaging for different audiences. Especially the "My Wife" one. Gave me a good laugh. :)
IshKebab 16d ago
I agree. They got some things right - the indentation based syntax is quite approachable even if it breaks down quite quickly (e.g. `lambda`), and infinite precision integers are fantastic. But it's soooooo slow, tooling was abysmal until uv came on the scene (which some people still don't use), it has a ton of old janky APIs, and features like implicit bool coercion. I wish there was a popular scripting language that was good. Modern robust semantics, infinite precision integers, static typing, good tooling, easy to embed. As far as I can tell it doesn't exist. Roto is the closest I've seen but it's moderately domain specific and doesn't have arbitrary precision integers.

by bnchrch 17d ago

skeledrew 16d ago

Big disagree. I've been following this project since it's early days, and have made a few projects based on it. I haven't been bitten by any "inefficiencies" in such a way that'd make me give up the language. And at this very moment I'm working on what's essentially a Python REPL that can build and return Flet controls (as well as the traditional string result), making writing and running adhoc native "applets" fully on mobile a possibility (haven't seen anything else that does this).

noufalibrahim 16d ago
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 16d ago
    I don’t think the parent comment was complaining about the compiler backend.
    - pjmlp 16d 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 16d 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 16d 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 16d 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.

deleted 16d ago

[deleted]

deleted 16d ago

[deleted]

unsungNovelty 16d ago

But when it comes to GUI toolkits, which of them are efficient? React Native, Tauri, Electron. I don't see a efficient one other than Native toolkits. Even they have their own problems. PS: Loved your website's (https://ben.church/ https://ben.church/) messaging for different audiences. Especially the "My Wife" one. Gave me a good laugh. :)

IshKebab 16d ago

I agree. They got some things right - the indentation based syntax is quite approachable even if it breaks down quite quickly (e.g. `lambda`), and infinite precision integers are fantastic. But it's soooooo slow, tooling was abysmal until uv came on the scene (which some people still don't use), it has a ton of old janky APIs, and features like implicit bool coercion. I wish there was a popular scripting language that was good. Modern robust semantics, infinite precision integers, static typing, good tooling, easy to embed. As far as I can tell it doesn't exist. Roto is the closest I've seen but it's moderately domain specific and doesn't have arbitrary precision integers.