Live data from Hacker News

Stop writing lambda expressions in Python

treyhunner.com

161–170 of 202 posts

Re: Stop writing lambda expressions in Python

#161

Earlier quoted context omitted.

Why does it need that, though? What's wrong with just naming the function?

There's real readability and clarity to positioning an anonymous function right at the point in the code that it will be used. When you name and define a function some other place and use it elsewhere, you have increased the overall complexity. What is this named function? Where is it used? Is it accessed by other bits of code? Should it be? All these questions come up when you see a named function. It is in fact les…

So if I understand correctly, in Javascript a fat arrow is just the syntax sugar for:

    var x = function(x){ return x };

Re: Stop writing lambda expressions in Python

#162

Earlier quoted context omitted.

Python is fundamentaly flawed, since it's based on lines (and significant indentation), and foremost, since it's based on statements, and not only on expressions. Lambda expressions look in python like a sore spot, because Python stresses so much statements, and procedural programming. IIRC, recently we've seen passing a paper in hacker news, that let beotians write programs, and only ~10% IIRC (or less) of their ute…

I've seen people make the distinction between statements and expressions in the past, but I don't get the significance. I mean I understand what they are but I don't understand why people view the concept as such a big deal. Are there any resources explaining this which you would recommend?

Expressions can be nested arbitrarily and infinitely — like in math. You can take “x * x” and “3 * x” and add them into “xx + 3x”. You can pass that to a function like “log(xx + 3x)”. You could then divide that, square root it, on and on. You can combine the expressions however you want.

Statements can also be combined, but in a separate way. You have control flow blocks, and inside of those you have one serial list of statements. Control flow blocks and statements can only go in other control flow blocks, and not in expressions.

If you’re coming from languages like C or Python, that might not seem like a huge deal. Why would you want “x = 5” or “while y Languages that focus more on expressions have surprisingly simple ways of expressing some things, though.

In Rust, “if” statements are fully expressions, so you can assign them:

    let x = if y > 10 {
        let a = readLine().parse();
        let b = readLine().parse();
        a + b
    } else {
        y * 2
    }
Another neat feature is that macros can return blocks, and you can still call those macros wherever you like. For example, in the standard library, there is a “try!” macro that checks if a value is successful. It expands basically into:

    if result is successful {
        result.value
    } else {
        return result.error
    }
The “return” there basically causes the error to short-circuit up the stack. In practice, that means that you can use “try!” to simply say “give me the successful value, and if there was an error, just send it up the stack.”

If you wanna get really fancy, languages like Haskell and Elm don’t have side effects, so things like “x = 5” don’t exist. There are only expressions. You can create values that represent doing something (kind of like Redux actions), and there are lots of tools for combining those action values. Because it’s all expressions, you can combine them arbitrarily. If you have a common case for how you combine your effects, you can just make a plain old function for it, because it’s all just expressions.

Re: Stop writing lambda expressions in Python

#163
for the record, the 'useless function call' paragraph is known as eta-conversion in the FP world. see: https://wiki.haskell.org/Eta_conversion

First line says:

    An eta conversion (also written η-conversion) is adding or dropping of abstraction over a function. 
    For example, the following two values are equivalent under η-conversion:
      \x -> abs x
    and
      abs

Re: Stop writing lambda expressions in Python

#164

Earlier quoted context omitted.

There's real readability and clarity to positioning an anonymous function right at the point in the code that it will be used. When you name and define a function some other place and use it elsewhere, you have increased the overall complexity. What is this named function? Where is it used? Is it accessed by other bits of code? Should it be? All these questions come up when you see a named function. It is in fact les…

So if I understand correctly, in Javascript a fat arrow is just the syntax sugar for: var x = function(x){ return x };

The two biggest differences iirc:

- it can never be named

- it inherits `this` lexically from its parent scope (which imo is the sane default)

Re: Stop writing lambda expressions in Python

#165

Earlier quoted context omitted.

There's real readability and clarity to positioning an anonymous function right at the point in the code that it will be used. When you name and define a function some other place and use it elsewhere, you have increased the overall complexity. What is this named function? Where is it used? Is it accessed by other bits of code? Should it be? All these questions come up when you see a named function. It is in fact les…

So if I understand correctly, in Javascript a fat arrow is just the syntax sugar for: var x = function(x){ return x };

It also changes the behavior of this. [0]

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Stop writing lambda expressions in Python

#166
post #9
post #3

So in Python, imperative style is often more idiomatic than code that uses lambda expressions. While in some functional languages (Haskell) and array programming languages (J), tacit or point-free style is often more idiomatic than lambda expressions (or equivalent). There's something funny about that.

Many of the suggested alternatives to lambdas in the article are non-imperative though... they just don't use 'lambda'.

Certainly, and I do agree with most of the article. But the instances where lambdas are better replaced with an ordinary function don't use a different programming paradigm. My observation was about how different communities consider different paradigms idiomatic in situations where you get to choose.

Re: Stop writing lambda expressions in Python

#167
Another post about discussing a functional programming tool in [insert language with a different primary paradigm here], another few threads from the functional programming fans stating how their preference is absolutely correct and how that paradigm is veritably better than any other.

It isn't, it's just a different way to approach programming.

As for the article, it isn't really a case against lambdas themselves, just against misusing them. It certainly didn't make a strong enough case for me to stop using them.

Re: Stop writing lambda expressions in Python

#168
post #89
post #80

Earlier quoted context omitted.

Van Rossum started to work on Python in 1989 and released the first version in 1991. Python is modern in the sense of being still very well alive but it's deeply rooted in the 80s, and it shows with all those double underscore __magic functions__, the self argument in methods (the way we were doing object oriented programming in C, without the ++) and others. Compared to JavaScript it didn't evolve it's syntax much.…

`self` is about being explicit with parameters. Rust does the same thing and that's a more "modern" language. The `__magic__` is about avoiding naming conflicts while still being explicit. It's a choice between magic or reserving a lot of names.

Or use normal method names chosen by the class author like for example Ruby and many other languages. In the case of the standard library it's easy to be consistent. I concede that in any other case it can be hard or impossible.

About self, it's so strange to define a method with 2 arguments and call it with only one. Not only it's strange, it feels the opposite of being explicit. Most other languages manage to do without that self (Java, Ruby).

I run into another oddity today. Yesterday if forgot about

    a = 0
    if not a:
        print("like in C")

Re: Stop writing lambda expressions in Python

#169

Earlier quoted context omitted.

I think, it was an example of intentional hostile design (say, see this video https://www.youtube.com/watch?v=NWZLB8CyPbM for what I mean). All, seemingly for the sake of that "only-one-way-to-do-things" goal. EDIT: (Van Rossum's own explanation of why he thinks lambda's design is okay: https://www.artima.com/weblogs/viewpost.jsp?thread=147358 )

Do you have any evidence for your hypothesis about hostile design? The phrase, by the way, is "one obvious way".

Guido van Rossum said that many times that he does not like functional primitives. It is pretty well documented in his own writing that he had no intention of making functional programming very convenient in the language.

Re: Stop writing lambda expressions in Python

#170

Earlier quoted context omitted.

Private functions do not restrict the usage of that function to one point in the code. There's a world of difference between a coding convention - essentially a comment to say "please don't access this function from outside the current class" versus it simply being impossible to do so. And the "private" convention does not say "don't use this function at any other point except one", it says "please don't access this…

As a user of JavaScript and es6, fat arrows are only necessary if you haven't started using async and await syntax, and I found myself almost never using fat arrows after moving to async/await. Indeed naming my functions resulted in more testable and clearer code.

While I can see async/await replacing a lot of the most common use in JS, anonymous functions have a lot more uses than that (passing a single use function to generic algorithm, like an ordering function to a sorting routine, is one of the more common other uses, across languages.)
Post reply on HN