Hacker News Reader

Comment by nnq | Hacker News Reader

- powerful features -> less code to do something -> less bugs because less code

- powerful features -> more general abstractions -> more code reuse -> less new code written -> less bugs

It's not that simple, but it's good to start with the core assumption that less code -> less bugs and what more powerful languages offer you is ability to solve problems with less code while at the same time keeping that more compact code readable.

Or maybe big software-focused companies like G don't see "# of LOC" as a liability and don't try to reduce it while at the same time as trying to do more? Is this the core difference between a large corporation and a small startup that tries to do more with less?

View on HN

> core assumption that less code -> less bugs

This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows.

> solve problems with less code while at the same time keeping that more compact code readable

Less code means less readable.

> This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows.

No, it's not. Your interpretation of it is wrong, though. No code means no bugs, this is true. Now, write a new feature, unless the code is flawless, the code-base will certainly have more bugs than before, this is true. Now, write a linked-list, unless the code is flawless, the code-base will have more bugs than if using the one in the language std-lib. About language features, writing 5 implementations of a linked-list for each type instead of a generic one that it's type checked will certainly contain more bugs as it's more error prone to write the same things 5 times and keep it updated.

> Less code means less readable.

This is ridiculous. Otherwise, we'd all be using assembly. About Go, the lack of generics and simple error propagation is detrimental to being readable. Every function can fail, you don't say!. You're manually propagating the error instead of handling it here, you don't say!. That's what I think every time I go through some Go code-base.

The obvious counter-example to the claim that less code means fewer bugs is kdb/q. It is an extremely powerful and terse language but you can write an astonishing density of bugs per line of code.

really? I thought ppl use APL-family languages bc they allow to express things in very little code so there's more chance of getting it right?...

I don't know about if it works by chance, but I've heard of someone working for two years to get two short lines of APL 'right'.

Reply on news.ycombinator.com