7 ms·
> 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 tim
by codegladiator 7y ago
> 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.
- nitely 7y ago> 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.