3 ms·

I've loved what little EWD reading I have done. The two points highlighted here I read as: 1. The program structure should reflect the problem structure as clo

I've loved what little EWD reading I have done. The two points highlighted here I read as: 1. The program structure should reflect the problem structure as closely as possible 2. Thinking of every possible case ("enumeratively") is much less powerful than abstract reasoning To me the second point is where the power of functional programming lies. You express ideas in relatively small units with no side effects that are easy to fully reason about. When you express things clearly it just feels right. Special casing is possible in most functional languages, but it usually feels like a kludge. Another excellent essay is EWD831, "Why numbering should start at zero", which was something I felt was intuitive once I got used to it, but couldn't articulate clearly. Reading his essay was soothing in the same way as scratching an itch. The essay is here: Why numbering should start at zero - Edsger W. Dijkstra http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...

omaranto 15y ago
I've never really agreed that numbering should start at zero (or at one), I think people use indices way too much and it gets in the way of clarity. I much prefer whole array or list operations with no fiddling with indices and off by one errors. I like Haskell's array API, for example. You can index by whatever is natural in each case and you can always get the whole list of valid indices for an array x by using "indices x". I think that's much nicer, and it's also what D is doing: instead of having a(n implicitly paired) starting and ending iterator to indicate a range of positions like the C++ library does, D's library uses a range object. Basically I'm saying you can represent a range of indices as a pair of indices, one pointing to the first valid position and the other pointing past the last valid one, but that's an implementation detail you don't need to expose, make a range abstraction and you'll be happier. I should also point out that mathematicians don't number at zero unless there is some advantage (the default is to start at one), but more importantly, the preferred style in mathematical arguments is to avoiding fiddling with indices as much as possible (since it's so easy to mess something up working at such a low level of abstraction).
- anonymoushn 15y ago
  If all of my tools had performant implementations of this abstraction, I would just use them. Unfortunately, much of the time this abstraction is provided, it is significantly slower than fiddling with indices.

omaranto 15y ago

I've never really agreed that numbering should start at zero (or at one), I think people use indices way too much and it gets in the way of clarity. I much prefer whole array or list operations with no fiddling with indices and off by one errors. I like Haskell's array API, for example. You can index by whatever is natural in each case and you can always get the whole list of valid indices for an array x by using "indices x". I think that's much nicer, and it's also what D is doing: instead of having a(n implicitly paired) starting and ending iterator to indicate a range of positions like the C++ library does, D's library uses a range object. Basically I'm saying you can represent a range of indices as a pair of indices, one pointing to the first valid position and the other pointing past the last valid one, but that's an implementation detail you don't need to expose, make a range abstraction and you'll be happier. I should also point out that mathematicians don't number at zero unless there is some advantage (the default is to start at one), but more importantly, the preferred style in mathematical arguments is to avoiding fiddling with indices as much as possible (since it's so easy to mess something up working at such a low level of abstraction).

anonymoushn 15y ago
If all of my tools had performant implementations of this abstraction, I would just use them. Unfortunately, much of the time this abstraction is provided, it is significantly slower than fiddling with indices.