Hacker News Reader

Comment by y7 | Hacker News Reader

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 differences "obvious flaws in design" that aren't improved because of "Incompetence? Politics? Who knows." This is especially bad given that Python (in my opinion) has a very well thought-out and transparent change process, with PEPs that usually consider most alternative solutions to a problem brought up, and being held to a high standard in order for the BFDL to approve them.

Especially regarding some of the points near the end, it seems that the author just doesn't understand Python. Python doesn't have or want a strong typing system, and it mostly wants an imperative style keeping lines short.

> Well... what's worse, having a slightly goofy looking inline "def", or having a gimped language?

Why is it such a problem to move your closure to its own line and give it a name?

View on HN

>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.

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.

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.

> 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.

> 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.

> 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.

> 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.

Whenever I have difficulty thinking of a good name for an intermediate step, I start to worry that my algorithm is unnecessarily complicated.

>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.

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?

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.

> 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.

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.

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.

Well, perhaps that means the right solution is not to complain about the language but to switch to Ruby (or Crystal) instead.. :P

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.

Reply on news.ycombinator.com