7 ms·

Why not "simply" admit that Python and it's ecosystem while broad, are an absolute clusterfuck?

by NuSkooler 4y ago

whalesalad 4y ago
Because that’s not at all the case and your rhetoric is what perpetuates the false image.
- stathibus 4y ago
  Yeah it totally is, and people who pretend it's not are the problem. Somehow we ended up in a state where step one of doing anything new with python is to fire up an empty docker container. And I'm awfully tired of folks in the "python community" blaming the victims of the mess they made.
  - nonethewiser 4y ago
    > Somehow we ended up in a state where step one of doing anything new with python is to fire up an empty docker container. This approach seems insane but correct.
    - BiteCode_dev 4y ago
      No, use the procedure described in the previous article. It will be less hard than using docker.
- JohnFen 4y ago
  As a user, it kinda is. My recent example: last week, I was installing a new program that uses some python scripts during its operation. I could not get those scripts to run. I knew it was because of the usual python problem of the scripts not matching the version of python that was executing them, but figuring out how to fix that took me a full day. Just to make Python work. Not even as a dev. Wearing my user hat, this is a clusterfuck. There is no other language that I am exposed to that presents this sort of problem, and this is a very common issue with Python. This is why I start to get sweaty any time that I'm using software that involves Python. It turns into a crapshoot and half the time, it's going to cost me a lot of time and stress. > perpetuates the false image. You can believe it's a false image if you like, but there are a whole lot of end user experiences that indicate it's very real.
  - BiteCode_dev 4y ago
    Use the procedure described in the previous article. It will help with exactly that.
    - JohnFen 4y ago
      Right. But the point is that if I have to have special knowledge or do tricky things with Python just to get end-user software to work right, that's a problem. You should just be able to install the software and have it work right. End-users who are not so technically oriented would never even know to look for those instructions, let alone be comfortable following them. Python is the only language I've encountered that causes this sort of trouble for ordinary end-users. As a dev, I find this frustrating because the python scripts in question are clearly only "glue" in the first place. That's a lot of burden to put on the end user for just glue. As for my issue, I did make it work in the end. I'm 90% sure I didn't do it in the right way and it will cause me problems at some point in the future, but that will be a problem for future me.
      - Danjoe4 4y ago
        I am a huge fan of python and have rebutted some of the criticisms in this thread. I would also avoid shipping python to users because of the issue you point out. If it couldn't be avoided I'd probably package the version of python I want them to use, with my software.
        tough 4y ago
        python apps as .exe's is all you need to know exist to recognise the cluster fuck from miles afar
        pepa65 4y ago
        If those .exe's (or Linux/OSX binaries) would work as intended, than maybe that is a solution..!
      - 4y ago
- NuSkooler 4y ago
  All of these wonky tools are written for and by Python developers who themselves trip over the insanity. I think I have enough evidence after watching this go down for over a decade.
- DemocracyFTW2 4y ago
  In my experience 'clusterfuck' is not a fair description of the packaging and import system. 'Fractally intertwined half-broken huge ball of macaroni with spaghetti nested inside' is more accurate.
  - BiteCode_dev 4y ago
    Believe it or not, it improved tremendously in the last 10 years: - easy_install, distutils and eggs were deprecated - ensurepip and venv were introduced - the whole wheel ecosystem flourished - a new dependency resolver was introduced to python But: - a lot of noise has accumulated. Hence the procedure in the previous article, to avoid the traps from all that noise and go back to what usually works. - we have a long way to go, but it's not something easily fixed (hence the conclusion of the current article explaining why it's going to take a long time to get better).
    - AtlasBarfed 4y ago
      "we have a long way to go" Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages. Something, hopefully, will come out of webassembly. Otherwise, the last decade only saw the rise of two fundamentally flawed languages as the most popular ones. Ruby losing to both was not a good thing. And I'm not even a Ruby programmer! I hated the language back in the Rails vs Java days. But it is impossible to deny that great software came out of Ruby. Javascript and Python has produced no great software, just ponderous stacks of crappy code and poorly organized libraries. They are popular because they are used for throwaway web applications and throwaway scientific / non-programmer code, and it shows. The fact that golang is what is producing new "good" software: a language that is intentionally bad, as opposed to python and javascript being worse because of cruft accumulation or Eich writing it a weekend, is also not a great sign but it's not the step backward that javascript and python are.
      - belval 4y ago
        > Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages. People writing in JS are usually techies who could/would migrate. People writing in Python are on a wide spectrum that goes from "one-step-above-matlab" to "know-it-all-c-wizard". You won't actually get all these people to move on any reasonable timeframe. HN is biased because we tend to love tech and a lot of us know several languages, but Python is much more democratized. My friends in physics, biotech, mechanical engineering, basically everyone in STEM is using Python and to them it's a tool that took a lot of time to learn and they won't drop it all because dependencies are hard.
throwawaaarrgh 4y ago
Stockholm syndrome?
klibertp 4y ago
Because when you try to manage dependencies with Gradle on Android you realize that it could be worse. Much, much, worse. These are the languages and package managers I have experience with: - JavaScript and npm - Python and pip/conda - Kotlin and Gradle - Scala and mill - Common Lisp and quicklisp - Racket and raco - Raku and zef - Lua and luarocks - Elixir and mix - Haxe and haxelib - Rust and cargo - Nim and nimble - OCaml and opam - Smalltalk and Monti/Meta-cello; also Visual Works parcel manager - and a few others Out of all these, cargo, opam, mix, and zef are the only ones that are mostly working as intended. They're still a pain, but they're predictable and honest about their limitations. Everything else is just bad, to the point where it's a waste of time to think about which is the biggest and which are a bit less of a clusterfuck. For some of these I had to resort to building a chroot env with a copy of my system inside to convince them to compile and link against correct libraries. If that's not a clusterfuck, I don't know what is... Unless you were lucky to see something better than "mainstream state of the art" solutions, you won't realize how bad it actually is. At that point you start inventing yarns or poetries, adding layers on top of layers to paper over simplistic, hardcoded assumptions made by original authors 20-30 years ago, and go into denial when someone tells you that's not going to fix anything.

Why not "simply" admit that Python and it's ecosystem while broad, are an absolute clusterfuck?

whalesalad 4y ago

Because that’s not at all the case and your rhetoric is what perpetuates the false image.

stathibus 4y ago
Yeah it totally is, and people who pretend it's not are the problem. Somehow we ended up in a state where step one of doing anything new with python is to fire up an empty docker container. And I'm awfully tired of folks in the "python community" blaming the victims of the mess they made.
- nonethewiser 4y ago
  > Somehow we ended up in a state where step one of doing anything new with python is to fire up an empty docker container. This approach seems insane but correct.
  - BiteCode_dev 4y ago
    No, use the procedure described in the previous article. It will be less hard than using docker.
JohnFen 4y ago
As a user, it kinda is. My recent example: last week, I was installing a new program that uses some python scripts during its operation. I could not get those scripts to run. I knew it was because of the usual python problem of the scripts not matching the version of python that was executing them, but figuring out how to fix that took me a full day. Just to make Python work. Not even as a dev. Wearing my user hat, this is a clusterfuck. There is no other language that I am exposed to that presents this sort of problem, and this is a very common issue with Python. This is why I start to get sweaty any time that I'm using software that involves Python. It turns into a crapshoot and half the time, it's going to cost me a lot of time and stress. > perpetuates the false image. You can believe it's a false image if you like, but there are a whole lot of end user experiences that indicate it's very real.
- BiteCode_dev 4y ago
  Use the procedure described in the previous article. It will help with exactly that.
  - JohnFen 4y ago
    Right. But the point is that if I have to have special knowledge or do tricky things with Python just to get end-user software to work right, that's a problem. You should just be able to install the software and have it work right. End-users who are not so technically oriented would never even know to look for those instructions, let alone be comfortable following them. Python is the only language I've encountered that causes this sort of trouble for ordinary end-users. As a dev, I find this frustrating because the python scripts in question are clearly only "glue" in the first place. That's a lot of burden to put on the end user for just glue. As for my issue, I did make it work in the end. I'm 90% sure I didn't do it in the right way and it will cause me problems at some point in the future, but that will be a problem for future me.
    - Danjoe4 4y ago
      I am a huge fan of python and have rebutted some of the criticisms in this thread. I would also avoid shipping python to users because of the issue you point out. If it couldn't be avoided I'd probably package the version of python I want them to use, with my software.
      - tough 4y ago
        python apps as .exe's is all you need to know exist to recognise the cluster fuck from miles afar
        pepa65 4y ago
        If those .exe's (or Linux/OSX binaries) would work as intended, than maybe that is a solution..!
    - 4y ago
NuSkooler 4y ago
All of these wonky tools are written for and by Python developers who themselves trip over the insanity. I think I have enough evidence after watching this go down for over a decade.
DemocracyFTW2 4y ago
In my experience 'clusterfuck' is not a fair description of the packaging and import system. 'Fractally intertwined half-broken huge ball of macaroni with spaghetti nested inside' is more accurate.
- BiteCode_dev 4y ago
  Believe it or not, it improved tremendously in the last 10 years: - easy_install, distutils and eggs were deprecated - ensurepip and venv were introduced - the whole wheel ecosystem flourished - a new dependency resolver was introduced to python But: - a lot of noise has accumulated. Hence the procedure in the previous article, to avoid the traps from all that noise and go back to what usually works. - we have a long way to go, but it's not something easily fixed (hence the conclusion of the current article explaining why it's going to take a long time to get better).
  - AtlasBarfed 4y ago
    "we have a long way to go" Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages. Something, hopefully, will come out of webassembly. Otherwise, the last decade only saw the rise of two fundamentally flawed languages as the most popular ones. Ruby losing to both was not a good thing. And I'm not even a Ruby programmer! I hated the language back in the Rails vs Java days. But it is impossible to deny that great software came out of Ruby. Javascript and Python has produced no great software, just ponderous stacks of crappy code and poorly organized libraries. They are popular because they are used for throwaway web applications and throwaway scientific / non-programmer code, and it shows. The fact that golang is what is producing new "good" software: a language that is intentionally bad, as opposed to python and javascript being worse because of cruft accumulation or Eich writing it a weekend, is also not a great sign but it's not the step backward that javascript and python are.
    - belval 4y ago
      > Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages. People writing in JS are usually techies who could/would migrate. People writing in Python are on a wide spectrum that goes from "one-step-above-matlab" to "know-it-all-c-wizard". You won't actually get all these people to move on any reasonable timeframe. HN is biased because we tend to love tech and a lot of us know several languages, but Python is much more democratized. My friends in physics, biotech, mechanical engineering, basically everyone in STEM is using Python and to them it's a tool that took a lot of time to learn and they won't drop it all because dependencies are hard.

throwawaaarrgh 4y ago

Stockholm syndrome?

klibertp 4y ago

Because when you try to manage dependencies with Gradle on Android you realize that it could be worse. Much, much, worse. These are the languages and package managers I have experience with: - JavaScript and npm - Python and pip/conda - Kotlin and Gradle - Scala and mill - Common Lisp and quicklisp - Racket and raco - Raku and zef - Lua and luarocks - Elixir and mix - Haxe and haxelib - Rust and cargo - Nim and nimble - OCaml and opam - Smalltalk and Monti/Meta-cello; also Visual Works parcel manager - and a few others Out of all these, cargo, opam, mix, and zef are the only ones that are mostly working as intended. They're still a pain, but they're predictable and honest about their limitations. Everything else is just bad, to the point where it's a waste of time to think about which is the biggest and which are a bit less of a clusterfuck. For some of these I had to resort to building a chroot env with a copy of my system inside to convince them to compile and link against correct libraries. If that's not a clusterfuck, I don't know what is... Unless you were lucky to see something better than "mainstream state of the art" solutions, you won't realize how bad it actually is. At that point you start inventing yarns or poetries, adding layers on top of layers to paper over simplistic, hardcoded assumptions made by original authors 20-30 years ago, and go into denial when someone tells you that's not going to fix anything.