5 ms·

The problem with this article is that is doing something extremely simple, and calling that an abstraction. The power of Python or Ruby is not demonstrated doi

The problem with this article is that is doing something extremely simple, and calling that an abstraction. The power of Python or Ruby is not demonstrated doing a for loop, is with something like this: print sum(int(n) for n in open('/a/file/with/numbers')) We don't need to care about a lot of stuff that we would in C/C++ (memory management, iterate through a file, the format of stuff, terminating the loop properly) Are C/C++ interesting languages? Of course, sometimes you need that extra level of control about what's going on. But I don't agree that the cost of abstraction is higher in Python/Ruby. You can create code that does A LOT in a few lines, that most of the times will have a good enough speed. In C/C++ you need a lot of work to create a good abstraction, that's not guaranteed to perform well.

vinkelhake 12y ago
It's not quite that bad. To sum the numbers in a file you've got a line to open the file and another to call std::accumulate with istream iterators. Memory management? Doesn't come up. Terminating the loop? What loop?
ajtulloch 12y ago
FWIW, with folly::gen [1], this is just: using namespace folly::gen; byLine('/a/file/with/numbers') | eachTo<int> | sum; https://github.com/facebook/folly/tree/master/folly/gen https://github.com/facebook/folly/tree/master/folly/gen
- seri 12y ago
  Thank you for this. Got me really interested in folly now.
- nly 12y ago
  It's only 2 lines even restricting yourself to the standard library #include <fstream> #include <iterator> #include <numeric> using namespace std; int main() { ifstream nf ("numbers.txt"); return accumulate (istream_iterator<int>(nf), istream_iterator<int>(), 0); }
jeffdavis 12y ago
I think the post would be more clear if the author said "indirection" or "path length" (loosely: the number of primitive logical steps to complete an operation). The point is that, with many interpreted language compilers, you doubly lose out: the primitive logical steps (in the author's example, function calls) are slower, and they aren't optimized away like they are in C. I think that's a valid point, because it limits code reuse. As you build up vast libraries and frameworks, the trivial indirections build up and it slows everything to a crawl.
frostmatthew 12y ago
> But I don't agree that the cost of abstraction is higher in Python/Ruby. You can create code that does A LOT in a few lines, that most of the times will have a good enough speed. I think you missed the author's point - you may want to re-read the blog's first two paragraphs.
haberman 12y ago
> The problem with this article is that is doing something extremely simple, and calling that an abstraction. Simple examples make for good blog articles. Real abstractions follow the same pattern as simple ones. > The power of Python or Ruby is not demonstrated doing a for loop, is with something like this: print sum(int(n) for n in open('/a/file/with/numbers')) In this case, your abstraction is sum(). Internally, sum() will use something like a for loop in its implementation. sum() is fast because it's implemented in C, not Python.

vinkelhake 12y ago

It's not quite that bad. To sum the numbers in a file you've got a line to open the file and another to call std::accumulate with istream iterators. Memory management? Doesn't come up. Terminating the loop? What loop?

ajtulloch 12y ago

FWIW, with folly::gen [1], this is just: using namespace folly::gen; byLine('/a/file/with/numbers') | eachTo<int> | sum; https://github.com/facebook/folly/tree/master/folly/gen https://github.com/facebook/folly/tree/master/folly/gen

seri 12y ago
Thank you for this. Got me really interested in folly now.
nly 12y ago
It's only 2 lines even restricting yourself to the standard library #include <fstream> #include <iterator> #include <numeric> using namespace std; int main() { ifstream nf ("numbers.txt"); return accumulate (istream_iterator<int>(nf), istream_iterator<int>(), 0); }

jeffdavis 12y ago

I think the post would be more clear if the author said "indirection" or "path length" (loosely: the number of primitive logical steps to complete an operation). The point is that, with many interpreted language compilers, you doubly lose out: the primitive logical steps (in the author's example, function calls) are slower, and they aren't optimized away like they are in C. I think that's a valid point, because it limits code reuse. As you build up vast libraries and frameworks, the trivial indirections build up and it slows everything to a crawl.

frostmatthew 12y ago

> But I don't agree that the cost of abstraction is higher in Python/Ruby. You can create code that does A LOT in a few lines, that most of the times will have a good enough speed. I think you missed the author's point - you may want to re-read the blog's first two paragraphs.

haberman 12y ago

> The problem with this article is that is doing something extremely simple, and calling that an abstraction. Simple examples make for good blog articles. Real abstractions follow the same pattern as simple ones. > The power of Python or Ruby is not demonstrated doing a for loop, is with something like this: print sum(int(n) for n in open('/a/file/with/numbers')) In this case, your abstraction is sum(). Internally, sum() will use something like a for loop in its implementation. sum() is fast because it's implemented in C, not Python.