5 ms·

Python had their smearing campaign claiming TIOOWTDI against Perl's TIMTOWTDI, and dubious claim's of sigils (`@$`) hurt readability. But once Python had the e

by jxy 6y ago

Python had their smearing campaign claiming TIOOWTDI against Perl's TIMTOWTDI, and dubious claim's of sigils (`@$`) hurt readability. But once Python had the ecosystem going, it brought back `@`, `{}`, numerous `_`, fanciful `:=`. And, of course, there always is more than one way to do it in Python. Python's "easy to use" is just a lie, https://github.com/satwikkansal/wtfpython https://github.com/satwikkansal/wtfpython The common lisp CFFI module is nothing short of Python's. But, I know, people hate to put their `(` in front of their function names, and people hate to omit `,` between there function arguments.

neolog 6y ago
"Python is easy to use" is a relative statement about its priorities. Compare to other languages that have different priorities. Python is easier and slower than C++, for example. There are many design errors in Python, of course. But most "wtfpython" things don't actually affect people using the language -- they're engineered to identify funny compiler optimizations and floating-point peculiarities. The real problems of a language aren't usually the kind of thing demonstrated in a couple-line snippet. Though there are exceptions.
- jolux 6y ago
  >Python is easier and slower than C++, for example. Most languages are easier than C++, and many of them are faster than Python.
  - neolog 6y ago
    There are many dimensions that different languages prioritize. As you increase the number of dimensions you consider important, the number of languages that are better than $language on all of your important dimensions tends to decrease.
    - jolux 6y ago
      Sure. I have a lot of problems with Python’s design and find it grating, and I don’t think its biggest problems are about tradeoffs, they’re just mistakes.
- Izkata 6y ago
  > But most "wtfpython" things don't actually affect people using the language Plenty do though. I've passed that page onto co-workers a lot, back when the list was smaller, and almost every time they've found something on the page that explains a bit of weirdness with Python that they'd just dismissed as buggy behavior and avoided touching. The ones I remember them mentioning: https://github.com/satwikkansal/wtfpython#-mutating-the-immutable https://github.com/satwikkansal/wtfpython#-mutating-the-immu... https://github.com/satwikkansal/wtfpython#-beware-of-default-mutable-arguments https://github.com/satwikkansal/wtfpython#-beware-of-default... And I multiple times I've had to explain the difference between references / shallow copy / deep copy to bootcampers, which falls under https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-where-x-wins-in-the-first-attempt https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-whe...
  - andi999 6y ago
    Shallow and deep copy is a surprising concept, but I think it is the core feature that actually allows python to handle large datasets.
  - neolog 6y ago
    IMO those two gotchas (mutable default and late-binding closures) are actually the main ones. That's why they're mentioned explicitly here https://docs.python-guide.org/writing/gotchas/ https://docs.python-guide.org/writing/gotchas/ Shallow/deep copies is an unavoidable part of having mutable data. The main alternative way to handle mutation is a fancy type system like Rust's, which is not an acceptable tradeoff for new programmers.
deleted 6y ago
[deleted]
lmm 6y ago
> Python had their smearing campaign claiming TIOOWTDI against Perl's TIMTOWTDI It was nothing of the sort; the claims would have landed on deaf ears if Perl didn't genuinely suffer maintainability problems due to that approach. > dubious claim's of sigils (`@$`) hurt readability AIUI the (admittedly limited) scientific data that exists supports that. > But once Python had the ecosystem going, it brought back `@`, `{}`, numerous `_`, fanciful `:=`. And, of course, there always is more than one way to do it in Python. You present this as some kind of bait-and-switch, but it's nothing of the sort; no-one's happy about the use of @ or := (I don't know what you're talking about regarding {} or _), but they were least-bad compromises for things that were felt to be needed. Multiple ways to do something is still seen as a bad thing - "There should be one-- and preferably only one --obvious way to do it" is the standard Python phrase, acknowledging that having only one way is an aspiration that can't always be fulfilled. > Python's "easy to use" is just a lie Nonsense. Like every language it's accumulated some warts, but it's still the language beginners find easiest to learn and teachers find easiest to teach. > But, I know, people hate to put their `(` in front of their function names, and people hate to omit `,` between there function arguments. Wow, way to conform to the Lisp stereotypes. If the problems of Lisp were actually that superficial, don't you think there'd be someone who'd produce a Lisp with a more familiar syntax and reap the popularity gains? Is every single Lisper really too haughty to make a trivial syntax change?

by jxy 6y ago

neolog 6y ago

"Python is easy to use" is a relative statement about its priorities. Compare to other languages that have different priorities. Python is easier and slower than C++, for example. There are many design errors in Python, of course. But most "wtfpython" things don't actually affect people using the language -- they're engineered to identify funny compiler optimizations and floating-point peculiarities. The real problems of a language aren't usually the kind of thing demonstrated in a couple-line snippet. Though there are exceptions.

jolux 6y ago
>Python is easier and slower than C++, for example. Most languages are easier than C++, and many of them are faster than Python.
- neolog 6y ago
  There are many dimensions that different languages prioritize. As you increase the number of dimensions you consider important, the number of languages that are better than $language on all of your important dimensions tends to decrease.
  - jolux 6y ago
    Sure. I have a lot of problems with Python’s design and find it grating, and I don’t think its biggest problems are about tradeoffs, they’re just mistakes.
Izkata 6y ago
> But most "wtfpython" things don't actually affect people using the language Plenty do though. I've passed that page onto co-workers a lot, back when the list was smaller, and almost every time they've found something on the page that explains a bit of weirdness with Python that they'd just dismissed as buggy behavior and avoided touching. The ones I remember them mentioning: https://github.com/satwikkansal/wtfpython#-mutating-the-immutable https://github.com/satwikkansal/wtfpython#-mutating-the-immu... https://github.com/satwikkansal/wtfpython#-beware-of-default-mutable-arguments https://github.com/satwikkansal/wtfpython#-beware-of-default... And I multiple times I've had to explain the difference between references / shallow copy / deep copy to bootcampers, which falls under https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-where-x-wins-in-the-first-attempt https://github.com/satwikkansal/wtfpython#-a-tic-tac-toe-whe...
- andi999 6y ago
  Shallow and deep copy is a surprising concept, but I think it is the core feature that actually allows python to handle large datasets.
- neolog 6y ago
  IMO those two gotchas (mutable default and late-binding closures) are actually the main ones. That's why they're mentioned explicitly here https://docs.python-guide.org/writing/gotchas/ https://docs.python-guide.org/writing/gotchas/ Shallow/deep copies is an unavoidable part of having mutable data. The main alternative way to handle mutation is a fancy type system like Rust's, which is not an acceptable tradeoff for new programmers.

deleted 6y ago

[deleted]

lmm 6y ago

> Python had their smearing campaign claiming TIOOWTDI against Perl's TIMTOWTDI It was nothing of the sort; the claims would have landed on deaf ears if Perl didn't genuinely suffer maintainability problems due to that approach. > dubious claim's of sigils (`@$`) hurt readability AIUI the (admittedly limited) scientific data that exists supports that. > But once Python had the ecosystem going, it brought back `@`, `{}`, numerous `_`, fanciful `:=`. And, of course, there always is more than one way to do it in Python. You present this as some kind of bait-and-switch, but it's nothing of the sort; no-one's happy about the use of @ or := (I don't know what you're talking about regarding {} or _), but they were least-bad compromises for things that were felt to be needed. Multiple ways to do something is still seen as a bad thing - "There should be one-- and preferably only one --obvious way to do it" is the standard Python phrase, acknowledging that having only one way is an aspiration that can't always be fulfilled. > Python's "easy to use" is just a lie Nonsense. Like every language it's accumulated some warts, but it's still the language beginners find easiest to learn and teachers find easiest to teach. > But, I know, people hate to put their `(` in front of their function names, and people hate to omit `,` between there function arguments. Wow, way to conform to the Lisp stereotypes. If the problems of Lisp were actually that superficial, don't you think there'd be someone who'd produce a Lisp with a more familiar syntax and reap the popularity gains? Is every single Lisper really too haughty to make a trivial syntax change?