Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

    b = sum((j if j % 2 else 0) for (j, k) in results if k)
This definitely is borderline unreadable but that isn't necessarily because it does a lot of things. It is because it does a lot of things without order and with a lot of line noise. Compare it with

    sum [j | (j, True) <- results, odd j]
or

    filter snd >>> map fst >>> filter odd >>> sum
The bigger problem is that this carries a bool around. If it is only used for filtering filter it beforehand.

The Opportunity for correction is an interesting idea but the authors issue mostly come from a lack of referential transparency. In a pure language refactoring wouldn't be an issue so one could argue this is a symptom of too little abstraction, not too much.



If you'd name your variables all three would be perfectly readable I bet.


Technically the third has no variables...

Slightly less wise-ass, I couldn't come up with a use case for this code that'd give sane variable names. Third attempt:

    sum $ do 
        (element, True) <- results
        guard (odd element)
        return element
That's pretty far from imperative languages, though, which I kind of tried to avoid.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: