Hacker News Reader

Comment by 9t3h4r3o5w1a4w2 | Hacker News Reader

Python has lambda but they are one liners.

There is no way to do write this in Python:

   someFunc( _ => {
       // this is 
       // a function 
       // with multiple lines
   })

Having to define a named function to use it as a callback is a pain in the ass.

Python has an excellent standard library but the language itself is pretty mediocre IMHO. Classes are an afterthought thus verboses, as so is "functional programming" in Python.

JS biggest issue is that it is not strongly typed enough. But ES2015 makes it really pleasant to use.

View on HN

I know the lack of multiline lambdas is a common criticism of Python, but I've never really understood it.

Typing

    someFunc( _ => {
       // this is 
       // a function 
       // with multiple lines
    })

Is only one line shorter than

    def foo ():
       // this is 
       // a function 
       // with multiple lines

    someFunc(foo)

There is a case to be made that the second version is more legible and that exposing the function foo makes unit testing it possible. I can understand why people might slightly prefer one or the other, but I honestly can't understand the intensity of opinion around this seemingly very minor syntactic difference.

I'm curious what you find verbose about Python classes as:

    class FooBar():
        text = "Hello World!"

        def hello(self):
            return self.text

feels fairly terse to me.

The problem with python class definition is the need to write instance vars 3x:

    def __init__(self, foo)
        self.foo = foo

There is an attrs package and new proposal (https://github.com/ericvsmith/dataclasses/blob/master/pep-xx...) to remedy that.

Yeah, I guess I normally don't deal with enough properties like that for it to be a big deal in my workflow. When it's come up I've generally done something like:

    class Foo:
        bar = 42

        def __init__(self, **kwargs):
            self.__dict__.update(**kwargs)

But I agree that's not a super robust solution

the problem is callbacks as a pattern

if you have a multiline function it should be named and unit-tested instead of just stuffed anonymously into some pyramid of doom

> if you have a multiline function it should be named and unit-tested instead of just stuffed anonymously into some pyramid of doom

It's like saying all data should be declared as variable, in the functional programming paradigm, functions are data. That's why closures are useful. And it has absolutely nothing to do with unit-testing, that's beside the point. Javascript is not harder to unit test because it has fully featured anonymous functions.

> Javascript is not harder to unit test because it has fully featured anonymous functions.

It is if you actually use them. ;)

what does functional programming have to do with it? you still unit test functions in functional programming surely?

> It's like saying all data should be declared as variable, in the functional programming paradigm, functions are data. That's why closures are useful.

I don't think you understand what you're talking about. We were already talking about using 'functions as data', and closures and anonymous functions aren't the same thing.

But anyway, how do you unit test an anonymous function?

I assume you mean that you don't, you just test the bigger context around it. But that was my point, once your anonymous function starts becoming much bigger than a one-liner it ought to be tested itself.

>> Having to define a named function to use it as a callback is a pain in the ass.

Happy debugging!

Reply on news.ycombinator.com