4 ms·

There is no excuse for missing multi-line lambdas other than negging on programmers.

• xapata 9y ago
  Really, is it that hard to come up with a name for your function?
  • KirinDave 9y ago
    I don't even understand why your question is relevant.
    • rjeli 9y ago
      If you want a multi line lambda: def print_each_twice(xs): map(lambda x: print(x) # whoops, impossible You can define a local function: def print_each_twice(xs): def print_twice(x): print(x) print(x) map(print_twice, xs) The former is more intuitive to write. The latter reduces nesting, makes you name the function, and improves readability IMO. It's currently easy to scan blocks of Python and see each indentation level starting with one of a few keywords (class, def, for, with). Adding multi line lambdas would make the ultra simple structure harder to quickly parse.
      • KirinDave 9y ago
        > If you want a multi line lambda: I don't want this though. This doesn't do what multi-line lambdas do. It can never do what lambdas do. It's not a lambda function if it's named and fully pre-computed. > Adding multi line lambdas would make the ultra simple structure harder to quickly parse. This is just about the least compelling argument I've ever heard. "The parser writers are not going to have fun."
        • rjeli 9y ago
          I meant to parse mentally. Control flow in Python is very easy to mentally parse at a glance. Powerful lambdas get rid of that. It's an extremely contrived example, but from the code I posted, it should just be: for x in xs: print(x) print(x) Much easier to read because there's only one way to write it. Hence GVR shunning map/reduce/filter.
          • KirinDave 9y ago
            GVR is wrong. It's okay to be wrong. But the last 5 years of software development and the remarkable growth of Javascript as a platform accessible to everyone make a compelling case that GVR was wrong.
            • empthought 9y ago
              No it doesn't. It makes the case that the browser is the most pervasive and flexible application runtime, which we already knew. Server-side JavaScript was never a thing until that was solidified, thus providing a large developer base.
              • KirinDave 9y ago
                Why is this a meaningful distinction? Who cares if it's server or client side in this discussion? The Python community has said passing anonymous closures is too complex, the majority of the industry disagrees and has pushed forward. Lambdas are everywhere BUT Python now. Javascript is even pushing forward with more sophisticated constructs to help them build custom monadic constructs, and shipping a super useful monadic construct in syntax. C# has been doing that for years. Java will soon as well. The rest of the industry has moved on from this conceit and you can't really argue that it's made environments like Javascript overwhelming to newcomers. If Python 3 could just get over this conceit, its maintainers could start solving major Python problems really quickly. E.g., Python's janky iteration primitives could be replaced in an afternoon or three with equivalent but cleaner and clearer options.
                • 9y ago
        • maxerickson 9y ago
          Maybe I misunderstand what you mean with "fully pre-computed", but local functions in Python close over local scope at runtime: >>> def splatter(t): ... def f(): print(t) ... return f ... >>> beep=splatter("beep") >>> boop=splatter("boop") >>> beep() beep >>> boop() boop That's the problem with Python, everything is dynamic.
          • KirinDave 9y ago
            I meant structural precomputation. But yeah, I forget you can discard names. You're right: through sufficient use of discarded intermediate bindings you can replicate multi-line lambdas. Still, the existence of this sorta demands we ask, "So why can't we use it then?"
            • maxerickson 9y ago
              I'm not steeped in functional programming, but isn't anonymity the least interesting part compared to being first class and forming closures?
              • KingMob 9y ago
                I don't really see it as an FP thing at all, because the same argument can be made with respect to variable names. The issue is that without serious anonymous functions, you're forced to come up with more names, increasing cognitive load. An anonymous fn clearly communicates "I'm not going to be used elsewhere".
                • xapata 9y ago
                  So call it something generic related to usage: keyfunc, repeat, parse, callback, etc.
                  • KirinDave 9y ago
                    Why increase the complexity and density of the code while complaining that the alternative would be too complex though? If I can simulate anonymous functions with locally scoped functions that then behave as lambdas then what hill is Python dying on here? The "we don't want to submit a patch to make our parser do this?" Hill? It's definitely possible to do. So...