On Mon, Oct 22, 2018 at 10:41 PM Eric S. Raymond <e...@thyrsus.com> wrote:
> Axel Wagner <axel.wagner...@googlemail.com>: > > But personally I don't see the point of introducing a custom iterator > concept > > just to *occasionally* save one or two lines of code. > > Don't despise saving lines of code. There's a well-known law the name of > which I've forgotten that defect rates per KLOC are rougly constant across > languages. Accordingly, what you're really doing when you enable your > language > to do more in fewer LOC is lowering your defect load. > > Thart's not really how I think of it, though. I think in terms of reducing > eyeball friction. Always a virtue when you're programming at scale. > > These might be the same issue, actually. > The key term was "occasionally". I don't know how often "iterators that don't need any error handling or cleanup" comes up, but I'd imagine it to be pretty rare. In Python, for example, this might be a bit different, because the iterator can just throw. And if you actually don't need error handling or cleanup, using a channel seems fine (and on par with any generic iteration construct in terms of LOC). If saving LOC is the goal (TBH I contest that all LOC are created equal in this regard) there are much lower hanging fruit. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be > your own. > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
