4 ms·

Hindsight is 20/20 but if the Python folks knew how long and bad the 2 to 3 transition would be, they probably would've committed to a much bigger facelift on t

Hindsight is 20/20 but if the Python folks knew how long and bad the 2 to 3 transition would be, they probably would've committed to a much bigger facelift on the interpreter internals too. 12 year transition and single threaded performance is still abysmal and it has a few painful transitions left to get to real multi-threading. As kind as one should be with opensource development, at some point is it fair to call it a very poorly managed language?

lacker 3y ago
Nah, it's not poorly managed. Python has a lot of problems. But they are all problems that stem from Python's success. The worst parts of Python are the parts that are hard to change because Python is so popular, so the ecosystem is really large, so every sort of change becomes harder due to backward incompatibility.
- tyree731 3y ago
  One of Python’s most serious issues is that it is one of the slowest programming languages actively developed and used today, if it isn’t the slowest outright. This isn’t due to its success, this is due to the language’s performance having been deemed not a priority until somewhat recently.
  - Daishiman 3y ago
    No, this is definitely a key to its success. A simple C implementation allows everyone and their mother to hack at it and interface with C libraries and add try features and evolve the language through endless PEPs. Compare Python's language evolution to Java's abysmally slow language evolution because every new feature has to be implemented in a way that works with the JVM's JIT-compatible speed hacks. A _ton_ of very useful things Java could have done simply cannot be done because you can't work against the grain of the JVM. If Python's backward-compatibility is a pain, you have no idea how bad it is in the JVM (see how all the JVM's caveats have hobbled the semantics of generics as a good example). Not providing the end users any guarantees about performant code means that coders offload the performant areas to libraries that use languages built for performance, keeping that complexity outside of the interpreter and language.
    - parhamn 3y ago
      Genuinely curious, I don't know much about java. But if the JVM is good enough to implement full way-more-performant-than-python languages like scala/kotlin, shouldn't it technically be possible to progress the language without mucking with the JVM internals at all?
      - Daishiman 3y ago
        It’s been tried but dynamic languages are not very well suited to the JVM, but progress has been achieved with things like ‘invokedynamic’. The finer issues have to do with things like numeric representations, C bindings, class loading etc. still there are implementations of Python and Ruby on the JVM but they’re not especiallY popular as you can’t run the big libraries.
  - LtWorf 3y ago
    Yeah, used to be that if it made the interpreter less legible or straightforward it wouldn't get merged.
deleted 3y ago
[deleted]
jeremycarter 3y ago
Yes, you're correct. All these years and multiprocessing is still abysmal. I think people are too quick to defend Python. Its important to look at this objectively without bias.
- shrimpx 3y ago
  Python is a nice language with a shitty implementation. The ergonomics and productivity gain of the “nice language” part keeps winning over the other part.
  - xapata 3y ago
    Some of that "shit" was also a competitive advantage in the early days of the language.
- paulddraper 3y ago
  > All these years and multiprocessing is still abysmal. Shrug. Is it really that much worse than JavaScript or PHP? I mean, maybe they are or have been abysmal, but at least Python is in popular company.
FridgeSeal 3y ago
At what point do we make a language that’s syntactically identical to Python, but designed from the ground up to have better performance and threading support and just have projects that want performance + Python syntax to that, because clearly the current Python is flailing at multiple goals at once and achieving none of them.
- kmod 3y ago
  This has been done! Many times, most recently with Mojo. It sounds like you're the target user but don't use them, so if you're interested you could help them out by telling them specifically how they don't meet your needs
  - FridgeSeal 3y ago
    Nah I’ve given up on Python wholesale these days, and don’t operate in AI stuff anymore either, so not a lot of need for any of the current Python specific libs. Basically everything I write for work or hobby is all Rust now , but I’ve written more than enough Python that I’m still interested enough to follow the developments from a distance. :)
  - fulafel 3y ago
    Yep. The .NET and JVM versions also had hopes about eventual CPython-overtaking speed back in the day.
- dist-epoch 3y ago
  The problem was never the language (see PyPy), but the C-extensions.
  - Too 3y ago
    Imagine if one could eliminate the need for C-extensions in the first place.
    - Daishiman 3y ago
dist-epoch 3y ago
> Hindsight is 20/20 but if the Python folks knew how long and bad the 2 to 3 transition would be It was predictable and peopled commented at the time. Perl 5/6 was given as an example. And when it became apparent that nobody was switching, it still took about 5 years until they tried making it easier.

lacker 3y ago

Nah, it's not poorly managed. Python has a lot of problems. But they are all problems that stem from Python's success. The worst parts of Python are the parts that are hard to change because Python is so popular, so the ecosystem is really large, so every sort of change becomes harder due to backward incompatibility.

tyree731 3y ago
One of Python’s most serious issues is that it is one of the slowest programming languages actively developed and used today, if it isn’t the slowest outright. This isn’t due to its success, this is due to the language’s performance having been deemed not a priority until somewhat recently.
- Daishiman 3y ago
  No, this is definitely a key to its success. A simple C implementation allows everyone and their mother to hack at it and interface with C libraries and add try features and evolve the language through endless PEPs. Compare Python's language evolution to Java's abysmally slow language evolution because every new feature has to be implemented in a way that works with the JVM's JIT-compatible speed hacks. A _ton_ of very useful things Java could have done simply cannot be done because you can't work against the grain of the JVM. If Python's backward-compatibility is a pain, you have no idea how bad it is in the JVM (see how all the JVM's caveats have hobbled the semantics of generics as a good example). Not providing the end users any guarantees about performant code means that coders offload the performant areas to libraries that use languages built for performance, keeping that complexity outside of the interpreter and language.
  - parhamn 3y ago
    Genuinely curious, I don't know much about java. But if the JVM is good enough to implement full way-more-performant-than-python languages like scala/kotlin, shouldn't it technically be possible to progress the language without mucking with the JVM internals at all?
    - Daishiman 3y ago
      It’s been tried but dynamic languages are not very well suited to the JVM, but progress has been achieved with things like ‘invokedynamic’. The finer issues have to do with things like numeric representations, C bindings, class loading etc. still there are implementations of Python and Ruby on the JVM but they’re not especiallY popular as you can’t run the big libraries.
- LtWorf 3y ago
  Yeah, used to be that if it made the interpreter less legible or straightforward it wouldn't get merged.

deleted 3y ago

[deleted]

jeremycarter 3y ago

Yes, you're correct. All these years and multiprocessing is still abysmal. I think people are too quick to defend Python. Its important to look at this objectively without bias.

shrimpx 3y ago
Python is a nice language with a shitty implementation. The ergonomics and productivity gain of the “nice language” part keeps winning over the other part.
- xapata 3y ago
  Some of that "shit" was also a competitive advantage in the early days of the language.
paulddraper 3y ago
> All these years and multiprocessing is still abysmal. Shrug. Is it really that much worse than JavaScript or PHP? I mean, maybe they are or have been abysmal, but at least Python is in popular company.

FridgeSeal 3y ago

At what point do we make a language that’s syntactically identical to Python, but designed from the ground up to have better performance and threading support and just have projects that want performance + Python syntax to that, because clearly the current Python is flailing at multiple goals at once and achieving none of them.

kmod 3y ago
This has been done! Many times, most recently with Mojo. It sounds like you're the target user but don't use them, so if you're interested you could help them out by telling them specifically how they don't meet your needs
- FridgeSeal 3y ago
  Nah I’ve given up on Python wholesale these days, and don’t operate in AI stuff anymore either, so not a lot of need for any of the current Python specific libs. Basically everything I write for work or hobby is all Rust now , but I’ve written more than enough Python that I’m still interested enough to follow the developments from a distance. :)
- fulafel 3y ago
  Yep. The .NET and JVM versions also had hopes about eventual CPython-overtaking speed back in the day.
dist-epoch 3y ago
The problem was never the language (see PyPy), but the C-extensions.
- Too 3y ago
  Imagine if one could eliminate the need for C-extensions in the first place.
  - Daishiman 3y ago

dist-epoch 3y ago

> Hindsight is 20/20 but if the Python folks knew how long and bad the 2 to 3 transition would be It was predictable and peopled commented at the time. Perl 5/6 was given as an example. And when it became apparent that nobody was switching, it still took about 5 years until they tried making it easier.