Guido was right, there should be no lambda in Python (2018) (pbrown.me)

    λx.λy.λz. x (y z)

    λ x y z . x (y z)

The author is complaining that Python doesn't use a dialect of lambda functions used in Haskell. Which is true. Python isn't Haskell and shouldn't be.

Partial function application:

    incr = partial(add, 1)
    # or
    def incr(x):
        return add(x, 1)
    z = incr(4)

Currying is function that returns a function:

    def curried_add(x):
        def inner(y):
            return add(x, y)
        return inner
    z = curried_add(1)(4)

This one is backwards: the benefit is forcing beginners to write well-formatted code. You would not believe the insane things people just learning can come up with, when in a C-style language where indentation doesn't matter.

  foo((lambda x, y:
         for i in range(x):
           y += i
         return y),
      20
  )

Languages which do that have issues representing very useful software engineering tools: optional arguments, variadic arguments and keyword arguments.

Currying is related to partial application; it refers to a technique for representing multivariate functions using only functions of one argument.

E.g. to obtain some f(x, y, z) we instead make it f(x)(y)(z), where f is a one-argument function applied to (x). That yields an anonymous one-argument function that is applied to (y), and that again yields a one-argument function applied to (z), which finally calculates f(x, y, z).

Whereas partial application is this: we already have a bona fide three-argument f(x, y, z), and the ability to call it with all three arguments at once. But for some reason, we call it as f(x)(y)(z). Now f needs 3 arguments but is called with just one, (x). So an anonymous two-argument function is produced which, if given two arguments will combine those with the one that was given and call f. Alas, that function is given only one argument, so it returns another one-argument function. When that one is given an argument, it all unwraps, and f ends up being called. These anonymous functions are understood to be produced because our notation is understood to have implicit partial application semantics. Under currying, things aren't implicit; f(x) is written as a one-argument function, which will have a lambda term in it. There is nothing to be implicit about in terms of application: all functions have one argument.

> To get it in Python you'd need to do this:

> f = lambda x: lambda y: x + y

> This makes the currying explicit. In general, currying is taking an n-ary function and reducing it to a series of n unary functions.

Something's gone wrong; your example of explicit currying conflicts with your definition of currying. `f` is a unary function.

The lambda keyword is long which makes it a pain, but currying really is equivalent to specialised partial application right? People seem to love currying so much I feel like I don't understand something here.

For context I work a lot with java, R, and Python which all have anonymous functions and higher order functions, but are all decidedly _not_ "functional languages".

Indeed it has. It is a very accessible (and even moreso "available") language.

But it has so many odd (and frankly wrong) peculiarities that big projects tend to become more difficult more quickly because of the mess that is most Python code. Some of the footguns are so rediculous that you cannot believe they exist; and even more astounding is the apologist arguments for why they should be the way they are. This one is my favorite: https://stackoverflow.com/questions/1132941/least-astonishme...

Since it is so accessible and has such a rich ecosystem, someone with little skill can cobble together a system which works well enough to get to production. But that junior developer pay rate cost (and ease of hiring) will mean that as the project matures and more and more features are added, the code more rapidly becomes incomprehensible. Everything being mutable, no types (except for bolted on, visually noisy, non-runtime linters), OOP missing some of the key information hiding features, awkward or half-baked functional features, and time/space performance problems all combine to make Python a terrible choice for non-prototype level projects.

Later ECMAScript editions have made good improvements, but there are still plenty of sharp edges and footguns in Javascript which simply do not need to exist.

Javascript is a leading language because _practically_ speaking (not strictly speaking) it is the only language you can use if you want to make things happen in the browser. And it came with every major web browser since the late 90s. THAT is why it gained immense marketshare.

Python has been included in Linux, *BSD, and macOS for years. It's a very simple language to make things happen with little effort; it is "accessible" to most people, particularly non computer scientists. It reads a little bit more like English than other languages, and it doesn't require compiling (again to accessibility).

All these things don't mean it's good. But it got picked up by non-developers and used to solve real world problems and a lot of research problems. More and more specialized modules were written for it, making it even easier to solve many problems.

So its accessibility and ecosystem have been good. But that doesn't mean it's good for building big, long lived, easily maintainable or extensible systems. It certainly doesn't mean it's good for building performant systems.

See elsewhere in this thread for my link to my biggest complaints (from an old discussion). I'm not a recognized expert on language design, but I've written significant quantities of production code in several languages, including Python, over many years.

No doubt people may disagree with my assertion, but using popularity as evidence of disagreement is not valid since popularity often does not correlate to the quality or suitability of something. History is full of companies, technologies, and practices where the most popular was absolutely not the best.

See this thread if you want more than a few examples of how Python is poorly designed (as compared to Ruby): https://news.ycombinator.com/item?id=32116957

IMO the biggest issue is that they add features with absolutely no regard to how you could implement it with good performance. There are also a ton of features that let you do things that are just a really bad idea. Look at something like __subclasses__. Encourages terrible coding practices! (I learnt about it by reading some terrible code my colleagues wrote.) And good luck JITing that.

There's also a ton of syntax that is weird and asymmetric, like list comprehensions. Also the fact that you don't need to explicitly create variables is very error prone. Some of that is excusable given how old Python is but that doesn't mean it isn't bad.

Oh and import resolution. That's just downright terrible. No excuse there. I'd almost take #include over the insane mishmash of different ways imports work. It's even worse than JavaScript's module disaster.

There is a method on all objects which are a collection:

    __len__()

    x = [1,2,3,4]
    print(x.__len__())  #4

    y = "abcdefg"
    print(y.__len__())  #7

    z = { "a": "b", "c": "d"}
    print(z.__len__())  #2

You can either implement a single function that handles the various types or you can add a method to each type, but the latter can be pretty tedious when you're implementing a bunch of functions / methods that operate on numerous types.

I ran into this when I started implementing map() for a few builtin types and found myself duplicating the loop-over-items code and started thinking, "Hmm, I wonder if this is why Python implemented len(), map(), etc as functions instead of methods."

Of course, you could implement an abstract class or equivalent for the generic aspects of len(), map(), etc, but then that gets pretty complex too.

So, based on that, which to reiterate is just a guess, I don't think the decision is bizarre at all. It's just an implementation tradeoff.

From a developer point of view, I slightly prefer method syntax for aesthetic reasons, but practically speaking it doesn't make any difference whether I type obj.len() or len(obj), and IMO neither is more or less object-oriented than the other (which is a common complaint about len() et al).

It's funny how Java developers perceive "lambdas" as (param, param) -> { code } blocks to be used in consumers and iterators etc. This is a weird mutation of the general concept due to Java's lack of functions: as a Lisp developer I don't perceive lambda expressions like that at all. The use of lambda expressions is much more general than this: it's simply the creation of function pointers for many tasks. For me, nearly 100% of the time it's to create them to be stashed away as callbacks. And in Java, the only realistic way to do this still is with anonymous classes.

    mult_10 = partial(mult, 10)
    mult_10_20 = partial(mult_10, 20)
    print(mult_10_20(30))