3 ms·

It's interesting that there seems to be a lack of appreciation for having a single way of doing things. I think there are very few applications for which the pe

It's interesting that there seems to be a lack of appreciation for having a single way of doing things. I think there are very few applications for which the performance gains of additional flexibility are significant, whereas the productivity and test simplicity can be more significant for non trivial apps.

zemo 13y ago
on the internet, it seems that there is a lack of appreciation for having a single way of doing things, but in the real world... it doesn't really same to be the case. The appreciation is there, it's just not as vocal, because it's... well, not as interesting to talk about, to be honest. How much of the world's software is written in C++? How many HN articles are about C++? HN is representative of HN, not programming in general.
- sanderjd 13y ago
  It is ironic that you mention having a single way of doing things and C++ in the same breath. The reason there are multiple ways of doing things in nearly all languages is that people have found that not all common use cases fall nicely into one construct. A language can either be plauged by everyone reimplementing some common constructs or it can add some of those constructs as "another way of doing things". I don't really get this thread at all actually. Most of the article was about how Go actually has three looping constructs, so the entire premise seems ...off.
pcwalton 13y ago
It's not about performance gains; it's about making it harder to mess up. C-style for loops are easier to get wrong. (Try iterating backwards from 10 to 0 with an unsigned int loop index in C; most programmers get it wrong the first time due to underflow.) They are also more vulnerable to race conditions. (See "race on loop counter" at [1]; with first-class iterators you can create a separate binding for each iteration of the loop, eliminating this problem.) [1]: http://golang.org/doc/articles/race_detector.html http://golang.org/doc/articles/race_detector.html
comex 13y ago
I don't mind if there's a single way of doing things (although I prefer when there's an escape hatch). But plenty of languages have a single way of, say, iterating over the lines of a file that doesn't involve writing the same expression twice and feeling straitjacketed.

zemo 13y ago

on the internet, it seems that there is a lack of appreciation for having a single way of doing things, but in the real world... it doesn't really same to be the case. The appreciation is there, it's just not as vocal, because it's... well, not as interesting to talk about, to be honest. How much of the world's software is written in C++? How many HN articles are about C++? HN is representative of HN, not programming in general.

sanderjd 13y ago
It is ironic that you mention having a single way of doing things and C++ in the same breath. The reason there are multiple ways of doing things in nearly all languages is that people have found that not all common use cases fall nicely into one construct. A language can either be plauged by everyone reimplementing some common constructs or it can add some of those constructs as "another way of doing things". I don't really get this thread at all actually. Most of the article was about how Go actually has three looping constructs, so the entire premise seems ...off.

pcwalton 13y ago

It's not about performance gains; it's about making it harder to mess up. C-style for loops are easier to get wrong. (Try iterating backwards from 10 to 0 with an unsigned int loop index in C; most programmers get it wrong the first time due to underflow.) They are also more vulnerable to race conditions. (See "race on loop counter" at [1]; with first-class iterators you can create a separate binding for each iteration of the loop, eliminating this problem.) [1]: http://golang.org/doc/articles/race_detector.html http://golang.org/doc/articles/race_detector.html

comex 13y ago

I don't mind if there's a single way of doing things (although I prefer when there's an escape hatch). But plenty of languages have a single way of, say, iterating over the lines of a file that doesn't involve writing the same expression twice and feeling straitjacketed.