Hacker News Reader

Comment by Buttons840 | Hacker News Reader

I'm going to make a controversial claim for the sake of argument.

We can and will debate what programs are "simpler" all day, it's all subjective... except for one metric: line count. Line count is objective.

Take pause before rejecting any change that uses fewer lines of code.

It takes an awfully good abstraction to beat simply having less code.

View on HN

It seems like it should be objective, but it isn't. Because you get people writing ridiculous "clever" one-liners that are difficult to parse and understand. That clever one-liner could be re-written to do the exact same thing and be much more clear and readable, but it would take, say, 8 lines instead of 1.

Then there's the subjectiveness of what you actually consider a "line".

Fair. "Less code" is probably a better metric, but still has the same problem you describe.

Still, some argue that an 8 line for-loop is better than a 1 line map or something, but a map is more constrained in what it can do than a free style for-loop.

And 8 vs 1 lines in some corner of the program is less important than whether or not we make it a coding standard to write and use AbstractBeanThingyamabobs for all our stuff, etc.

and then there's "syntactic sugar"

Kolmogorov complexity is close to what you're getting at, but is about total string length of the program which is more useful than line count when line count can be gamed. That is, a shorter program is "simpler" than a longer program. In quotes because it's not necessarily true (see code golfing, the language itself may become very complex to permit such a short program and the requisite knowledge and competency then increases the total complexity to achieve, or even understand, the simpler result). A similar technique that doesn't discount meaningful variable names might use syntactic token count. That way:

  printf("Hello, World!\n");

and:

  Put("Hello, World!\n");

Can be treated as the same complexity (the difference is 3 characters, and they are otherwise equivalent).

There are also analysis methods (names escaping me, and Google fu is weak today) that look at loops, procedure calls, dependency graphs, and other things to attempt to discern (should be treated as guidelines and not rules) the complexity of a program using objective metrics.

https://en.wikipedia.org/wiki/Kolmogorov_complexity

> There are also analysis methods (names escaping me, and Google fu is weak today) that look at loops, procedure calls, dependency graphs, and other things to attempt to discern (should be treated as guidelines and not rules) the complexity of a program using objective metrics.

Cyclomatic complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity might be what you're thinking about.

That was it, thank you.

>the language itself may become very complex to permit such a short program

Hit the nail on the head. We can't fight thermodynamics, we can only cheat by drawing lines and pumping entropy one way. "Simplicity" is obtained by hiding complexity away. Modern container ships are reliably run by 13 people because of a huge system of builders and maintainers for everything from diesel engines to navigation systems.

Familiarity is a rug we get to sweep the complexity under.

If people know a language, like regexes (or APL as an extreme case), they can hide a lot of complexity.

Reply on news.ycombinator.com