2 ms·
> Training yourself to read terse code is O(1) understanding code is O(N) where N is the number of lines of code. Even granting that, this: > f[iII]{m:0;$[k:-
by otikik 8y ago
> Training yourself to read terse code is O(1) understanding code is O(N) where N is the number of lines of code.
Even granting that, this:
> f[iII]{m:0;$[k:-x;W(x){x-:1;j:y;N(k)y[i]:y[+i];y[k]:j;j:f[k;y;z];$[m<j;m:j;]};{N(#y)z[i]:y[i];W(j:z){m+:1;N(j){k:z[i];z[i]:z[j];z[j]:k;j-:1}}}];m}
Is not a single line of "terse code". It's a bunch of lines of code with the newlines and spaces removed.
> Try writing code as simple and succinct as possible.
I already strive to do that (I don't always succeed). But the operating word here is as possible. Not "above anything else".
- quadcore 8y agoI didn't wanted to say #node in the ast. The presentation or the variable names doesn't matter in terms of less code I believe. Whitney's code is obfuscated which is distinct from less code imo. To some extent. Succinct code is kind of great. Just to confirm, I'm saying that after the user, the most important thing is less code. In more practical terms, I'd say try "above anything else" to see where the actual limit is. From my experience, it's way further from where traditional programming is.