4 ms·

I remember this exact argument when Ruby first became popular and the PickAxe book was telling people how to write .each and .map instead of loops. Come to thi

I remember this exact argument when Ruby first became popular and the PickAxe book was telling people how to write .each and .map instead of loops. Come to think of it, I remember this exact argument when SmallTalk was introduced. My elders probably remember having this argument when discussing LISP vs. Fortran. I'm not sure what I can tell you that hasn't already been said in the sixty years that programmers have been having the whole "It's easier to understand when you're directly manipulating the metal" argument.

ajross 14y ago
If you're sick of having the argument, then why did you troll it? :) I mean, I'm perfectly willing to be your imperative curmudgeon strawman if you really want. But honestly, if you're going to blog about the spectrum of "explicit" programming, you're sort of morally bound to accept arguments on sides of the spectrum you'd rather not talk about.
- raganwald 14y ago
  1. I'm not sick of it, I just can't tell you anything you haven't already heard and rejected. 2. I'm not trolling, just pointing out that this has been going on for a while, which implies that there are reasonable people on both sides of the discussion. 3. I never argued that explicit is bad or that jargon is good, I just explained that sometimes, jargon accomplishes a purpose. 4. I have written for loops and liked them. So, 5. Don't assume enmity where there is none.
  - avenger123 14y ago
    Thank you for this. I didn't see your article as trolling. You articulate a very valid point - The degree of perceived "cleverness" in code is dependent on the reader's level of familiarity of the language's basic and advanced concepts. Your example really highlights this.
- btilly 14y ago
  If you want that argument, let's start with the fact that I can make Raganwald's version work, unchanged, with the data structure changed to be the values of a hash, the keys of a hash, a tree data structure, and a streamed data set that you do not entirely possess at any single time. Your version requires it to be an array, and nothing else. You may retort that it almost always is an array. My experience in languages that support the abstraction disagrees with you. Secondly with your version I find that I require significantly more typing, and get it wrong significantly more wrong simply because I had a trivial typo. Thirdly with your version on a double loop I find myself periodically messing up because I slip in the wrong counter variable in the wrong place. Stupid error, but the code compiles and does the wrong thing, then I have to track it down. With the functional version I pretty much never make that mistake on that use case. And finally my experience, with my background, says that it is easier to fix mistakes in the functional version than the explicit one. The result is that separating the concept of iteration from the implementation is a good thing. Even C++ realized this fact (badly) with iterators.
  - signa11 14y ago
    > Even C++ realized this fact (badly) with iterators. would you mind clarifying that a bit (or a bunch) ? afaik, STL cleanly separates the notion of structures and algorithms that operate on those structures via iterators. thanks !
    - saucetenuto 14y ago
      I'm not the grandparent poster, but one classic problem with STL iterators is that they always have to come in pairs. If you think about it, most STL algorithms don't really work on iterators, they work on ranges that happen to be defined by pairs of iterators. That makes it hard to compose operations, makes it hard to work with infinite streams, and makes it possible to screw up and write something like std::transform(v1.begin(), v2.end()). Have a look at Alexandrescu's work on ranges in D for a more modern exploration of the same concept.
      - deleted 14y ago
        [deleted]
cousin_it 14y ago
The code suggested by ajross seems more readable not just because it's closer to the metal, but also because reading it doesn't require memorizing many ad-hoc names like "splat" and "pluck", you just apply a few logical rules that you learned once. But there's no reason why code written with advanced abstractions couldn't be "locally readable" in the same way...

ajross 14y ago

If you're sick of having the argument, then why did you troll it? :) I mean, I'm perfectly willing to be your imperative curmudgeon strawman if you really want. But honestly, if you're going to blog about the spectrum of "explicit" programming, you're sort of morally bound to accept arguments on sides of the spectrum you'd rather not talk about.

raganwald 14y ago
1. I'm not sick of it, I just can't tell you anything you haven't already heard and rejected. 2. I'm not trolling, just pointing out that this has been going on for a while, which implies that there are reasonable people on both sides of the discussion. 3. I never argued that explicit is bad or that jargon is good, I just explained that sometimes, jargon accomplishes a purpose. 4. I have written for loops and liked them. So, 5. Don't assume enmity where there is none.
- avenger123 14y ago
  Thank you for this. I didn't see your article as trolling. You articulate a very valid point - The degree of perceived "cleverness" in code is dependent on the reader's level of familiarity of the language's basic and advanced concepts. Your example really highlights this.
btilly 14y ago
If you want that argument, let's start with the fact that I can make Raganwald's version work, unchanged, with the data structure changed to be the values of a hash, the keys of a hash, a tree data structure, and a streamed data set that you do not entirely possess at any single time. Your version requires it to be an array, and nothing else. You may retort that it almost always is an array. My experience in languages that support the abstraction disagrees with you. Secondly with your version I find that I require significantly more typing, and get it wrong significantly more wrong simply because I had a trivial typo. Thirdly with your version on a double loop I find myself periodically messing up because I slip in the wrong counter variable in the wrong place. Stupid error, but the code compiles and does the wrong thing, then I have to track it down. With the functional version I pretty much never make that mistake on that use case. And finally my experience, with my background, says that it is easier to fix mistakes in the functional version than the explicit one. The result is that separating the concept of iteration from the implementation is a good thing. Even C++ realized this fact (badly) with iterators.
- signa11 14y ago
  > Even C++ realized this fact (badly) with iterators. would you mind clarifying that a bit (or a bunch) ? afaik, STL cleanly separates the notion of structures and algorithms that operate on those structures via iterators. thanks !
  - saucetenuto 14y ago
    I'm not the grandparent poster, but one classic problem with STL iterators is that they always have to come in pairs. If you think about it, most STL algorithms don't really work on iterators, they work on ranges that happen to be defined by pairs of iterators. That makes it hard to compose operations, makes it hard to work with infinite streams, and makes it possible to screw up and write something like std::transform(v1.begin(), v2.end()). Have a look at Alexandrescu's work on ranges in D for a more modern exploration of the same concept.
    - deleted 14y ago
      [deleted]

cousin_it 14y ago

The code suggested by ajross seems more readable not just because it's closer to the metal, but also because reading it doesn't require memorizing many ad-hoc names like "splat" and "pluck", you just apply a few logical rules that you learned once. But there's no reason why code written with advanced abstractions couldn't be "locally readable" in the same way...