3 ms·

Compared to what?

__loam 3y ago
Go for example has fewer ways to write things. With Python, you have to guess what the idiomatic pattern is and it's often not obvious and specific to python. Go went as far removing the ternary operator to cut down on this kind of thing. Writing things in the idiomatic way is more obvious because there's usually only one way to do a given thing.
- Sohcahtoa82 3y ago
  > With Python, you have to guess what the idiomatic pattern is and it's often not obvious and specific to python. This is true of every language. You just don't know Python. You probably decided a long time ago that you hate it because of X reason (usually whitespace-as-syntax, as that's probably the most controversial Python design choice), and so refuse to learn anything more and decide you just hate everything. > Go went as far removing the ternary operator to cut down on this kind of thing. It surprises me when people get confused by the ternary operator. I never thought it was hard. I wish Python had it. Yes, I know, Python has "a = b if c else d", but that's just weird as it flips the order of expressions around to something that doesn't make much sense.
  - __loam 3y ago
    I've been using python for 11 years bud. I know all the idioms. When I say it's a bad language, it's coming from years of experience using it in production environments. But yeah the problem is I never learned a language I've probably written more code in than any other language. The ternary is just one example. It's not confusing, it's just indicative of the philosophy of python's design, and it's hardly the worst example. E: it's actually been 11 years. I'm getting old
    - Sohcahtoa82 3y ago
      The ternary operator as a concept is fine, but I certainly dislike Python's implementation and really wish they went with C's version. IMO, "a = b ? c : d" is much more readable than "a = c if b else d" In most cases, I love the philosophy of Python's design.
      - __loam 3y ago
        There's more awful things if you keep digging. The above poster set up a strawman about people not liking the whitespace matters aspect, and while agree that's bad, if you have any modern editor it's not really a big problem. I prefer braces but it's hardly a problem. The actual issues include: - The global interpreter lock. Multiprocessing is a hacky fix to a problem that most other mainstream languages do not have. - Performance in general. Python is double digits times or more slower than a lot of other languages at a lot of tasks. - Weak type system. This is the most glaring issue for large projects. You can add type hints but it's obvious the language wasn't designed with it in mind. You need several layers of linters (mypy, black, etc) to fix this problem, and even then your codebase probably has untyped files. You also won't know if your program is broken until run time. - Python 3 is not backwards compatible with Python 2. I know why they did this but that doesn't mean this wasn't an expensive problem for a lot of orgs, and 2.7 remains in use in a lot of places and is now a security vulnerability. - The package management and set up process kind of suck. This is ironic since python is one of the most suggested languages for new devs. One of advantages python has is that it's easy to use, and that has attracted a lot of development that has lead to a wide variety of libraries including ones that use c and Fortran under the hood like numpy to do things much faster than python. The ease of use also should mean that there's a very large pool of devs to hire from, and that theoretically you're optimizing for lower dev time spent developing. In practice I think the value trade off is worse than people think, especially for larger codebases.
        Sohcahtoa82 3y ago
        GIL and performance issues are specific to the interpreter, not the language itself. PyPy is evidence of that. 3 to 2 backwards compatibility issues simply weren't possible to prevent. Python had a lot of design mistakes (inadequate differentiation between strings and bytes was one I ran into a lot) that made it impossible to fix without breaking things. Sure, they could have made `print` as a statement still work, but I think it's better that things obviously designed in Python 2 to break. The weak type system...I dunno I kind of like it. It prevents a lot of the ridiculousness that Java has, where every piece of middleware needs to do type introspection and reflection to get anything done. And it doesn't try to "just make things work" the way JavaScript does and create bizarre rules where {} + {} is NaN and 1 + {} is "1[object Object]". I can certainly see how it can become troublesome on large project. I think the biggest problem with package management is that `pip` wants to install everything as a system package by default (which requires root), rather than going into a user directory. VirtualEnvs did a lot to fix package management.
  - t8sr 3y ago
    Hey now, it's possible to have written hundreds of thousands of lines of Python and worked on the internals (back in Python2 days) and still think it's terrible. (I don't, really, but that's because I don't try to use it to write web services.) I think part of the problem is even comparing Python to Go. They are both "programming languages", but in one of them the expression `x + y` translates to the CPU doing about 2-10 things, and in another the CPU does anywhere between ~1,000 and a few 100,000 things. (I'm ignoring the FFI here.) It's not like Python does 5,000 things just because it's poorly designed! Actually, I wouldn't want to write math code or do physics simulations in any other language. But conversely, I think if you try to write a backend RPC service in Python, you are just using the wrong tool for the job. Maybe that's because it's what you know and that's fine, but let's not pretend it's a good choice on technical metrics. In most ways, Python is much closer to bash than it is to Go/Rust/JVM/C. Just like I wouldn't wanna write shell scripts in C, I wouldn't want to write backend code in Python.

Compared to what?

Go for example has fewer ways to write things. With Python, you have to guess what the idiomatic pattern is and it's often not obvious and specific to python. Go went as far removing the ternary operator to cut down on this kind of thing. Writing things in the idiomatic way is more obvious because there's usually only one way to do a given thing.

Sohcahtoa82 3y ago
> With Python, you have to guess what the idiomatic pattern is and it's often not obvious and specific to python. This is true of every language. You just don't know Python. You probably decided a long time ago that you hate it because of X reason (usually whitespace-as-syntax, as that's probably the most controversial Python design choice), and so refuse to learn anything more and decide you just hate everything. > Go went as far removing the ternary operator to cut down on this kind of thing. It surprises me when people get confused by the ternary operator. I never thought it was hard. I wish Python had it. Yes, I know, Python has "a = b if c else d", but that's just weird as it flips the order of expressions around to something that doesn't make much sense.
- __loam 3y ago
  I've been using python for 11 years bud. I know all the idioms. When I say it's a bad language, it's coming from years of experience using it in production environments. But yeah the problem is I never learned a language I've probably written more code in than any other language. The ternary is just one example. It's not confusing, it's just indicative of the philosophy of python's design, and it's hardly the worst example. E: it's actually been 11 years. I'm getting old
  - Sohcahtoa82 3y ago
    The ternary operator as a concept is fine, but I certainly dislike Python's implementation and really wish they went with C's version. IMO, "a = b ? c : d" is much more readable than "a = c if b else d" In most cases, I love the philosophy of Python's design.
    - __loam 3y ago
      There's more awful things if you keep digging. The above poster set up a strawman about people not liking the whitespace matters aspect, and while agree that's bad, if you have any modern editor it's not really a big problem. I prefer braces but it's hardly a problem. The actual issues include: - The global interpreter lock. Multiprocessing is a hacky fix to a problem that most other mainstream languages do not have. - Performance in general. Python is double digits times or more slower than a lot of other languages at a lot of tasks. - Weak type system. This is the most glaring issue for large projects. You can add type hints but it's obvious the language wasn't designed with it in mind. You need several layers of linters (mypy, black, etc) to fix this problem, and even then your codebase probably has untyped files. You also won't know if your program is broken until run time. - Python 3 is not backwards compatible with Python 2. I know why they did this but that doesn't mean this wasn't an expensive problem for a lot of orgs, and 2.7 remains in use in a lot of places and is now a security vulnerability. - The package management and set up process kind of suck. This is ironic since python is one of the most suggested languages for new devs. One of advantages python has is that it's easy to use, and that has attracted a lot of development that has lead to a wide variety of libraries including ones that use c and Fortran under the hood like numpy to do things much faster than python. The ease of use also should mean that there's a very large pool of devs to hire from, and that theoretically you're optimizing for lower dev time spent developing. In practice I think the value trade off is worse than people think, especially for larger codebases.
      - Sohcahtoa82 3y ago
        GIL and performance issues are specific to the interpreter, not the language itself. PyPy is evidence of that. 3 to 2 backwards compatibility issues simply weren't possible to prevent. Python had a lot of design mistakes (inadequate differentiation between strings and bytes was one I ran into a lot) that made it impossible to fix without breaking things. Sure, they could have made `print` as a statement still work, but I think it's better that things obviously designed in Python 2 to break. The weak type system...I dunno I kind of like it. It prevents a lot of the ridiculousness that Java has, where every piece of middleware needs to do type introspection and reflection to get anything done. And it doesn't try to "just make things work" the way JavaScript does and create bizarre rules where {} + {} is NaN and 1 + {} is "1[object Object]". I can certainly see how it can become troublesome on large project. I think the biggest problem with package management is that `pip` wants to install everything as a system package by default (which requires root), rather than going into a user directory. VirtualEnvs did a lot to fix package management.
- t8sr 3y ago
  Hey now, it's possible to have written hundreds of thousands of lines of Python and worked on the internals (back in Python2 days) and still think it's terrible. (I don't, really, but that's because I don't try to use it to write web services.) I think part of the problem is even comparing Python to Go. They are both "programming languages", but in one of them the expression `x + y` translates to the CPU doing about 2-10 things, and in another the CPU does anywhere between ~1,000 and a few 100,000 things. (I'm ignoring the FFI here.) It's not like Python does 5,000 things just because it's poorly designed! Actually, I wouldn't want to write math code or do physics simulations in any other language. But conversely, I think if you try to write a backend RPC service in Python, you are just using the wrong tool for the job. Maybe that's because it's what you know and that's fine, but let's not pretend it's a good choice on technical metrics. In most ways, Python is much closer to bash than it is to Go/Rust/JVM/C. Just like I wouldn't wanna write shell scripts in C, I wouldn't want to write backend code in Python.