3 ms·

There are two kinds of languages, ones that everyone complains about, and those that nobody uses.

by fooker 3y ago

devnullbrain 3y ago
Everyone uses Python
- spoiler 3y ago
  People complain about various python and its ecosystem's quirks all the time, though!
  - devnullbrain 3y ago
    You don't need to use its ecosystem at all to use it as a replacement for sh
- theonemind 3y ago
  I complain about Python all of the time. 1. seems to frequently get used for large products where people should really do strong static typing 2. Python 2 to 3 fiasco 3. Packaging and venvs and dependencies are a mess. 3a. versioning of dependencies. culturally handled in a slapdash kind of manner. 3b. Managing multiple versions of Python on my system, and multiple venvs per version. 4. not a functional language 5. Insanely, ridiculously slow compared to something like C. Slow even by the standards of scripting languages. 6. Python culture doesn't seem to acknowledge that regular users that don't care at all what language you used and want an executable, not a hot-glue build-your-own-environment hobby kit. 7. Pervasive culture of weak backward compat in libraries. 8. The pip devs are opinionated, and frankly user-hostile in my opinion, breaking backward UX convention, deprecating, general high-handed ivory-tower dev behavior. 9. I'd complain about the GIL, and a lot of people do, but I actually personally don't care. Maybe I covered it with the slow runtime and care indirectly. Every time I encounter something written in Python I just mentally groan and roll my eyes. I genuinely don't like Python. Some of what I enumerated obviously bleeds into culture and ecosystem, but in practical terms for practical use, that's not so cleanly separable from the language in a lot of cases. Perl was always great about backwards compat and documentation, Ruby had a strong web dev bent because of rails, blahblah.
  - devnullbrain 3y ago
    These are mostly complaints about Python the development language, not Python the sh alternative.
    - fooker 3y ago
      Python sucks as an sh alternative. And as not many people use it as an sh alternative, not many complaints about it. Something as simple as `./foo.sh file.txt | grep bar | tail -n1 | awk '{print($1)}'` would look ugly and convoluted in python.
chriswarbo 3y ago
Urgh, I hate this thought-terminating cliche. It makes no distinction between minor annoyances and major design flaws. About a decade ago I worked with someone who'd say this when a PHP project hit some ridiculous bug, and I'd suggest we maybe consider something else for future projects. Like, sure people complain that mixing tabs with spaces causes an invisible syntax error in Python; but at least it (a) has a dictionary datastructure, and (b) doesn't unavoidably convert some string keys into numbers, such that CSS colours like "112e33" become 112×10³³. (I thankfully don't use PHP anymore; inb4 "ackshually PHP7 is great"...)
- fooker 3y ago
  Your solution to hitting a bug in a tool is switching ecosystems and spending years building up your expertise? What happens when you hit another bug in the new ecosystem?
  - lolc 3y ago
    I may evaluate whether a platform is full of accidental complexity and decide to switch. This evaluation may be triggered by a failure caused by weird conversion rules yes.
  - chriswarbo 3y ago
    > Your solution to hitting a bug in a tool If only it were "a bug". Rather, there was a steady trickle of post-mortems for production issues which couldn't be explained-away as a lack of testing; which secure coding practices would not have prevented; which took multiple experienced developers a while to figure out, and whose behaviour surprised all of them; and which were unavoidably baked into the design decisions of the underlying technology. This was also in a team that purposefully focused on building small, task-specific, loosely-coupled systems. > is switching ecosystems and spending years building up your expertise? Meh, it's easy enough to jump between PHP, Perl, Python, Ruby, Javascript, etc. since their differences are pretty minimal. Indeed, their language roadmaps seem to be "copy each other's homework" (generators, async, etc.; JS even added a `class` keyword FFS!). Even for someone who's only experienced with one particular approach taken by some specific framework, there's probably a work-alike clone to be found in all of those languages. Heck, the current PHP advocates keep going on about how different PHP7/8 are from PHP4; in which case, it may be easier to jump ship to another interpreted, untyped, imperative, procedural/OO scripting language (which may also be more battle-hardened and stable than that new version of PHP!) It's certainly not like switching from, say, Mercury to Zig! Anecdatally: My first job was PHP programming, which I landed despite having never used it before; I was hired since I knew Python, I did fine. I got another PHP job a year later, whose interview included a written test. A few years later I learned that (a) its purpose was to check if candidates were lying about knowing PHP, by asking questions that exposed PHP's unique quirks and pitfalls; and (b) I'd apparently scored higher than anyone they'd interviewed before or since, despite only having used it for a year. In other words: some programming languages are so similar that switching between them may be easier than learning a new framework. > What happens when you hit another bug in the new ecosystem? My whole point is that this question is not answerable, precisely because "bug" is such a broad category. If the bug is a minor annoyance, we'd work around or avoid it; if it was more serious, but small, we'd maybe upstream a patch; if it was more difficult we'd maybe sponsor a core maintainer to work on it; etc. Presumably we wouldn't be hitting fundamental design problems, since our switching process would not land upon a notoriously flawed technology, cobbled-together by someone who "hates programming" and is "really, really bad at writing parsers"[1] (yet nevertheless proceeds to bake much of their language's semantics into the parser![2]) [1] https://en.wikiquote.org/wiki/Rasmus_Lerdorf https://en.wikiquote.org/wiki/Rasmus_Lerdorf [2] For example, all the syntax errors and ambiguities I listed at https://stackoverflow.com/a/24463174/884682 https://stackoverflow.com/a/24463174/884682

There are two kinds of languages, ones that everyone complains about, and those that nobody uses.

by fooker 3y ago

There are two kinds of languages, ones that everyone complains about, and those that nobody uses.

devnullbrain 3y ago

Everyone uses Python

spoiler 3y ago
People complain about various python and its ecosystem's quirks all the time, though!
- devnullbrain 3y ago
  You don't need to use its ecosystem at all to use it as a replacement for sh
theonemind 3y ago
I complain about Python all of the time. 1. seems to frequently get used for large products where people should really do strong static typing 2. Python 2 to 3 fiasco 3. Packaging and venvs and dependencies are a mess. 3a. versioning of dependencies. culturally handled in a slapdash kind of manner. 3b. Managing multiple versions of Python on my system, and multiple venvs per version. 4. not a functional language 5. Insanely, ridiculously slow compared to something like C. Slow even by the standards of scripting languages. 6. Python culture doesn't seem to acknowledge that regular users that don't care at all what language you used and want an executable, not a hot-glue build-your-own-environment hobby kit. 7. Pervasive culture of weak backward compat in libraries. 8. The pip devs are opinionated, and frankly user-hostile in my opinion, breaking backward UX convention, deprecating, general high-handed ivory-tower dev behavior. 9. I'd complain about the GIL, and a lot of people do, but I actually personally don't care. Maybe I covered it with the slow runtime and care indirectly. Every time I encounter something written in Python I just mentally groan and roll my eyes. I genuinely don't like Python. Some of what I enumerated obviously bleeds into culture and ecosystem, but in practical terms for practical use, that's not so cleanly separable from the language in a lot of cases. Perl was always great about backwards compat and documentation, Ruby had a strong web dev bent because of rails, blahblah.
- devnullbrain 3y ago
  These are mostly complaints about Python the development language, not Python the sh alternative.
  - fooker 3y ago
    Python sucks as an sh alternative. And as not many people use it as an sh alternative, not many complaints about it. Something as simple as `./foo.sh file.txt | grep bar | tail -n1 | awk '{print($1)}'` would look ugly and convoluted in python.

chriswarbo 3y ago

Urgh, I hate this thought-terminating cliche. It makes no distinction between minor annoyances and major design flaws. About a decade ago I worked with someone who'd say this when a PHP project hit some ridiculous bug, and I'd suggest we maybe consider something else for future projects. Like, sure people complain that mixing tabs with spaces causes an invisible syntax error in Python; but at least it (a) has a dictionary datastructure, and (b) doesn't unavoidably convert some string keys into numbers, such that CSS colours like "112e33" become 112×10³³. (I thankfully don't use PHP anymore; inb4 "ackshually PHP7 is great"...)

fooker 3y ago
Your solution to hitting a bug in a tool is switching ecosystems and spending years building up your expertise? What happens when you hit another bug in the new ecosystem?
- lolc 3y ago
  I may evaluate whether a platform is full of accidental complexity and decide to switch. This evaluation may be triggered by a failure caused by weird conversion rules yes.
- chriswarbo 3y ago
  > Your solution to hitting a bug in a tool If only it were "a bug". Rather, there was a steady trickle of post-mortems for production issues which couldn't be explained-away as a lack of testing; which secure coding practices would not have prevented; which took multiple experienced developers a while to figure out, and whose behaviour surprised all of them; and which were unavoidably baked into the design decisions of the underlying technology. This was also in a team that purposefully focused on building small, task-specific, loosely-coupled systems. > is switching ecosystems and spending years building up your expertise? Meh, it's easy enough to jump between PHP, Perl, Python, Ruby, Javascript, etc. since their differences are pretty minimal. Indeed, their language roadmaps seem to be "copy each other's homework" (generators, async, etc.; JS even added a `class` keyword FFS!). Even for someone who's only experienced with one particular approach taken by some specific framework, there's probably a work-alike clone to be found in all of those languages. Heck, the current PHP advocates keep going on about how different PHP7/8 are from PHP4; in which case, it may be easier to jump ship to another interpreted, untyped, imperative, procedural/OO scripting language (which may also be more battle-hardened and stable than that new version of PHP!) It's certainly not like switching from, say, Mercury to Zig! Anecdatally: My first job was PHP programming, which I landed despite having never used it before; I was hired since I knew Python, I did fine. I got another PHP job a year later, whose interview included a written test. A few years later I learned that (a) its purpose was to check if candidates were lying about knowing PHP, by asking questions that exposed PHP's unique quirks and pitfalls; and (b) I'd apparently scored higher than anyone they'd interviewed before or since, despite only having used it for a year. In other words: some programming languages are so similar that switching between them may be easier than learning a new framework. > What happens when you hit another bug in the new ecosystem? My whole point is that this question is not answerable, precisely because "bug" is such a broad category. If the bug is a minor annoyance, we'd work around or avoid it; if it was more serious, but small, we'd maybe upstream a patch; if it was more difficult we'd maybe sponsor a core maintainer to work on it; etc. Presumably we wouldn't be hitting fundamental design problems, since our switching process would not land upon a notoriously flawed technology, cobbled-together by someone who "hates programming" and is "really, really bad at writing parsers"[1] (yet nevertheless proceeds to bake much of their language's semantics into the parser![2]) [1] https://en.wikiquote.org/wiki/Rasmus_Lerdorf https://en.wikiquote.org/wiki/Rasmus_Lerdorf [2] For example, all the syntax errors and ambiguities I listed at https://stackoverflow.com/a/24463174/884682 https://stackoverflow.com/a/24463174/884682