5 ms·

I wish there was an "auto-flattener"/"auto-inliner" tool that would allow you to automagically turn code that was written top-down, with lots of nicely high-lev

I wish there was an "auto-flattener"/"auto-inliner" tool that would allow you to automagically turn code that was written top-down, with lots of nicely high-level abstractions, into an equivalent code with all the actions mushed together and with infrastructure layers peeled away as much as possible. Have you ever seen a codebase with infrastructure and piping taking about 70% of the code, with tiny pieces of business logic thrown here and there? It's impossible to figure out where the actual job is being done (and what it actually is): all you can see is just an endless chain of methods that mostly just delegate the responsibility further and further. What could've been a 100-line loop of "foreach item in worklist, do A, B, C" kind is instead split over seven tightly cooperating classes that devote 45% of their code to multiplexing/load-balancing/messaging/job-spooling/etc, another 45% to building trivial auxiliary structure and instantiating each other, and only 10% actually devoted to the actual data processing, but good luck finding those 10%, because there is a never-ending chain of calling each other: A.do_work() calls B.process_item() which calls A.on_item_processing() which calls B.on_processed()... wait, shouldn't there been some work done between "on_item_processing" and "on_processed"? Yes, it was done by an inconspicuously named "prepare_next_worklist_item" function. Ah, and the icing on the cake: looping is actually done from the very bottom of this call chain by doing a recursive call to the top-most method which at this point is about 20 layers above the current stack frame. Just so you can walk down this path again, now with the feeling.

ambicapter 5y ago
> I wish there was an "auto-flattener"/"auto-inliner" tool that would allow you to automagically turn code that was written top-down, with lots of nicely high-level abstractions, into an equivalent code with all the actions mushed together and with infrastructure layers peeled away as much as possible. Learn to read assembly and knock yourself out.
- Jtsummers 5y ago
  That's not a very helpful response. Unless the code is compiled to native machine code and is all inlined, this won't help one bit.
  - nytgop77 5y ago
    Maybe not helpfull, but it made me smile :-)
  - AtlasBarfed 5y ago
    On today's HN with this thread is "the hole in mathematics". It is directly germane to what you are talking about. In the process of formalizing axiomatic math, 1+1=2 took 700 pages in a book to formally prove. The point about assembly is more or less correct. The process of de-abstracting is going to be long and probably not that clear in the end. I understand what you mean: the assembly commenter is correct, you'll need to actually execute the program and reduce it to a series of instructions it actually performed. Which is either an actual assembly, or a pseudo-assembly instruction stream for the underlying turing machine: your computer.
    - Joker_vD 5y ago
      I really need you to introduce you to Jester, my toy functional programming language. It compiles down to pure lambda calculus (data structures are implemented with Scott-Mogensen encoding) and then down to C that uses nothing but function calls and assignments of pointers to struct fields. The logic and arithmetic are all implemented in the standard library: a Bool is a function that takes 2 continuations, a Byte is 8 Bool, an Int is 4 Byte, addition uses the good old ripple-carry algorithm, etc. Reading the disassembly of the resulting program is pretty unhelpful: any function consists entirely of putting values from the fields of the passed-in structures into the fields of new structures and (tail)calling another function and passing it some mix of old/new structures.
vikiomega9 5y ago
Most editors have code folding. I've noticed this helps when there are comments or it's easy to figure out the branching or what not. However, what you're asking for is a design style that's hard to implement I think without language tooling (for example identifying effectful methods).
- TeMPOraL 5y ago
  GP is asking for the opposite. They're asking for code unfolding. That is, given a "clean code like": auto DoTheThing(Stuff stuff) -> Result { const auto foo = ProcessSth(stuff); const auto bar = ValidateSthElse(stuff); return DoSth(foo, bar); } The tool would inline all the function calls. That is, for each of ProcessSth(), ValidateSthElse() and DoSth(), it would automatically perform the task of "copy the function body, paste it at the call site, and massage the caller to make it work". It's sometimes called the "inline function" refactoring - the inverse of "extract function"/"extract method" refactoring. I'd really, really want such a tool. Particularly one where the changes were transient - not modifying the source code, just overlaying it with a read-only replacement. Also interactive. My example session is: - Take the "clean code" function that just calls a bunch of other functions. With one key combination, inline all these functions. - In the read-only inlined overlay, mark some other function calls and inline them too. - Rinse, repeat, until I can read the overlay top-to-bottom and understand what the code is actually doing.
  - vikiomega9 5y ago
    I'm curious to understand your use-case, would be open to explaining more? Do you actually want to overlay the code directly into the parent method or would a tooltip (similar to hyperlink previews) work? I wondering how expanding the real estate space would help with readability and how the userflow would work. For example, code folding made a lot more sense because the window would have those little boxes to fold unfold (which is basically similar to the act of inline and un-inline).
    - TeMPOraL 5y ago
      Yes, I want to overlay the code directly into the parent method, preferably with appropriate syntax highlighting and whatever other goodies the IDE/editor provides normally. It would be read-only to indicate that it's just a transient overlay, and not an actual code change. So, if I have a code like: auto Foo(Bar b) { return b.knob(); } auto Frob(Frobbable f) { auto q = Foo(f.thing()); return q.quux(f.otherthing()); } auto DoSth(Frobbable frobbie) { auto a = Frob(frobbie); return a.magic(); } Then I want to mark the last function, and automatically turn it into: auto DoSth(Frobbable frobbie) { auto foo_1 = frobbie.thing(); auto q_1 = foo_1.knob(); auto frob_1 = frobbie.otherthing(); auto a = q_1.quux(frob_1); return a.magic(); } Or something equivalent, possibly with highlights/synthetic comments telling me which bits of code came from where. I want to be able to keep inlining function calls like this, until I hit a boundary layer like the standard library, or a third-party library. I might want to expand past that, but I don't think I'd do that much. I'd also like to be able to re-fold code I'm not interested in, to reduce noise. What such tool would do is automating the process I'm currently doing manually - jumping around the tiny functions calling other tiny functions, in order to reassemble the actual sequence of lower-level operations. I don't want this to be a tooltip, because I want to keep expanding past the first level, and have the overlay stay in place until I'm done with it. EDIT: languages in the Lisp family - like Common Lisp or Emacs Lisp - feature a tool called "macroexpander". Emacs/SLIME wraps it into an interactive "macrostepper" that behaves pretty much exactly like the tool I described in this discussion thread. EDIT2: See the excellent demo upthread by ' emilprogviz - https://news.ycombinator.com/item?id=27306118 https://news.ycombinator.com/item?id=27306118. That's the kind of tool I had in mind.
josephg 5y ago
Your comment gives me emotional flashbacks. Years ago I took Java off my resume, because I don’t want to ever interact with this sort of thing again. (I’m sure it exists in other languages, but I’ve never seen it quite as bad as in Java.) I think the best “clean code” programming advice is the advice writers have been saying for centuries. Find your voice. Be direct and be brief. But not too brief. Programming is a form of expression. Step 1 is to figure out what you’re trying to say (eg the business logic). Then say it in its most natural form (switch statements? If-else chain? Whatever). Then write the simplest scaffold around it you can so it gets called with the data it needs. The 0th step is stepping away from your computer and naming what you want your program to express in the first place. I like to go for walks. Clear code is an expression of clear thoughts. You’ll usually know when you’ve found it because it will seem obvious. “Oh yeah, this code is just X. Now I just have to type it up.”
hackinthebochs 5y ago
>I wish there was an "auto-flattener"/"auto-inliner" tool I'm as big an advocate of "top-down" design as anyone, and I have also wished for such a tool. When you just want to know "what behavior comes next", all the abstractions do get in the way. The IDE should be able to "flatten" the execution path from current context and give you a linear view of the code. Sort of like a trace of a debug session, but generated on-the-fly. But still, I don't think this is the best way to write code.

ambicapter 5y ago

> I wish there was an "auto-flattener"/"auto-inliner" tool that would allow you to automagically turn code that was written top-down, with lots of nicely high-level abstractions, into an equivalent code with all the actions mushed together and with infrastructure layers peeled away as much as possible. Learn to read assembly and knock yourself out.

Jtsummers 5y ago
That's not a very helpful response. Unless the code is compiled to native machine code and is all inlined, this won't help one bit.
- nytgop77 5y ago
  Maybe not helpfull, but it made me smile :-)
- AtlasBarfed 5y ago
  On today's HN with this thread is "the hole in mathematics". It is directly germane to what you are talking about. In the process of formalizing axiomatic math, 1+1=2 took 700 pages in a book to formally prove. The point about assembly is more or less correct. The process of de-abstracting is going to be long and probably not that clear in the end. I understand what you mean: the assembly commenter is correct, you'll need to actually execute the program and reduce it to a series of instructions it actually performed. Which is either an actual assembly, or a pseudo-assembly instruction stream for the underlying turing machine: your computer.
  - Joker_vD 5y ago
    I really need you to introduce you to Jester, my toy functional programming language. It compiles down to pure lambda calculus (data structures are implemented with Scott-Mogensen encoding) and then down to C that uses nothing but function calls and assignments of pointers to struct fields. The logic and arithmetic are all implemented in the standard library: a Bool is a function that takes 2 continuations, a Byte is 8 Bool, an Int is 4 Byte, addition uses the good old ripple-carry algorithm, etc. Reading the disassembly of the resulting program is pretty unhelpful: any function consists entirely of putting values from the fields of the passed-in structures into the fields of new structures and (tail)calling another function and passing it some mix of old/new structures.

vikiomega9 5y ago

Most editors have code folding. I've noticed this helps when there are comments or it's easy to figure out the branching or what not. However, what you're asking for is a design style that's hard to implement I think without language tooling (for example identifying effectful methods).

TeMPOraL 5y ago
GP is asking for the opposite. They're asking for code unfolding. That is, given a "clean code like": auto DoTheThing(Stuff stuff) -> Result { const auto foo = ProcessSth(stuff); const auto bar = ValidateSthElse(stuff); return DoSth(foo, bar); } The tool would inline all the function calls. That is, for each of ProcessSth(), ValidateSthElse() and DoSth(), it would automatically perform the task of "copy the function body, paste it at the call site, and massage the caller to make it work". It's sometimes called the "inline function" refactoring - the inverse of "extract function"/"extract method" refactoring. I'd really, really want such a tool. Particularly one where the changes were transient - not modifying the source code, just overlaying it with a read-only replacement. Also interactive. My example session is: - Take the "clean code" function that just calls a bunch of other functions. With one key combination, inline all these functions. - In the read-only inlined overlay, mark some other function calls and inline them too. - Rinse, repeat, until I can read the overlay top-to-bottom and understand what the code is actually doing.
- vikiomega9 5y ago
  I'm curious to understand your use-case, would be open to explaining more? Do you actually want to overlay the code directly into the parent method or would a tooltip (similar to hyperlink previews) work? I wondering how expanding the real estate space would help with readability and how the userflow would work. For example, code folding made a lot more sense because the window would have those little boxes to fold unfold (which is basically similar to the act of inline and un-inline).
  - TeMPOraL 5y ago
    Yes, I want to overlay the code directly into the parent method, preferably with appropriate syntax highlighting and whatever other goodies the IDE/editor provides normally. It would be read-only to indicate that it's just a transient overlay, and not an actual code change. So, if I have a code like: auto Foo(Bar b) { return b.knob(); } auto Frob(Frobbable f) { auto q = Foo(f.thing()); return q.quux(f.otherthing()); } auto DoSth(Frobbable frobbie) { auto a = Frob(frobbie); return a.magic(); } Then I want to mark the last function, and automatically turn it into: auto DoSth(Frobbable frobbie) { auto foo_1 = frobbie.thing(); auto q_1 = foo_1.knob(); auto frob_1 = frobbie.otherthing(); auto a = q_1.quux(frob_1); return a.magic(); } Or something equivalent, possibly with highlights/synthetic comments telling me which bits of code came from where. I want to be able to keep inlining function calls like this, until I hit a boundary layer like the standard library, or a third-party library. I might want to expand past that, but I don't think I'd do that much. I'd also like to be able to re-fold code I'm not interested in, to reduce noise. What such tool would do is automating the process I'm currently doing manually - jumping around the tiny functions calling other tiny functions, in order to reassemble the actual sequence of lower-level operations. I don't want this to be a tooltip, because I want to keep expanding past the first level, and have the overlay stay in place until I'm done with it. EDIT: languages in the Lisp family - like Common Lisp or Emacs Lisp - feature a tool called "macroexpander". Emacs/SLIME wraps it into an interactive "macrostepper" that behaves pretty much exactly like the tool I described in this discussion thread. EDIT2: See the excellent demo upthread by ' emilprogviz - https://news.ycombinator.com/item?id=27306118 https://news.ycombinator.com/item?id=27306118. That's the kind of tool I had in mind.

josephg 5y ago

Your comment gives me emotional flashbacks. Years ago I took Java off my resume, because I don’t want to ever interact with this sort of thing again. (I’m sure it exists in other languages, but I’ve never seen it quite as bad as in Java.) I think the best “clean code” programming advice is the advice writers have been saying for centuries. Find your voice. Be direct and be brief. But not too brief. Programming is a form of expression. Step 1 is to figure out what you’re trying to say (eg the business logic). Then say it in its most natural form (switch statements? If-else chain? Whatever). Then write the simplest scaffold around it you can so it gets called with the data it needs. The 0th step is stepping away from your computer and naming what you want your program to express in the first place. I like to go for walks. Clear code is an expression of clear thoughts. You’ll usually know when you’ve found it because it will seem obvious. “Oh yeah, this code is just X. Now I just have to type it up.”

hackinthebochs 5y ago

>I wish there was an "auto-flattener"/"auto-inliner" tool I'm as big an advocate of "top-down" design as anyone, and I have also wished for such a tool. When you just want to know "what behavior comes next", all the abstractions do get in the way. The IDE should be able to "flatten" the execution path from current context and give you a linear view of the code. Sort of like a trace of a debug session, but generated on-the-fly. But still, I don't think this is the best way to write code.