21–30 of 125 posts
Until it introduced the haphazard type system. Now I need to import types in every file, use IF to guard it in CI in every file, and use a powerful IDE to be able to use the benefits of typing.
Terrible is using a dynamic programming language and expecting static features from it. Besides, linters and type hinting have come a long way.
Ocaml is an interesting example imho, as the type inference engine is so good you hardly have to specify types. When you read it and squint, it looks dynamic. It's not.
Oh and he just says what is supposed to be quiet part at the end:
>And, not to put too fine a point on it, but if you can code Python but not Go (or another decent programming language), you probably have no business writing software for a living. I know it sounds harsh and I apologize for that, but writing software is a profession and hence you should have the knowledge, skill, and experience to use professional tools.
Hear that all data scientists, flask devs, systems engineers, and ML folks? Python is bad so you should quit. ;)
Python is one of my least favorite languages and I avoid it wherever I can. I agree with several of the criticisms here, but I disagree with this part: > The problem with Python is of course that it is an interpreted language with lazy evaluation That isn't "the problem" with Python. There's nothing wrong with these sorts of languages. However, it does limit the sorts of problems the language is suited for, and I do…
> with lazy evaluation I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horror show (my taste, other people like it, that's fine), but I had to use it a few times and found that (also from the article) some parts are lazy, but not python as a language. Is that not correct? > it does limit the sorts of problems the language is suited fo…
Iteration in a sense can be "lazy", but that laziness is via data structures built on top of a strict core language. Python is not alone in having lazy iteratable data structures, but it leans into them relatively hard in its standard library.
Many of us love this, as it lets for loops work elegantly over all sorts of abstractions, but I could see some folks disliking it. Still, the author does not explain this nuance, which makes me think he does not quite know what he is talking about.
"This wrench is really bad for hammering nails!"
Earlier quoted context omitted.
> with lazy evaluation I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horror show (my taste, other people like it, that's fine), but I had to use it a few times and found that (also from the article) some parts are lazy, but not python as a language. Is that not correct? > it does limit the sorts of problems the language is suited fo…
Almost surely the author of TFA meant "dynamic", not lazy. Nobody uses "lazy" in the sense of TFA.
I wish people could be honest and say they don't care for some language or framework or OS for personal or aesthetic reasons, rather than having to round it up to being objectively bad, but then I suppose nobody probably would click on "I don't like Python and have got some nits to pick". Oh and he just says what is supposed to be quiet part at the end: >And, not to put too fine a point on it, but if you can code Pyt…
This is the biggest problem in software and it's kind of intractable.
The ideal world has tools that empower everyone to do what they need to do, which to some extent must include an activity like programming.
But, and this may be unconscious, "people who program for a living" have a strong incentive to gatekeep.