But anyone using typescript would just be Googling JavaScript syntax. Rarely is there anything Typescript-specific you need to look up while writing TS code.
Why do people care about so much lambda? If you want a function, use a real one. Python makes it easy to create throwaways everywhere. The only thing it enforces is proper indentation. What advantage should a lambda give you?
Naming things, especially functions that you tend to use in lambdas, is often hard. Imagine if you had to name a for loop to us it. That's how it feels.
filter(lambda x: x < 10, map(lambda x: x * x, [1, 2, 3, 4]))
But even for more complicated logic, it also doesn't seem like it's that burdensome to just throw a name on the lambda:
def square(x):
return x * x
def less_than_ten(x):
return x < 10
filter(less_than_ten, map(square, [1, 2, 3, 4]))
Which I find to be more readable/maintainable.
That's probably the most underrated feature of python. Decisions about how the language should function like this which seem "restrictive" from one perspective, and yet force you down the avenue of good decision-making for readability/maintainability. Sure, it's possible to write terrible python, but you're generally cutting against the grain to do it.
Yes you can do simple examples like the one I gave, but when it gets more complex you have to do what you did and name the functions, which is pretty horrible when they're just one-offs. It also makes the code read in a weird order.
That looks like a Ruby one-liner which is very OO (calling methods with blocks on everything, everything also being an object is very Smalltalk-esque).
Python's problem isn't a lack of lambdas, it's a lack of consistency; for some things you use functions and for others methods.
I know what lambda is, I just don't see any usecase where the limitation is a problem. If your lambda is so complex that you need more than a oneliner, then what's big thing with using a nested function?
The list defined above is [1, 4, 9], but the one you just defined is [1, 4, 9, 16]. It's interesting how the shift in notation subtly confused the semantics of what's going on.
Good point. I missed that and made a mistake. It should have been:
[x * x for x in [1, 2, 3, 4] if x * x < 10]
There is a subtle shift in semantics. The functional form defines a sequence of function applications whereas the list comp notation is more of a declaration.
You can write this as a oneliner too. But the problem here is not lambda, but the lack of map/filter-methods on list. Disputable whether this is good or bad.
I thought what you wrote wasn't valid because xx isn't defined in the scope of the inequality... however I now realize that's because Hacker News deletes the asterisks. In any case, it's
[x [asterisk] x for x in [1,2,3,4] if x[asterisk] x < 10]
which is still a little annoying because the x [asterisk] x gets computed twice. This is one of those little details that really annoys mathematicians, as I saw with SageMath for decades (I started SageMath -- which uses Python -- and got no end of complaints about the above). In the Magma programming language there is a "where" version of comprehensions that eloquently solves this problem as explained here: http://magma.maths.usyd.edu.au/magma/handbook/text/10
If it's too complicated for a lambda, you shouldn't be using a lambda. Define a separate function if it takes you more than a line or it's harder to reason about.
People all know lambdas are expressions only, it's not a biggie really. In all honesty you rarely inline complex lambdas with all you mentioned, it would become hard to read or debug.
Python's competition isn't PHP; it's Typescript.