3 ms·

> A 1000 line function broken down into 100 different 10 line functions which are then each called in turn (and need lots of parameters to pass around the inevi

> A 1000 line function broken down into 100 different 10 line functions which are then each called in turn (and need lots of parameters to pass around the inevitable shared state) is actually often less readable than just a 1000 line function. Aside from the 1000 line function (sheesh), this is a failure of the IDE, not of the practice. We have computers that can inline these functions so you could see the code in a big 1000 line thunk if you would like, but only a LISP IDE gives you inlining afaik. > “Good code is simple” doesn’t actually say anything. That's a bold claim and I will assert it is wholly incorrect. Good Code is simple and simple code is VERBOSE > whether that translates to “simple” code depends on the programmers. That is incorrect. It largely depends on the language abstractions. When the abstractions are familiar, it goes from incomprehensible (literally) to familiar. Code cannot seem simple if you do not have the familiarity with the abstractions used. > Should we strive to satisfy the Shakespeare for Dummies demographic Yes. > Programmers seem to believe in a realm of beautiful, readable, easy-to-maintain code that they haven’t seen or worked with yet Lots of programmers believe it because they have seen it. I have. It was embedded in hard-to-maintain code, but it was there.

tremon 4y ago
Good Code is simple and simple code is VERBOSE It doesn't mean anything because both good and simple are subject to on-the-spot redefinition. At what skill level does code become "simple"? Does all code have to be ELI5 to be good? When a Node developer looks at CUDA implementation of k-means regression analysis and finds it "difficult", does that mean the code isn't good? When the abstractions are familiar So you're saying it does depend on the programmer, because the programmer should be familiar with the abstractions used?
- b3morales 4y ago
  In case you have not seen it, there is an excellent talk by Rich Hickey on what "simple" is and how it differs from "familiar" or "easy": https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy He proposes that "simple" is more objective than subjective.
- Supermancho 4y ago
  > Does all code have to be ELI5 to be good? Short answer: No. "good" is a different bar (whatever you mean by it). It's not possible for every function to be simple, for more than 1 reason (for sure, some calculations are inherently complex, some relationships are complex, etc). However, the vast majority of code can be. > So you're saying it does depend on the programmer, because the programmer should be familiar with the abstractions used? Correct. It is expected the viewer is familiar with the language, not additional abstraction on top of that. You have to assume there is a cost to those new abstractions that elevate it beyond simple.
rendaw 4y ago
> 1000 line function (sheesh), this is a failure of the IDE, not of the practice This can be argued the other way too. Decent IDEs have code folding and other features so you can look at a long function at a higher level without needing to abuse language features for subjective purposes.
- Supermancho 4y ago
  > Decent IDEs have code folding Function inlining is folded, moreso... foo() { return bar(); // <-- bar can be clicked on and expanded in place } becomes: foo() { return {return "boo";} } ------ bar() {return "boo";}

tremon 4y ago

Good Code is simple and simple code is VERBOSE It doesn't mean anything because both good and simple are subject to on-the-spot redefinition. At what skill level does code become "simple"? Does all code have to be ELI5 to be good? When a Node developer looks at CUDA implementation of k-means regression analysis and finds it "difficult", does that mean the code isn't good? When the abstractions are familiar So you're saying it does depend on the programmer, because the programmer should be familiar with the abstractions used?

b3morales 4y ago
In case you have not seen it, there is an excellent talk by Rich Hickey on what "simple" is and how it differs from "familiar" or "easy": https://www.infoq.com/presentations/Simple-Made-Easy https://www.infoq.com/presentations/Simple-Made-Easy He proposes that "simple" is more objective than subjective.
Supermancho 4y ago
> Does all code have to be ELI5 to be good? Short answer: No. "good" is a different bar (whatever you mean by it). It's not possible for every function to be simple, for more than 1 reason (for sure, some calculations are inherently complex, some relationships are complex, etc). However, the vast majority of code can be. > So you're saying it does depend on the programmer, because the programmer should be familiar with the abstractions used? Correct. It is expected the viewer is familiar with the language, not additional abstraction on top of that. You have to assume there is a cost to those new abstractions that elevate it beyond simple.

rendaw 4y ago

> 1000 line function (sheesh), this is a failure of the IDE, not of the practice This can be argued the other way too. Decent IDEs have code folding and other features so you can look at a long function at a higher level without needing to abuse language features for subjective purposes.

Supermancho 4y ago
> Decent IDEs have code folding Function inlining is folded, moreso... foo() { return bar(); // <-- bar can be clicked on and expanded in place } becomes: foo() { return {return "boo";} } ------ bar() {return "boo";}