Comment by jwmerrill | Hacker News Reader

Comment by jwmerrill | Hacker News Reader

Parent Full thread

I sometimes wish there was a way to demand the same level of proof for claims of readability and productivity that we demand for claims about performance.

Measuring before optimizing is of course a good idea, but it's also time consuming. There's a lot of latitude to make different reasonable choices about how you write code down in the first place before you get to the measuring staging.

Should we criticize someone who reaches for a for loop because they know it doesn't allocate without proving that that matters more than someone who reaches for a map because they think it's more readable and productive without any great way of proving that that's true?

>map because they think it's more readable and productive without any great way of proving that that's true?

I mean, doing

    sendUserIds(users.map(u => u.id))

is very obviously more readable than what you're forced to do in languages like Go

    ids := make([]int, len(users))
    for i, user := range users {
        ids[i] = user.Id
    }
    sendUserIds(ids)

The difference only grows once you start needing to do more operations, grouping, putting stuff into map by a certain key, etc. Many languages also have lazy sequences for such operations (e.g. https://kotlinlang.org/docs/reference/sequences.html, though they aren't always faster, it depends)

The code in the comment above is however not an example of this, and is actually less readable in my opinion. It seems more like an author wishing to be using a different language instead of accepting what they have in front of them.

Reply on news.ycombinator.com