Hacker News Reader

Comment by azinman2 | Hacker News Reader

It'd be nice if there was a way that when compilers "re-write" or eliminate parts, those could be highlighted or otherwise nicely conveyed in our IDEs.

I don't know why we expect phones and apps to have modern great UX, solving all kinds of problems, but our text editors should remain essentially the same as in the 70s.

View on HN

The 70s era bit of this is the thinking that compilers 'sometimes re-write parts' of your program. Really they completely break your entire program down and then build it up from the ground again. Everything would show up as having been rewritten.

In this specific case an IDE could conceivably highlight a check that the compiler will omit, or point at undefined behaviour directly. The general aim is probably unachievable as you suggest - if 3 functions are rewritten to one it'd be hard to point out where the change was applied.

Most C/C++ compilers support outputting line number information even for optimized code (DWARF for example has a specific mechanism for identifying inlined code in stack traces). That's more than enough location data to provide something useful.

Seeing e.g. the original source in the disassembly window is useful. And the same info lets you do things like: https://gcc.godbolt.org/

Taking that information into any sort of "yeah, this still represents the original intent of the author" highlight/lack of highlight/summary as it sounds like azinman2 wants might be a little more difficult. (After all, if you can implement that, why not have your compiler only emit 'sane' code in the first place?)

That would be a nice research project for a PhD or two, but I think it will be very difficult to present optimizations in a way that is useful for the programmer. In this case for example the optimization concerns an inline function. The compiler might optimize it in completely different ways depending on the context. How do you present that in the editor? It would also make compilation much slower, I think, because you have to schlepp around all the information that you use for the optimizations.

There are some tools that go in that direction. For example clang can help you help the optimizer auto vectorize loops: http://llvm.org/docs/Vectorizers.html#diagnostics

but our text editors should remain essentially the same as in the 70s

Not everybody expexts that:

I use sublime text for smaller editing tasks (although vscode and notepad++ are kind of ok too) and Visual studio or in my case preferably Netbeans for anything bigger (although I accept that this might sound weird).

Only if I connect over ssh or work on a console I prefer vim.

Edit: also my preferred IDE already does something similar by telling me whenever it thinks something can obviously be simplified or written in a more idiomatic way.

To both replies so far, I'd say open your mind a bit. Think about it this way... email was invented long, long ago, yet people have moved onto facebook and snapchat and instagram and all these completely different experiences there are more nuanced and richer. If you squint your eyes, programming is basically the same.... there are vast opportunities to change how it fundamentally works. Having feedback loops from the compiler into your source code (it can be visualized in a wide number of ways) is just one area that's low-hanging fruit that could also help with such security vulnerabilities.

Hi, compiler author here. You're not being downvoted for your POV, but because you're not grokking that the thing that you are asking for is fundamentally difficult.

Nearly all serious compilers have at least one representation which is not isomorphic for all programs. (It is homomorphic, which is required for the compiler to be correct.) As a consequence, at least some programs will be mangled beyond recognition.

Hi, creative programmer here.

Just because it's hard doesn't mean it isn't worthwhile to do, or that everything the compiler does must be reserved and shown in the IDE. I'm also not suggesting that this compiler feedback is the only IDE improvement we make. I'm observing that the entire way we develop software hasn't fundamentally changed in decades, yet every other aspect of computing has. Even something that roughly seems the same like word processing is now collaborative and in the cloud with real-time updates and social threads.

Light table is one IDE that is trying to question some assumptions -- like that files are important and that everything must be 1 line spaces apart in mono font. This is the kind of progress I'd like to see.

It does seem reasonable that there be a way, even if difficult, to highlight a bounds check that gets optimized away. If we start from the problem we're trying to solve (show eliminated code that poses security risks... such as bounds checks or erasing memory) rather than the general problem (reverse all compiler changes), then things become more tractable.

Reply on news.ycombinator.com