6 ms·

I agree with the OPs points but disagree with the degree to which the author has used them as a means to "hate" a language. I generally avoid Python too but say

by berdon 8y ago

I agree with the OPs points but disagree with the degree to which the author has used them as a means to "hate" a language. I generally avoid Python too but saying you hate the language because of a bunch of contrivances mostly wrought from inexperience and holding too strongly to C like languages is poor form. Versions: Ok? Versioning and fragmentation is a hard problem. Backwards compatibility is a hard problem. Moving fast and never breaking anything is a nearly impossible problem. Python sucks at it, lots of things suck at it. There are many examples of other languages (.NET Core, for example), platforms, frameworks, etc that all suffer from this. It can be a reason to avoid those things but probably not one to base a loathing on. Also, lots of people still use Perl. Lots of people still love Perl. I don't know why. Installation: This screams "windows only" user. Path'ing, local dependencies, and package management is relatively common and you should force yourself to be comfortable with those concepts. Just saying "I should be able to just run one thing and be done forever", albeit ideal, is naive and never going to happen. Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces. Includes: Most of these complaints sound like they're coming from someone largely silo'd in the C/C++ world of wanting to know everything. "With C, you can just look in /usr/include/*.h" - the author is admitting he's unhappy because Python isn't C. Quirks: General complaints about other languages... and using those complaints to somehow sour Python? The quirks he does list for Python aren't even strange - they're pretty useful. Local Names: OP probably could have just included this in quirks rather than having another point. I'm pretty sure there's actually a means of avoiding this type of import issue by some silly Python pathing shenanigans.

ArchTypical 8y ago
> author is admitting he's unhappy because Python isn't C That's not the point at all. I mean, did you read it? How do you mischaracterize the specific point about the casual opportunity for foreign module metaprogamming? Module initialization is bad in a pernicious way. While you can't do operator overloading, you can clobber namespaces (which was referenced). Paired with a community repository, this is exactly the same case of what's so dangerous about npm.
- berdon 8y ago
  My point wasn't to devalue his arguments - in fact, I find them valid arguments. My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it. He complains about Python developers grep'ing directories when he admits to looking through just as arbitrary of a directory. His complaints about random code execution during import is valid but also seen as a feature _allowing_ metaprogramming. It's just as bad as C/C++ allowing clobbering over memory. These are features that come with trade-offs. The author is focusing _only_ on the trade-offs and how they don't exist in his favored language as a reason to hate the language. That's certainly fine for his subjective opinion but not as appropriate in a blog post where he is clearly trying to persuade others.
  - ArchTypical 8y ago
    > It's just as bad as C/C++ allowing clobbering over memory. That's a good parallel. > My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it. I have less familiarity with C/C++ than Python and I hate it because it's not about language perspective. It's bad language design, for such a high level language. Inclusion wrapped with execution is unsafe and has an easy fix for most language interpreters. Don't allow execution during a declaration. If you want to do metaprogramming, there are other ways that don't break the paradigm (rewriting files before inclusion, chaining programs, etc).
autoexec 8y ago
> Also, lots of people still use Perl. Lots of people still love Perl. I don't know why. Perl still holds a special place in my heart. It's so forgiving that it's perfect for banging out something that gets the job done in a couple minutes but while I most often use it for something quick and dirty you can still put in some time and planning to write something complex and maintainable too. I'm not sure there are major projects being written in perl today, but it's the language I still use for automation of day to day admin stuff and for pretty much all of my log/mail parsing needs.
mixmastamyk 8y ago
> Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces. Nope, for reasons I've explained up thread. In the meantime I suggest this code: from __future__ import braces
- berdon 8y ago
  Your reasons amount to "use an editor that shows whitespace". That's valid and would be my suggestion to people too but it doesn't address my comment. Using an editor for a "necessary" feature only helps you when you have it. If you, on an off-chance, don't have it then you're going to have a bad time. Comparing whitespace issues to brace-matching issues is a strawman. Braces are visible in 99% of editors.
  - mixmastamyk 8y ago
    I use nano or micro at times, which don’t, problem doesn’t happen there either. The benefits are enjoyed every single read of the code while the drawback is a potential issue (being very generous when I say) once every six months. Honestly happens about once every five years to me.

by berdon 8y ago

ArchTypical 8y ago

> author is admitting he's unhappy because Python isn't C That's not the point at all. I mean, did you read it? How do you mischaracterize the specific point about the casual opportunity for foreign module metaprogamming? Module initialization is bad in a pernicious way. While you can't do operator overloading, you can clobber namespaces (which was referenced). Paired with a community repository, this is exactly the same case of what's so dangerous about npm.

berdon 8y ago
My point wasn't to devalue his arguments - in fact, I find them valid arguments. My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it. He complains about Python developers grep'ing directories when he admits to looking through just as arbitrary of a directory. His complaints about random code execution during import is valid but also seen as a feature _allowing_ metaprogramming. It's just as bad as C/C++ allowing clobbering over memory. These are features that come with trade-offs. The author is focusing _only_ on the trade-offs and how they don't exist in his favored language as a reason to hate the language. That's certainly fine for his subjective opinion but not as appropriate in a blog post where he is clearly trying to persuade others.
- ArchTypical 8y ago
  > It's just as bad as C/C++ allowing clobbering over memory. That's a good parallel. > My point was he's using inexperience and/or familiarity with C/C++ as a reason to "hate" it. I have less familiarity with C/C++ than Python and I hate it because it's not about language perspective. It's bad language design, for such a high level language. Inclusion wrapped with execution is unsafe and has an easy fix for most language interpreters. Don't allow execution during a declaration. If you want to do metaprogramming, there are other ways that don't break the paradigm (rewriting files before inclusion, chaining programs, etc).

autoexec 8y ago

> Also, lots of people still use Perl. Lots of people still love Perl. I don't know why. Perl still holds a special place in my heart. It's so forgiving that it's perfect for banging out something that gets the job done in a couple minutes but while I most often use it for something quick and dirty you can still put in some time and planning to write something complex and maintainable too. I'm not sure there are major projects being written in perl today, but it's the language I still use for automation of day to day admin stuff and for pretty much all of my log/mail parsing needs.

mixmastamyk 8y ago

> Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces. Nope, for reasons I've explained up thread. In the meantime I suggest this code: from __future__ import braces

berdon 8y ago
Your reasons amount to "use an editor that shows whitespace". That's valid and would be my suggestion to people too but it doesn't address my comment. Using an editor for a "necessary" feature only helps you when you have it. If you, on an off-chance, don't have it then you're going to have a bad time. Comparing whitespace issues to brace-matching issues is a strawman. Braces are visible in 99% of editors.
- mixmastamyk 8y ago
  I use nano or micro at times, which don’t, problem doesn’t happen there either. The benefits are enjoyed every single read of the code while the drawback is a potential issue (being very generous when I say) once every six months. Honestly happens about once every five years to me.