3 ms·

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 o

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.

geocar 8y ago
> 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=13571159 - https://news.ycombinator.com/item?id=10872782 https://news.ycombinator.com/item?id=10872782 - http://archive.vector.org.uk/art10500700 http://archive.vector.org.uk/art10500700
tom_mellior 8y 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 8y ago
  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.
  - tom_mellior 8y ago
    Sure, but IMHO it tends to fail even on the "more readable" front.
    - tome 8y ago
      Yes, for converting three lines to two, but often not when converting thirty lines to twenty.
  - mannykannot 8y ago
    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.

geocar 8y ago

> 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=13571159 - https://news.ycombinator.com/item?id=10872782 https://news.ycombinator.com/item?id=10872782 - http://archive.vector.org.uk/art10500700 http://archive.vector.org.uk/art10500700

tom_mellior 8y 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 8y ago
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.
- tom_mellior 8y ago
  Sure, but IMHO it tends to fail even on the "more readable" front.
  - tome 8y ago
    Yes, for converting three lines to two, but often not when converting thirty lines to twenty.
- mannykannot 8y ago
  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.