4 ms·

A new .map line has limited scope of access, and thus highly restricted possibilities. The same line in a for-loop can access anything, including things from o

by setr 5y ago

A new .map line has limited scope of access, and thus highly restricted possibilities. The same line in a for-loop can access anything, including things from other lines. The primary benefit of these kinds of functional chains is that each step is highly constrained in their capabilities, mainly by their function name and access scope, so you can better verify that it really does do what it says on the tin. A for loop’s content has to be ultimately read thoroughly, because anything goes. Including modifying lists unrelated to the list under question.

watwut 5y ago
The price for that limited scope is that it is much harder to figure out what is actual parameter of lambda that goes into map function. If is also not even limited all that much. In lambda, everything from surrounding scope is visible too. My personal issue with these is that it is all harder to reason about, harder to read, harder to debug. And each time there is real issue, I have to unpack these into procedural, fix and then encrypt again. I dont see less bugs in code since we started using these. Bugs did not dropped.
- setr 5y ago
  > The price for that limited scope is that it is much harder to figure out what is actual parameter of lambda that goes into map function I’m not sure why that soul would be the case... it’s whatever came out of the previous action? You’re doing list operations...always. Nested list operations get convoluted fast, so I generally avoid them (break them up into separate iterations) but otherwise. The only thing I can remember complicating things is issues with type conversion, but the IDE usually tells you what’s up. The loss of print debugging and useful debugger support is a pain but usually resolved by commenting out half the manipulations and printing immediately. Otherwise IME it’s a lot simpler to see a series of independent operations on the total list, then it is to follow a for loop interacting with one element at a time. But personally I switch between the two styles freely, depending on which one is “cleaner” so I likely naturally avoid the more convoluted/difficult cases.

by setr 5y ago

watwut 5y ago

The price for that limited scope is that it is much harder to figure out what is actual parameter of lambda that goes into map function. If is also not even limited all that much. In lambda, everything from surrounding scope is visible too. My personal issue with these is that it is all harder to reason about, harder to read, harder to debug. And each time there is real issue, I have to unpack these into procedural, fix and then encrypt again. I dont see less bugs in code since we started using these. Bugs did not dropped.

setr 5y ago
> The price for that limited scope is that it is much harder to figure out what is actual parameter of lambda that goes into map function I’m not sure why that soul would be the case... it’s whatever came out of the previous action? You’re doing list operations...always. Nested list operations get convoluted fast, so I generally avoid them (break them up into separate iterations) but otherwise. The only thing I can remember complicating things is issues with type conversion, but the IDE usually tells you what’s up. The loss of print debugging and useful debugger support is a pain but usually resolved by commenting out half the manipulations and printing immediately. Otherwise IME it’s a lot simpler to see a series of independent operations on the total list, then it is to follow a for loop interacting with one element at a time. But personally I switch between the two styles freely, depending on which one is “cleaner” so I likely naturally avoid the more convoluted/difficult cases.