4 ms·

Readability improved from squareVec1 to squareVec4, then went downhill. Hiding loops behind new names doesn't make programming better.

rootlocus 13y ago
It does if you're familiar with the common high-order functions used in functional programming.
- forrestthewoods 13y ago
  If you are familiar with both C++ and common high-order functions used in functional programming I still think that squareVec4 is, by leaps and bounds, the most readable. squareVec4 is simple, concise, and leaves little to no room for ambiguity. squareVec6 is a monstrosity that requires reading more text that contains more complicated ascii and involves more concepts. And for the author to then claim that making use of "cool stuff" in <algorithm> is more maintainable code? That's just crazy talk man!
  - mercurial 13y ago
    Isn't this an artifact of C++ rather than a general truth, though? If you could just invoke something like: return v.fold([], def (acc, i) { acc.push(i*i) }); Or better: return v.map(def(i) { i * i }) Something like 'map' in this case is much more appropriate, since it's operation on a collection which returns a new collection with a given operation applied on each element.
deleted 13y ago
[deleted]
nly 13y ago
At Going Native last year Sean Parent, from Adobe, gave a superb talk called 'C++ Seasoning' where his number one pro-tip for C++ was: no raw loops. He made a good case that anywhere you have a non-trivial loop in C++, you're almost always going to be better off folding the problem in to a composition of algorithms. The code got more readable, more performant, and redundant code can often be removed. Please take an hour to watch it here in glorious high quality: http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoni...
- agumonkey 13y ago
  And if someone has nothing better to do, may I suggest to watch anything by Sean Parent. Some old adobe talks might be in low-res, but they were still very interesting, on the abstraction side of things.
  - nly 13y ago
    Where can we find these old talks?
    - agumonkey 13y ago
      I think most of them are on youtube. Ill get back to you tomorrow.
    - agumonkey 13y ago
      Here's one : A Possible Future of Software Development : www.youtube.com/watch?v=4moyKUHApq4‎
notacoward 13y ago
My thoughts exactly. It's simply not true that "everybody knows without thinking" what the std::accumulate version will do. It's specific not only to a particular pattern but to the expression of that pattern in a particular language. People new to C++ won't be able to parse "[](vector<int> acc" right away, and it's key to understanding the whole. By contrast, the range-based for loop is obvious even to a C++ novice and easily guessable even by those who don't know C++. If you want something that's both concise and readable, try the Python list-comprehension version. That is an elegant solution. The C++ accumulate/transform solutions are the very opposite of elegant. In a code review, I would flag them as obfuscatory.

rootlocus 13y ago

It does if you're familiar with the common high-order functions used in functional programming.

forrestthewoods 13y ago
If you are familiar with both C++ and common high-order functions used in functional programming I still think that squareVec4 is, by leaps and bounds, the most readable. squareVec4 is simple, concise, and leaves little to no room for ambiguity. squareVec6 is a monstrosity that requires reading more text that contains more complicated ascii and involves more concepts. And for the author to then claim that making use of "cool stuff" in <algorithm> is more maintainable code? That's just crazy talk man!
- mercurial 13y ago
  Isn't this an artifact of C++ rather than a general truth, though? If you could just invoke something like: return v.fold([], def (acc, i) { acc.push(i*i) }); Or better: return v.map(def(i) { i * i }) Something like 'map' in this case is much more appropriate, since it's operation on a collection which returns a new collection with a given operation applied on each element.

deleted 13y ago

[deleted]

nly 13y ago

At Going Native last year Sean Parent, from Adobe, gave a superb talk called 'C++ Seasoning' where his number one pro-tip for C++ was: no raw loops. He made a good case that anywhere you have a non-trivial loop in C++, you're almost always going to be better off folding the problem in to a composition of algorithms. The code got more readable, more performant, and redundant code can often be removed. Please take an hour to watch it here in glorious high quality: http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoni...

agumonkey 13y ago
And if someone has nothing better to do, may I suggest to watch anything by Sean Parent. Some old adobe talks might be in low-res, but they were still very interesting, on the abstraction side of things.
- nly 13y ago
  Where can we find these old talks?
  - agumonkey 13y ago
    I think most of them are on youtube. Ill get back to you tomorrow.
  - agumonkey 13y ago
    Here's one : A Possible Future of Software Development : www.youtube.com/watch?v=4moyKUHApq4‎

notacoward 13y ago

My thoughts exactly. It's simply not true that "everybody knows without thinking" what the std::accumulate version will do. It's specific not only to a particular pattern but to the expression of that pattern in a particular language. People new to C++ won't be able to parse "[](vector<int> acc" right away, and it's key to understanding the whole. By contrast, the range-based for loop is obvious even to a C++ novice and easily guessable even by those who don't know C++. If you want something that's both concise and readable, try the Python list-comprehension version. That is an elegant solution. The C++ accumulate/transform solutions are the very opposite of elegant. In a code review, I would flag them as obfuscatory.