5 ms·

I just can't understand anyone who is black and white. I like when I have both tools at my disposal: recursion and iteration.

hueving 11y ago
when you have a project concerned with readability, adding new features is a huge community cost in the long run because it's one more thing you have to learn to deal with as you go across projects. One of the wonderful things with python is that you can dig into the code of most python projects and not have to worry much about completely different idioms requiring a complete context switch to understand how they work. He is not really being black and white, he is doing a service by preventing language bloat ala C++ as much as possible.
- mhd 11y ago
  It always struck me as a reaction against Perl's "Tim Toady" approach, encouraging a more idiomatic and unified programming strategy to ease comprehension and teaching (IIRC the origin of Python, or at least ABC).
- sklogic 11y ago
  This is exactly what makes Python a bad language. Lack of expressive power results in an unnecessary complexity of the code. It's much easier to comprehend a short, compact code written in the familiar, domain-specific idioms rather than digging through convoluted pile of low-level leaky idioms like loops, list comprehensions, generators, classes, recursion and all that irrelevant crap.
  - afc 11y ago
    Just wanted to add my voice: this matches exactly my perception. I used to really like Python, but I've come to the conclusion that there's a certain point in terms of the complexity of a Python program where everything just blows up and it's next to impossible to keep it from becoming a tangled mess. This point is reached incredibly soon, something like five classes with some inheritance, some interface/virtual/abstract class. Ugh. Now I avoid Python as much as possible, much preferring C++ or Java, which I think work incredibly better for larger programs.
kyllo 11y ago
I used to think I needed both, but since picking up Haskell I don't miss for loops at all and I rarely need to use explicit recursion either--now I almost exclusively use higher-order functions like `map`.
- Retra 11y ago
  When I started learning Python, I always used map and filter because they were just how I thought about problems. But there is a certain bit of elegance to being able to write [process(child) for child in node if child is not None] in lieu of map(process, filter(notNone, child)) The functional style makes better use of conceptual primitives, but the imperative style is generally better for documenting. for child in node: if child is not none: # Comment explaining decision. process(child) # Comment explaining more stuff.
  - gnud 11y ago
    I think LINQ got this very nearly right. You can write this LINQ-style from child in node where child != null select process(child) or with extension methods node.Where(c => c != null).Select(process)
  - foobarian 11y ago
    I'm actually a bit scared of using recursion in production (at a web company). It has its place of course, but gratuitous recursive code that could have been written without gives me pause. It's too easy to miss an edge case and end up with a stack overflow, and that can bring down a whole server farm.
  - rhaps0dy 11y ago
    The first thing you show is a list comprehension [1], and it's still very much functional style, even if it has a "for" in it. Heck, Haskell has pure list comprehensions. [2] [1] https://en.wikipedia.org/wiki/List_comprehension#Python https://en.wikipedia.org/wiki/List_comprehension#Python [2] https://en.wikipedia.org/wiki/List_comprehension#Haskell https://en.wikipedia.org/wiki/List_comprehension#Haskell

hueving 11y ago

when you have a project concerned with readability, adding new features is a huge community cost in the long run because it's one more thing you have to learn to deal with as you go across projects. One of the wonderful things with python is that you can dig into the code of most python projects and not have to worry much about completely different idioms requiring a complete context switch to understand how they work. He is not really being black and white, he is doing a service by preventing language bloat ala C++ as much as possible.

mhd 11y ago
It always struck me as a reaction against Perl's "Tim Toady" approach, encouraging a more idiomatic and unified programming strategy to ease comprehension and teaching (IIRC the origin of Python, or at least ABC).
sklogic 11y ago
This is exactly what makes Python a bad language. Lack of expressive power results in an unnecessary complexity of the code. It's much easier to comprehend a short, compact code written in the familiar, domain-specific idioms rather than digging through convoluted pile of low-level leaky idioms like loops, list comprehensions, generators, classes, recursion and all that irrelevant crap.
- afc 11y ago
  Just wanted to add my voice: this matches exactly my perception. I used to really like Python, but I've come to the conclusion that there's a certain point in terms of the complexity of a Python program where everything just blows up and it's next to impossible to keep it from becoming a tangled mess. This point is reached incredibly soon, something like five classes with some inheritance, some interface/virtual/abstract class. Ugh. Now I avoid Python as much as possible, much preferring C++ or Java, which I think work incredibly better for larger programs.

kyllo 11y ago

I used to think I needed both, but since picking up Haskell I don't miss for loops at all and I rarely need to use explicit recursion either--now I almost exclusively use higher-order functions like `map`.

Retra 11y ago
When I started learning Python, I always used map and filter because they were just how I thought about problems. But there is a certain bit of elegance to being able to write [process(child) for child in node if child is not None] in lieu of map(process, filter(notNone, child)) The functional style makes better use of conceptual primitives, but the imperative style is generally better for documenting. for child in node: if child is not none: # Comment explaining decision. process(child) # Comment explaining more stuff.
- gnud 11y ago
  I think LINQ got this very nearly right. You can write this LINQ-style from child in node where child != null select process(child) or with extension methods node.Where(c => c != null).Select(process)
- foobarian 11y ago
  I'm actually a bit scared of using recursion in production (at a web company). It has its place of course, but gratuitous recursive code that could have been written without gives me pause. It's too easy to miss an edge case and end up with a stack overflow, and that can bring down a whole server farm.
- rhaps0dy 11y ago
  The first thing you show is a list comprehension [1], and it's still very much functional style, even if it has a "for" in it. Heck, Haskell has pure list comprehensions. [2] [1] https://en.wikipedia.org/wiki/List_comprehension#Python https://en.wikipedia.org/wiki/List_comprehension#Python [2] https://en.wikipedia.org/wiki/List_comprehension#Haskell https://en.wikipedia.org/wiki/List_comprehension#Haskell