3 ms·
I disagree. I recently read through Real World Haskell (http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/ though it seems down right
by tom_mellior 9y ago
I disagree. I recently read through Real World Haskell (http://book.realworldhaskell.org/read/ http://book.realworldhaskell.org/read/ though it seems down right now?) as a refresher, and it devotes a lot of time to examples of the form "here is a three-line function, but aargh, it is too long, let's turn it into a two-line function by peppering it with <$> and <*> and <@!^!@> operators!". The savings in code size is small, but in every single case I found their "shorter", "simpler" program harder to read.
- tome 9y agoI suspect that's a pedagogical device to motivate introducing a style that can make code shorter and more readable, not a prescription to always convert three lines to two by using sigils.
- tom_mellior 9y agoSure, but IMHO it tends to fail even on the "more readable" front.
- tome 9y agoYes, for converting three lines to two, but often not when converting thirty lines to twenty.
- mannykannot 9y agoBut as a pedagogical device, it would seem to be teaching students to focus on the wrong thing (and it also fails Montrose's token-count definition of shorter.) (Caveat: the site is still down.) More generally, I think there is an inversion of causality here: well-written code is often shorter than slapdash code with the same goal because the author thought about the problem as a whole, got straight to the point, and avoided adding complexity. I think that is clear in the Sudoku-solver example of my previous post.