16 ms·

It seems to value my time quite highly, as I can achieve most things more quickly and easily in Python than any other language I know. Can you be more specific

by mkl 7y ago

It seems to value my time quite highly, as I can achieve most things more quickly and easily in Python than any other language I know. Can you be more specific about how it increases your burnout? Is it the language, or someone forcing you to use that linter and settings?

KirinDave 7y ago
> Is it the language, or someone forcing you to use that linter and settings? It's definitely both. Preface in true internet style: these are just opinions and you may not share them. That's fine. I really don't like Python as a language. I don't like its total lack of composability. I don't like its over-reliance on a very dated vision of OO. I don't like how its list comprehensions aren't generic. I don't like how it farms all its data structures out to C. I don't like how it uses cruddy one line lambdas and forces me to name things that are already named by the things I'm passing it to. And also the linter just exacerbates these things, because the linter is just a crystallized slice of a kind of software engineering culture I really don't like.
- futureastronaut 7y ago
  > I don't like how its list comprehensions aren't generic. Python iteration is generic. https://docs.python.org/3/reference/datamodel.html#object.__iter__ https://docs.python.org/3/reference/datamodel.html#object.__... Please don't spread FUD.
  - KirinDave 7y ago
    I'm thinking of generic in the sense of monadcomprehensions, sorry. > That's an implementation detail of CPython. I don't see how it's important for a language user either. Jython uses Java objects. PyPy uses RPython. This strengthens my point though? > Please don't spread FUD. This is that culture thing I'm talking about.
    - futureastronaut 7y ago
      I'm not really sure what your point is in criticizing "farming" to C. > This is that culture thing I'm talking about. You made a false claim. You referred to Python iteration as not generic, when what you really meant is that Python lacks first class monad support. If you want a monadic programming model, you're not going to be a happy camper in the Python world. But I doubt that comes as a surprise.
      - KirinDave 7y ago
        > I'm not really sure what your point is in criticizing "farming" to C. If Python is so great how come it can't even express a decent data structure that it needs? I'll happily level the same criticism at Ruby if you like. > You made a false claim. Firstly: This is not High School Debate Club. There isn't some kind of point system. Language and expectations like this are not only counterproductive (in that they essentially turn every conversation into a series of verbal ripostes in which the goal is to be most right rather than *learn the most) they're also tedious and unwelcome. > You referred to Python iteration as not generic, I did not. I said list comprehensions weren't generic, and then I tried to explain my complaint. It may be that someone has done a legendary feat of going through and creating a bunch of mixins for some of the gaps in the list comprehension coverage such that you can find some way to override how non-determinism is expressed. If so, please point me to it.
        CogitoCogito 7y ago
        > If Python is so great how come it can't even express a decent data structure that it needs? Why is this a requirement of a "great" language? By not requiring a language to be self-hosting, you are adding more degrees of freedom to your language's design, so I could even see an argument that writing it in C is an improvement. I don't necessarily agree with that, but I don't see why cpython written in C implies it is a bad language. Maybe you could elucidate your thinking?
        pvg 7y ago
- paganel 7y ago
  Not sure why Python’s list comprehensions not being generic might be such a great downside but just wanted to add that I personally think that they are perfectly fine just the way they are. For the context, I’ve been professionally writing Python code for 14 years now. I understand it’s not the perfect language but for quite average programmers like myself it does an excellent job of getting out of the way and of letting you focus just on the data, because that’s what programming is (or should be), i.e. managing and processing data. Like I said, it’s not the perfect language, it does not have Erlang’s pattern matching nor Lisp’s insistence on thinking about almost everything in a recursive manner, but you can at least mentally try to incorporate those two philosophies into Python once you know about them (and once you know about other similar such great programming concepts).
- ptx 7y ago
  If by generic you mean able to use other types of collections, aren't generator expressions[1] the generic version of list comprehensions? List comprehension: a = [x for x in stuff if x > 1] Equivalent generic version: a = list(x for x in stuff if x > 1) With your own collection type: a = MyCustomCollection(x for x in stuff if x > 1) [1] https://www.python.org/dev/peps/pep-0289/ https://www.python.org/dev/peps/pep-0289/
- m45t3r 7y ago
  Just a point about linters. They are bad in every language (because everyone has different opinions on what they consider beautiful code). If you're having a burnout because the PR you just opened are being rejected by the linter you probably just make the linter apply the modifications automatically in pipeline. We used to hate the linter checks in my current workplace because it was really boring to fix the issues. Now the CI simple fix them, and nobody cares anymore.
staticassertion 7y ago
I'm not the person you're responding to but what they say resonates with me as a Python developer. I believe Python is quite possibly the best language for a few things * Exploratory programming - such as what data scientists do * Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down When I have those two constraints met I am almost always choosing Python. Here are some problems I face on codebases as they scale up: * Python conventions lead to what I consider bad code. Devs will often choose things like 'patch' over dependency injection, and I have seen on multiple occasions projects derided for providing DI based interfaces - "oh, why would you write code that looks like Java? This is Python". There's a lot of death by a thousand cuts. Keyword args in functions are abused a lot, because they're "easy", ability to patch at runtime means it's often "easy" to just write what looks like a simple interface, but it's then harder to test. Inheritance is "easy" and often leads to complex code where behaviors are very, very non-local. Dynamic types mean that people are often a little too clever with their data. I've seen APIs that return effectively `Union[NoneType, Item, List[Item]]` for absolutely no semantic reason, without type annotations, meaning that if you assumed a list or none came back you were missing the single Item case. The implementation actually internally always got a list back from the underlying query but decided to special case the single item case... why? I see this sort of thing a bit, and other languages punish you for it (by forcing you to express the more complex type). * I find myself more and more leveraging threads these days. I did this often with C++, and all the time in my Rust code. Python punishes you for threading. The GIL makes things feel atomic when they aren't, reduces you to concurrency, all while paying the cost of an OS thread. Threading primitives are also quite weak, imo, and multiprocessing is a dead end. And, really, Python is anti-optimization, which is a good and bad thing, but it's a bit extreme. * Implicit exceptions everywhere. I see 'raise Exception' defensively placed in every Python codebase because you never know when a piece of code will fail. I see a lot of reliance on 'retry decorators' that just catch everything because you never know if an error is transient or persistent. The common "don't use exceptions for control flow" is broken right off the bat with StopIteration. I just think error handling in Python is god awful, really. * Mypy is awesome, but feels like a bit of a hack. The type system is great, and in theory it would solve many problems, but coverage is quite awful in open source projects and the type errors I get are useless. I actually only use mypy to make my IDE behave, I don't run it myself, because my types are actually technically unsound and the errors are too painful to work with (and honestly the type system is quite complex and hard to work with, not to mention the bugs). There are lots of other smaller issues, such as my distaste for pip, py2/3 breakage, lack of RAII, the insane reliance on C all over the place, I think syntax is bad in a lot of places (lambdas, whitespace in general), etc but these are probably my main sticking points with using the language for large projects. Again, Python is actually my favorite language for specific tasks, but I really think it's best optimized for small codebases.
mruts 7y ago
Here’s my long list on why Python is terrible: 1) No pattern matching. In 2019, this is just unacceptable. Pattern matching is so fundamental to good FP style that without it, it becomes almost impossible to write good and clean code. 2) Statement vs expression distinction. There’s no need for this and it just crippled the language. Why can’t I use a conditional inside an assignment? Why can’t I nest conditions inside other functions? It makes no sense and is stupid and inelegant. 3) Related to 2), why do I need to use a return statement? Just return the last expression like many other (better) languages 4) Bad and limited data structures. In Python all you get are arrays, hashmaps, sets. And only sets have an immutable version. This is unacceptable. Python claims to be “batteries included” but if you look at the Racket standard library it has like 20x more stuff and it’s all 100x better designed. In Scala you get in the standard library support for Lists, Stacks, Queues, TreeMaps, TreeSets, LinearMaps, LinearSet, Vectors, ListBuffers, etc. 5) Embarrassing performance. Python is so slow it’s shameful. I wrote a compiler and some interpreters in college and I honestly think I could create a similar language 10x faster than Python. Sometimes you need to trade off performance and power, but that’s not even the case with Python: it’s an order of magnitude slower than other interpreted languages (like Racket). 6) Missing or inadequate FP constructs. Why are lambdas different from a normal function? Why are they so crippled? Why do they have a different conditional syntax? The only sort of FP stuff Python has is reduce/filter/map. What about flatMap, scanr, scanl, foldl, foldr? Or why doesn’t Python have flatten? All of these are very useful and common operations and Python just makes everyone write the same code over and over again. 7) No monads. Monads can be used for exceptions, futures, lists, and more. Having to manually write some try catch thing is unseemly and worse than the monadic Haskell or Scala approach. 8) No threads and no real single process concurrency. Despite Python being used a lot, no one really seems to care about it. How can such a problem not be solved after over 20 years? It’s shameful and makes me wonder about the skill of Guido. There’s no reason why Python couldn’t have turned into something beautiful like Racket, but instead it has been held back by this grumpy old guy who is stuck in the past. 9) Others might not have a problem with this, but I detest Python’s anything can happen dynamic typing. It makes reasoning about code difficult and it makes editor introspections almost impossible. If I can’t know the exact type of every variable and the methods attached to it, it hampers my thinking a lot. I use Python for data science and if I could just have a language that was compiled and had static typing I would be 3x as productive. Let me conclude by saying there currently is one good reason to use Python: if the domain is ML/DL/quant/data science Python is still the undisputed king. The libraries for Python are world class: scipy, sklearn, pandas, cvxpy, pytorch, Kerala, etc. But Julia is catching up very fast and the people I have talked to are getting ready to ditch Python in 2-3 years for Julia. I don’t think I’ve encountered anyone who didn’t prefer Julia to Python.

by mkl 7y ago

KirinDave 7y ago

> Is it the language, or someone forcing you to use that linter and settings? It's definitely both. Preface in true internet style: these are just opinions and you may not share them. That's fine. I really don't like Python as a language. I don't like its total lack of composability. I don't like its over-reliance on a very dated vision of OO. I don't like how its list comprehensions aren't generic. I don't like how it farms all its data structures out to C. I don't like how it uses cruddy one line lambdas and forces me to name things that are already named by the things I'm passing it to. And also the linter just exacerbates these things, because the linter is just a crystallized slice of a kind of software engineering culture I really don't like.

futureastronaut 7y ago
> I don't like how its list comprehensions aren't generic. Python iteration is generic. https://docs.python.org/3/reference/datamodel.html#object.__iter__ https://docs.python.org/3/reference/datamodel.html#object.__... Please don't spread FUD.
- KirinDave 7y ago
  I'm thinking of generic in the sense of monadcomprehensions, sorry. > That's an implementation detail of CPython. I don't see how it's important for a language user either. Jython uses Java objects. PyPy uses RPython. This strengthens my point though? > Please don't spread FUD. This is that culture thing I'm talking about.
  - futureastronaut 7y ago
    I'm not really sure what your point is in criticizing "farming" to C. > This is that culture thing I'm talking about. You made a false claim. You referred to Python iteration as not generic, when what you really meant is that Python lacks first class monad support. If you want a monadic programming model, you're not going to be a happy camper in the Python world. But I doubt that comes as a surprise.
    - KirinDave 7y ago
      > I'm not really sure what your point is in criticizing "farming" to C. If Python is so great how come it can't even express a decent data structure that it needs? I'll happily level the same criticism at Ruby if you like. > You made a false claim. Firstly: This is not High School Debate Club. There isn't some kind of point system. Language and expectations like this are not only counterproductive (in that they essentially turn every conversation into a series of verbal ripostes in which the goal is to be most right rather than *learn the most) they're also tedious and unwelcome. > You referred to Python iteration as not generic, I did not. I said list comprehensions weren't generic, and then I tried to explain my complaint. It may be that someone has done a legendary feat of going through and creating a bunch of mixins for some of the gaps in the list comprehension coverage such that you can find some way to override how non-determinism is expressed. If so, please point me to it.
      - CogitoCogito 7y ago
        > If Python is so great how come it can't even express a decent data structure that it needs? Why is this a requirement of a "great" language? By not requiring a language to be self-hosting, you are adding more degrees of freedom to your language's design, so I could even see an argument that writing it in C is an improvement. I don't necessarily agree with that, but I don't see why cpython written in C implies it is a bad language. Maybe you could elucidate your thinking?
        pvg 7y ago
paganel 7y ago
Not sure why Python’s list comprehensions not being generic might be such a great downside but just wanted to add that I personally think that they are perfectly fine just the way they are. For the context, I’ve been professionally writing Python code for 14 years now. I understand it’s not the perfect language but for quite average programmers like myself it does an excellent job of getting out of the way and of letting you focus just on the data, because that’s what programming is (or should be), i.e. managing and processing data. Like I said, it’s not the perfect language, it does not have Erlang’s pattern matching nor Lisp’s insistence on thinking about almost everything in a recursive manner, but you can at least mentally try to incorporate those two philosophies into Python once you know about them (and once you know about other similar such great programming concepts).
ptx 7y ago
If by generic you mean able to use other types of collections, aren't generator expressions[1] the generic version of list comprehensions? List comprehension: a = [x for x in stuff if x > 1] Equivalent generic version: a = list(x for x in stuff if x > 1) With your own collection type: a = MyCustomCollection(x for x in stuff if x > 1) [1] https://www.python.org/dev/peps/pep-0289/ https://www.python.org/dev/peps/pep-0289/
m45t3r 7y ago
Just a point about linters. They are bad in every language (because everyone has different opinions on what they consider beautiful code). If you're having a burnout because the PR you just opened are being rejected by the linter you probably just make the linter apply the modifications automatically in pipeline. We used to hate the linter checks in my current workplace because it was really boring to fix the issues. Now the CI simple fix them, and nobody cares anymore.

staticassertion 7y ago

I'm not the person you're responding to but what they say resonates with me as a Python developer. I believe Python is quite possibly the best language for a few things * Exploratory programming - such as what data scientists do * Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down When I have those two constraints met I am almost always choosing Python. Here are some problems I face on codebases as they scale up: * Python conventions lead to what I consider bad code. Devs will often choose things like 'patch' over dependency injection, and I have seen on multiple occasions projects derided for providing DI based interfaces - "oh, why would you write code that looks like Java? This is Python". There's a lot of death by a thousand cuts. Keyword args in functions are abused a lot, because they're "easy", ability to patch at runtime means it's often "easy" to just write what looks like a simple interface, but it's then harder to test. Inheritance is "easy" and often leads to complex code where behaviors are very, very non-local. Dynamic types mean that people are often a little too clever with their data. I've seen APIs that return effectively `Union[NoneType, Item, List[Item]]` for absolutely no semantic reason, without type annotations, meaning that if you assumed a list or none came back you were missing the single Item case. The implementation actually internally always got a list back from the underlying query but decided to special case the single item case... why? I see this sort of thing a bit, and other languages punish you for it (by forcing you to express the more complex type). * I find myself more and more leveraging threads these days. I did this often with C++, and all the time in my Rust code. Python punishes you for threading. The GIL makes things feel atomic when they aren't, reduces you to concurrency, all while paying the cost of an OS thread. Threading primitives are also quite weak, imo, and multiprocessing is a dead end. And, really, Python is anti-optimization, which is a good and bad thing, but it's a bit extreme. * Implicit exceptions everywhere. I see 'raise Exception' defensively placed in every Python codebase because you never know when a piece of code will fail. I see a lot of reliance on 'retry decorators' that just catch everything because you never know if an error is transient or persistent. The common "don't use exceptions for control flow" is broken right off the bat with StopIteration. I just think error handling in Python is god awful, really. * Mypy is awesome, but feels like a bit of a hack. The type system is great, and in theory it would solve many problems, but coverage is quite awful in open source projects and the type errors I get are useless. I actually only use mypy to make my IDE behave, I don't run it myself, because my types are actually technically unsound and the errors are too painful to work with (and honestly the type system is quite complex and hard to work with, not to mention the bugs). There are lots of other smaller issues, such as my distaste for pip, py2/3 breakage, lack of RAII, the insane reliance on C all over the place, I think syntax is bad in a lot of places (lambdas, whitespace in general), etc but these are probably my main sticking points with using the language for large projects. Again, Python is actually my favorite language for specific tasks, but I really think it's best optimized for small codebases.

mruts 7y ago

Here’s my long list on why Python is terrible: 1) No pattern matching. In 2019, this is just unacceptable. Pattern matching is so fundamental to good FP style that without it, it becomes almost impossible to write good and clean code. 2) Statement vs expression distinction. There’s no need for this and it just crippled the language. Why can’t I use a conditional inside an assignment? Why can’t I nest conditions inside other functions? It makes no sense and is stupid and inelegant. 3) Related to 2), why do I need to use a return statement? Just return the last expression like many other (better) languages 4) Bad and limited data structures. In Python all you get are arrays, hashmaps, sets. And only sets have an immutable version. This is unacceptable. Python claims to be “batteries included” but if you look at the Racket standard library it has like 20x more stuff and it’s all 100x better designed. In Scala you get in the standard library support for Lists, Stacks, Queues, TreeMaps, TreeSets, LinearMaps, LinearSet, Vectors, ListBuffers, etc. 5) Embarrassing performance. Python is so slow it’s shameful. I wrote a compiler and some interpreters in college and I honestly think I could create a similar language 10x faster than Python. Sometimes you need to trade off performance and power, but that’s not even the case with Python: it’s an order of magnitude slower than other interpreted languages (like Racket). 6) Missing or inadequate FP constructs. Why are lambdas different from a normal function? Why are they so crippled? Why do they have a different conditional syntax? The only sort of FP stuff Python has is reduce/filter/map. What about flatMap, scanr, scanl, foldl, foldr? Or why doesn’t Python have flatten? All of these are very useful and common operations and Python just makes everyone write the same code over and over again. 7) No monads. Monads can be used for exceptions, futures, lists, and more. Having to manually write some try catch thing is unseemly and worse than the monadic Haskell or Scala approach. 8) No threads and no real single process concurrency. Despite Python being used a lot, no one really seems to care about it. How can such a problem not be solved after over 20 years? It’s shameful and makes me wonder about the skill of Guido. There’s no reason why Python couldn’t have turned into something beautiful like Racket, but instead it has been held back by this grumpy old guy who is stuck in the past. 9) Others might not have a problem with this, but I detest Python’s anything can happen dynamic typing. It makes reasoning about code difficult and it makes editor introspections almost impossible. If I can’t know the exact type of every variable and the methods attached to it, it hampers my thinking a lot. I use Python for data science and if I could just have a language that was compiled and had static typing I would be 3x as productive. Let me conclude by saying there currently is one good reason to use Python: if the domain is ML/DL/quant/data science Python is still the undisputed king. The libraries for Python are world class: scipy, sklearn, pandas, cvxpy, pytorch, Kerala, etc. But Julia is catching up very fast and the people I have talked to are getting ready to ditch Python in 2-3 years for Julia. I don’t think I’ve encountered anyone who didn’t prefer Julia to Python.