Hacker News Reader

Comment by andreasvc | Hacker News Reader

Can you please explain to me what's important about these functions being anonymous? Why, specifically, they shouldn't be given a name?

How do you define working "efficiently with higher-order functions"? Given that Python fully supports higher-order functions, I am really curious what you could mean. I didn't downvote you, but it may have to do with your pointed assertion here, without anything in the way of an argument.

As to "ordering matters"; sure, but as the functions a nontrivial program calls are inevitably described as a graph, they must necessarily be defined in some arbitrary linear order anyway.

View on HN

    some_collection.where(x -> x.name == 'foo').sort_by(x -> x.age)

These functions are tiny and trivial. They don't need names, and if you were to give them names, the extra weight becomes burdensome. Not just in syntax duplication, but the redundancy of the name as a comment on the trivial function body.

    nameIsFoo = x -> x.name == 'foo'
    getAge = x -> x.age
    some_collection.where(nameIsFoo).sort_by(getAge)

Note that giving the functions names has also changed the source order of the function bodies. Now you need to do a mental cross-reference to follow, instead of being able to read the definitions inline.

Sure, but those are one-line functions, which Python supports through lambdas. (Incidentally, some of them could be done with the operator module, without defining a new function). I would argue that once you write a multi-line function, it makes sense to give it a name and define it separately, which makes the "no multi-line anonymous functions" complaint less pressing.

Let me give you an example from my experience.

I wrote an elegant parser definition library, used for parsing specialized output of ... never mind.

It had hierarchic specifications (regular expressions etc) of parsing states, along with anonymous functions which stored away parsed data and sent the parser among different states.

New juniors could after a few hours use this to quickly parse complex text documents.

I cursed a lot while trying to port this to Python. :-( A dozen named sub-ten lines functions specified by names and referenced inside a parser structure? Just didn't work.

Edit: The point is, there are use cases where real lambdas are useful (except from map etc). It is just weird to argue otherwise.

I'm a python guy and I totally agree that multiline anonymous functions greatly enhance the readability of code in certain applications. You can do everything with named functions, but it's not always the best method for conveying meaning.

I can live without multiline anonymous functions - but I'd make use of them if they did exist.

Imagine having to build functions with names for each while, if/else and foreach statements. Because that's what it feels like when working with async I/O in Python, a complete pain in the ass compared to other languages.

Scala sample:

      cache.get[String]("name").flatMap {
        case Some(value) => value
        case None =>
          database.query("names").head.flatMap {
            case Some(id, value) =>
              cache.set("name", value, 10.minutes)
                .map(_ => value)

            case None =>
              Future.successful("Anonymous")
          }
      }

BTW, in this sample, for comprehensions are not that useful. But if you're using Scala-Async, you can write that in a style resembling blocking I/O:

      async {
        val cached = await(cache.get[String]("name"))

        cached match {
          case Some(value) => value
          case None =>
            val fromDB = await(database.query("names").head)
            
            fromDB match {
              case Some(id, value) =>
                await(cache.set("name", value, 10.minutes))
                value

              case None =>
                "Anonymous"
            }
        }
      }

In both cases multi-line anonymous functions are leveraged.

Reply on news.ycombinator.com