Hacker News Reader

Comment by montrose | Hacker News Reader

I find it's a valuable heuristic simply to try to make your code short (in tokens, of course, not characters).

That rule means that it's worth defining a new operator if you use it enough to save more than the amount of code you need to define it.

There are exceptions, of course. I have a higher standard for macros. But overall the principle of optimizing for brevity has held up through decades of programming of various types.

View on HN

> I find it's a valuable heuristic simply to try to make your code short (in tokens, of course, not characters).

Make it short in characters as well.

Fitting more code on the screen makes it possible to see common subsequences and methods of abstraction not otherwise possible. It has dramatically improved my programming, and I recommend anyone who can to spend 6-8 months practicing it.

For more on the subject:

- https://news.ycombinator.com/item?id=13571159

- https://news.ycombinator.com/item?id=10872782

- http://archive.vector.org.uk/art10500700

I disagree. I recently read through Real World Haskell (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.

I 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.

But 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.

Sure, but IMHO it tends to fail even on the "more readable" front.

Yes, for converting three lines to two, but often not when converting thirty lines to twenty.

Reply on news.ycombinator.com