3 ms·

The downside is that lambdas are usually a bit more complex to write/read than plain old scope blocks. The very nice upside would be that you could make the in

The downside is that lambdas are usually a bit more complex to write/read than plain old scope blocks. The very nice upside would be that you could make the inputs to the blocks explicit. In contrast, the fact that foo1 is an input to step1 and foo2 is an input to step2 can only be understood by careful examination.

archagon 12y ago
In the languages that I'm using (JS, and now Swift), lambdas are only marginally more difficult to write than a pair of brackets. In fact, in Swift, you actually can't write a pair of brackets to designate scope, but you can put stuff in a lambda if you wish.
a-nikolaev 12y ago
I don't see how you want to use first-class functions, lambdas, in this situation. Maybe, you meant to say nested functions? Lambda function is a piece of code that is usually sent somewhere else, a callback basically. If you define a lambda function instead of a block of code and call it right there, it would create a considerable overhead: because if it is a closure, it should save its current scope somewhere. And it is really unnecesary, if you call this function right at the same place where you define it.
- corysama 12y ago
  sjolsen did a good job of illustrating what I meant https://news.ycombinator.com/item?id=8375341 https://news.ycombinator.com/item?id=8375341 Improvements on his version would be to make everything const and the lambda inputs explicit. AwesomenessT largerFunction(Foo1 foo1, Foo2 foo2) { const ResultT1 result1 = [foo1] { const Bar bar = barFromFoo1(foo1); const Baz baz = bar.makeBaz(); return baz.awesome(); } (); const ResultT2 result2 = [foo2] { const Bar bar = barFromFoo2(foo2); return bar.awesome(); } (); return result1.howAwesome(result2); } It's my understanding that compilers are already surprisingly good at optimizing out local lambdas. I recall a demo from Herb Sutter where std::for_each(someLambda) was faster than a classic for(int i;i<100000;i++) loop with a trivial body because the for_each internally unrolled the loop and the lamdba body was therefore inlined as unrolled.

archagon 12y ago

In the languages that I'm using (JS, and now Swift), lambdas are only marginally more difficult to write than a pair of brackets. In fact, in Swift, you actually can't write a pair of brackets to designate scope, but you can put stuff in a lambda if you wish.

a-nikolaev 12y ago

I don't see how you want to use first-class functions, lambdas, in this situation. Maybe, you meant to say nested functions? Lambda function is a piece of code that is usually sent somewhere else, a callback basically. If you define a lambda function instead of a block of code and call it right there, it would create a considerable overhead: because if it is a closure, it should save its current scope somewhere. And it is really unnecesary, if you call this function right at the same place where you define it.

corysama 12y ago
sjolsen did a good job of illustrating what I meant https://news.ycombinator.com/item?id=8375341 https://news.ycombinator.com/item?id=8375341 Improvements on his version would be to make everything const and the lambda inputs explicit. AwesomenessT largerFunction(Foo1 foo1, Foo2 foo2) { const ResultT1 result1 = [foo1] { const Bar bar = barFromFoo1(foo1); const Baz baz = bar.makeBaz(); return baz.awesome(); } (); const ResultT2 result2 = [foo2] { const Bar bar = barFromFoo2(foo2); return bar.awesome(); } (); return result1.howAwesome(result2); } It's my understanding that compilers are already surprisingly good at optimizing out local lambdas. I recall a demo from Herb Sutter where std::for_each(someLambda) was faster than a classic for(int i;i<100000;i++) loop with a trivial body because the for_each internally unrolled the loop and the lamdba body was therefore inlined as unrolled.