3 ms·
2 questions: - Doesn't "loopless" actually mean "implicit looping"? (unless you assume infinite parallelization) - How do you debug a chain of "loopless" func
by stewbrew 7y ago
2 questions:
- Doesn't "loopless" actually mean "implicit looping"? (unless you assume infinite parallelization)
- How do you debug a chain of "loopless" functions when some corner case invalidates your assumptions?
- brudgers 7y ago1. The article describes different types of loops. If you buy that, then "looping" can mean several similar but distinct things. To me, the big distinction is whether or not we "know" how long the input is. Or more broadly, whether or not we can assert that the input terminates. If we can assert that that the input terminates then we can use "for i; while i < input.length" logic. If we can't assert input termination then we have to use "while input.next != EOF" logic and we might wind up calling "input.next" forever (but the system will probably crash first). 2. If the second form of looping -- calling input.next -- is like what you mean by "loopless" then debugging corner cases means something like looking at crash logs. But debugging any crash means looking at crash logs. Or sometimes it means just restarting the system. Which is what a lot of debugging looks like at the interesting scale of widely distributed significantly concurrent computation. 3. For problems of interesting size, assumptions about the data can be made based on statistical analysis of the input. Then corner cases become statistical anomalies that may or may not be worth engineering against. Systems crashing are as inevitable as off by one errors.