5 ms·

While the patterns themselves are interesting, the idea that all code must be rearranged in to smaller functions to be “refactored” seems a little juvenile.

CoolGuySteve 7y ago
It seems antithetical to the intent of "Goto considered harmful": > My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible. While Dijkstra later talks about using procedures to index into the call stack, needlessly adding to the depth of the callstack for single use functions seems excessive. With this logic, I actually think "The paragraphs with headers" is the way to go since as TFA states: "You know that the algorithm operates in steps, and you know where the steps are located in code." http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...
- makapuf 7y ago
  Functions can be inlined by the compiler if it thinks it's an issue. I think it's rather a question of readability : sometimes if a process involves a long series of step I like to be able to read them linearly rather than jumping back and forth to sub steps. I can read just the headers if they're cleanly organized by cleanly separated paragraphs (with braces if needed to indicate separate scopes and no leaking variables between paragraphs).
hinkley 7y ago
There’s an exercise for creative writing that my lit major friend told me about. You take everything you’ve written and cut it up into sentences. You just push the sentences around until something clicks and you figure out how to write your way out of the “stuckness”. Refactoring has rediscovered this trick, among others.
- 0x445442 7y ago
  Another similarity to creative writing is this; you're not done when there's nothing left to add, you're done when there's nothing left to remove.
rgoulter 7y ago
I can agree "code should be in small functions" by itself is a bad guideline. I think it's suggested due to other principles around making code easier to read / use. It'd be better to ask if the code is more complex than it needs to be. I liked the terms John Ousterhout uses. For some module of a program (e.g. a method, class, package, etc.), it has an interface and an implementation. The interface is "what you need to know to use the module", the implementation is "how it's done". Complexity comes from dependencies (e.g. more interfaces you need to know about), and from obscurity (e.g. things you need to know about, which aren't obvious from the interfaces given). In some cases, many small methods would be an increase in complexity overall. In some cases, one big method may be an increase in complexity.
- hinkley 7y ago
  In most cases one big method is an increase of complexity (and others will add to it over time). Large methods are usually a failure of imagination, like bad and rambling prose. Code is a set of instructions for the computer, and for the next person who has to maintain it (“ Programs are meant to be read by humans and only incidentally for computers to execute.”) Cooking instructions are split into steps. Assembly instructions are split into steps. LEGO instructions are split into steps. When drawing instructions aren’t split into steps the Internet turns them into a cultural phenomenon (Step 2: draw the rest of the fucking owl). Only programmers think they are immune to this ridicule, smash all the steps together, and then get salty when others complain, ignoring a series of luminaries who beg in every format of media available, and for decades, to do otherwise. Seriously, organize your code, separate the steps. You’re killing us.
  - mason55 7y ago
    No one disagrees that code needs to work in steps. The conversation is around how much and the answer is going to depend on what you're doing. Why have a function that prints a whole line? Isn't that just smashing together a bunch of small steps to print one character at a time?
taspeotis 7y ago
https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345
- DavidVoid 7y ago
  Since that blog seems to be down at the moment here's a cached version of the article/email. https://webcache.googleusercontent.com/search?q=cache:http://number-none.com/blow/john_carmack_on_inlined_code.html https://webcache.googleusercontent.com/search?q=cache:http:/...
ipnon 7y ago
The code that is easiest to revisit is decomposed into separate functions that are each trivial to understand. They are used to compose similarly trivial functions, and so on. Ideally every point of your program from input to output can be understood clearly and immediately.
- 0x445442 7y ago
  Makes the test a hell of a lot easier and more robust as well.
reuben_scratton 7y ago
Absolutely this. More functions => More complexity => Bad. Also: decreased legibility, less opportunity for compiler optimisation.

CoolGuySteve 7y ago

It seems antithetical to the intent of "Goto considered harmful": > My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible. While Dijkstra later talks about using procedures to index into the call stack, needlessly adding to the depth of the callstack for single use functions seems excessive. With this logic, I actually think "The paragraphs with headers" is the way to go since as TFA states: "You know that the algorithm operates in steps, and you know where the steps are located in code." http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

makapuf 7y ago
Functions can be inlined by the compiler if it thinks it's an issue. I think it's rather a question of readability : sometimes if a process involves a long series of step I like to be able to read them linearly rather than jumping back and forth to sub steps. I can read just the headers if they're cleanly organized by cleanly separated paragraphs (with braces if needed to indicate separate scopes and no leaking variables between paragraphs).

hinkley 7y ago

There’s an exercise for creative writing that my lit major friend told me about. You take everything you’ve written and cut it up into sentences. You just push the sentences around until something clicks and you figure out how to write your way out of the “stuckness”. Refactoring has rediscovered this trick, among others.

0x445442 7y ago
Another similarity to creative writing is this; you're not done when there's nothing left to add, you're done when there's nothing left to remove.

rgoulter 7y ago

I can agree "code should be in small functions" by itself is a bad guideline. I think it's suggested due to other principles around making code easier to read / use. It'd be better to ask if the code is more complex than it needs to be. I liked the terms John Ousterhout uses. For some module of a program (e.g. a method, class, package, etc.), it has an interface and an implementation. The interface is "what you need to know to use the module", the implementation is "how it's done". Complexity comes from dependencies (e.g. more interfaces you need to know about), and from obscurity (e.g. things you need to know about, which aren't obvious from the interfaces given). In some cases, many small methods would be an increase in complexity overall. In some cases, one big method may be an increase in complexity.

hinkley 7y ago
In most cases one big method is an increase of complexity (and others will add to it over time). Large methods are usually a failure of imagination, like bad and rambling prose. Code is a set of instructions for the computer, and for the next person who has to maintain it (“ Programs are meant to be read by humans and only incidentally for computers to execute.”) Cooking instructions are split into steps. Assembly instructions are split into steps. LEGO instructions are split into steps. When drawing instructions aren’t split into steps the Internet turns them into a cultural phenomenon (Step 2: draw the rest of the fucking owl). Only programmers think they are immune to this ridicule, smash all the steps together, and then get salty when others complain, ignoring a series of luminaries who beg in every format of media available, and for decades, to do otherwise. Seriously, organize your code, separate the steps. You’re killing us.
- mason55 7y ago
  No one disagrees that code needs to work in steps. The conversation is around how much and the answer is going to depend on what you're doing. Why have a function that prints a whole line? Isn't that just smashing together a bunch of small steps to print one character at a time?

taspeotis 7y ago

https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345

DavidVoid 7y ago
Since that blog seems to be down at the moment here's a cached version of the article/email. https://webcache.googleusercontent.com/search?q=cache:http://number-none.com/blow/john_carmack_on_inlined_code.html https://webcache.googleusercontent.com/search?q=cache:http:/...

ipnon 7y ago

The code that is easiest to revisit is decomposed into separate functions that are each trivial to understand. They are used to compose similarly trivial functions, and so on. Ideally every point of your program from input to output can be understood clearly and immediately.

0x445442 7y ago
Makes the test a hell of a lot easier and more robust as well.

reuben_scratton 7y ago

Absolutely this. More functions => More complexity => Bad. Also: decreased legibility, less opportunity for compiler optimisation.