5 ms·

Very short-sightedly written. It sounds like the author just wants a language with a different philosophy, and instead of realizing this goes on to call the di

• coldtea 10y ago
  >Very short-sightedly written. It sounds like the author just wants a language with a different philosophy Which is not a priori bad to want, especially if a language has a broken philosophy (or partially broken) to begin with.
  • y7 10y ago
    The only way I see a philosophy as being a broken one if it is founded on false premises, or internally inconsistent (or do you see a different way?). Which is the case with Python and why?
    • LeifCarrotson 10y ago
      A philosophy should also be considered broken if it is not useful for any purpose. By extension, it could also be considered broken if it is needlessly less useful than it could be for its intended purpose.
    • coldtea 10y ago
      Instead of philosophy what you say applies more to logical statements (they are broken if they are founded on false premises or are internally inconsistent). A philosophy is more malleable and ad-hoc than axiomatic logical statements, and it can just be bad because it doesn't offer satisfactory solutions the problems it claims to have tackled, or because it sidesteps certain things, etc. But even that is taking the "broken philosophy" allegation too literally. The author simply means that Python would be a better language if it offered more capable closures and more easy access to functional programming. And why one might argue about the "better", there's no arguing that Python would be more expressive if it did so.
      • y7 10y ago
        > And why[while?] one might argue about the "better" This is my point. Python's philosophy isn't "bad" in a universal sense (let alone broken). It's just that the author has a different philosophy for programming languages himself. And I find it short-sighted to regard other philosophies as "bad" or "flawed", simply because they do not match your own.
        • coldtea 10y ago
          Yes, I meant to write "while" (my comments are usually hastily written while waiting some build to finish and full of typos). >And I find it short-sighted to regard other philosophies as "bad" or "flawed", simply because they do not match your own. Sure, but isn't a "all philosophies are equal" also misleading? Some philosophies can be inherently worse than one's own.
  • yxhuvud 10y ago
    Well, perhaps that means the right solution is not to complain about the language but to switch to Ruby (or Crystal) instead.. :P
    • coldtea 10y ago
      Wouldn't that come with its own can of worms? At some point, you try to fix what you think is already closer to what you want or what you have legacy code using it.
• Grue3 10y ago
  >Why is it such a problem to move your closure to its own line and give it a name? What if it cannot have a meaningful name? You don't give a name to every single value in your program, why would first-class functions be any different? Like, there's an idiom in python where you write a function named "wrapper" in a decorator and then return wrapper. Except you put @wraps on it, so the name of this function isn't even "wrapper" anymore. So what was the point of naming it "wrapper" when you could just do ```return wraps(lambda ...)``` if lambda wasn't so underpowered.
  • y7 10y ago
    The name of the function when you read the code is still wrapper. The point of naming it is that it allows you to refer back to it, as well as provide the reader with a clue to what it does. This way, Python attempts to reduce nesting, which reduces ease of reading. You see this a lot in Javascript, with all the anonymous functions being passed around. Besides that it makes your stack trace hard to parse, it also makes it hard to follow if you're currently reading a named function, or an anonymous function that's being passed as a parameter inside another anonymous function, etc.
  • amyjess 10y ago
    > You don't give a name to every single value in your program There are lots of times I name single-use values because I want to throw it to the logger before I pass it to whatever function is going to use it.
  • nhumrich 10y ago
    Then give it a stupid name. "helper_func", "inline()", or even "_a". If you think the name isn't important, then don't waste your time on it.
• __david__ 10y ago
  > Why is it such a problem to move your closure to its own line and give it a name? That's actually one of my bigger beefs with Python: it forces a large naming burden on the programmer. When writing python code I find myself struggling to name intermediate results or stupid functions that should just be lambdas. Very very often those results don't warrant a name, or are unnameable. Also, naming something implies it will be useful in another context, which one-off lambdas rarely are.
  • ctrlc-root 10y ago
    > Also, naming something implies it will be useful in another context, which one-off lambdas rarely are. Not necessarily. I find it helps readability to do this: def prunde_indices(indices, cutoff): def match_old_index(index): return index.timestamp < cutoff old_indices = filter(match_old_index, indices) # ... do things with old_indices as opposed to using an anonymous lambda. That doesn't mean I have to reuse it outside of this function.
  • xapata 10y ago
    Whenever I have difficulty thinking of a good name for an intermediate step, I start to worry that my algorithm is unnecessarily complicated.
  • dragonwriter 10y ago
    > Also, naming something implies it will be useful in another context, which one-off lambdas rarely are. Naming something in a local scope doesn't imply that it will be useful other than at least one place on that local scope. In fact, it's a pretty clear indication that you don't expect to need it anywhere outside of that scope.