9 ms·

I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and mad

by taeric 4y ago

I can't but reflect back on another post I made today, which is that everything fails at scale. Literally everything. They just fail in different ways and made different tradeoffs along the way. For example, this is why I find myself using "print" debugging on a process of 10^4 values. It is fun to think that, "maybe I can step debug this" on that many values, but... that is well beyond my capability to keep it in my head, such that any help the debugger gives is added to zero. Which... is not good. That is, complaints that ridiculously large forms cause issues in a debugger seem... pointless? Lets say you managed to keep that from crashing, do you actually have a way to make it workable? Don't get me wrong, if folks are constantly opening JSON files that are gigabytes in size, it makes sense to focus on that and make sure it doesn't crash. I just, can't imagine what benefit you get from opening an X gigabyte file. I can't even see what the advantages of opening an X megabyte file are. That is literally beyond my brain power. So, looking to rewrite an emacs is always one that strikes me as a huge risk of throwing the baby out with the water. There is more than a fair chance that what you like about the current setup is a necessary implication of choices that you think you don't like.

jb1991 4y ago
Print debugging is a technique that will never go out of style. It works on any system, is used by programmers of any level of experience, is very quick to use and requires no tooling to understand. And sometimes, even if you do have other great tools at your disposal, it’s still the easiest way to track down a problem.
- taeric 4y ago
  I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it. Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
- worik 4y ago
  Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.
  - gpderetta 4y ago
    It requires a way to get bytes out of the system. You can connect an external console to that.
  - jb1991 4y ago
    Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.
    - pjmlp 4y ago
      Which is why a GPU debugger with frame tracing is so much better option. By the way, there are actually ways to expose a print function on shader code, provided there is driver support. https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/docs/debug_printf.md https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...
    - evrimoztamur 4y ago
      Well, not every system has a framebuffer, but here's a Carmack tweet that comes to mind: "gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins." — https://mobile.twitter.com/id_aa_carmack/status/568861553245728768 https://mobile.twitter.com/id_aa_carmack/status/568861553245...
      - emj 4y ago
        He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thing I go for during debug. [0] https://www.youtube.com/watch?v=UH-o5cG_QWo https://www.youtube.com/watch?v=UH-o5cG_QWo
- musicale 4y ago
  Logging - for debugging or for other purposes - is a very useful tool.
- whartung 4y ago
  As a general rule I prefer print debugging. I’ll step in with a breakpoint when I have to but odds are I’ve gone through a round of prints first. I do not enjoy stepping through all of the context setting up the system to fail. I’ve not tried a debugger that can “back up”, that may well be a different experience. But I loathe stepping through code, walking on eggs, overstepping, “oops, thar she blows, start over”. Like Bugs Bunny on the piana. Rather just toss in some prints, let fly, sift through the wreckage. My builds are fast enough to make the turn around acceptable.
maydup-nem 4y ago
> print debugging Curiously: https://project-mage.org/overcoming-the-print-statement https://project-mage.org/overcoming-the-print-statement
pjmlp 4y ago
That is why debuggers and OS support trace points and events for debugging at scale.
kqr 4y ago
I think you're onto something general here. At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility. Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.
- msravi 4y ago
  cat, grep, awk, sed, cut, paste, column
sudosysgen 4y ago
There are ways to debug at scale that aren't step debugging. You can set conditional breakpoints, or breakpoints that run code, or even backwards debugging. You don't have to settle with print debugging, ever. But sometimes it's faster to use it.
some-mthfka 4y ago
> I can't but reflect back on another post I made today, which is that everything fails at scale. That reminds me of: Terry Davis' TempleOS Brutal Take Down of Linus Torvalds https://youtu.be/gBE6glZNJuU?t=388 https://youtu.be/gBE6glZNJuU?t=388 All computer people today have been jedi-mindtricked, they obsess on if there's one thing they all wanna show you they know is scaling. Everybody is obsessed with scaling. Guess what. Scaling works both ways. You can get bigger. What happens if you look the other direction and you scale down? It doesn't get bad, it gets worse when you scale up. It gets better when you scale down. I think it's a fundamental problem of flexibility of specialization vs generality. I laid out my thoughts on this on the website in the "On Flexibility" article (There's an article on print statements, too, by the way).
narag 4y ago
I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big file? I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit. I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds. If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.
- scruple 4y ago
  Where's the pragmatism? I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway). I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.
  - narag 4y ago
    I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.
    - scruple 4y ago

by taeric 4y ago

jb1991 4y ago

Print debugging is a technique that will never go out of style. It works on any system, is used by programmers of any level of experience, is very quick to use and requires no tooling to understand. And sometimes, even if you do have other great tools at your disposal, it’s still the easiest way to track down a problem.

taeric 4y ago
I view it as "tracer bullets." I know it will make noise, but I'm planning to look at the pattern of the noise to see what I can reason out of it. Is it a complete answer? Of course not. Neither is trying to spin a wheel that you are truing. Produces a ton of output that is roughly in an expected pattern, and can be acted on.
worik 4y ago
Well yes, but I must quibble... > Print debugging.... It works on any system No it does not. It requires a console, and not all systems have a console.
- gpderetta 4y ago
  It requires a way to get bytes out of the system. You can connect an external console to that.
- jb1991 4y ago
  Well, you're right, of course. Another obvious one is that print debugging doesn't work for your GPU kernels.
  - pjmlp 4y ago
    Which is why a GPU debugger with frame tracing is so much better option. By the way, there are actually ways to expose a print function on shader code, provided there is driver support. https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/docs/debug_printf.md https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...
  - evrimoztamur 4y ago
    Well, not every system has a framebuffer, but here's a Carmack tweet that comes to mind: "gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins." — https://mobile.twitter.com/id_aa_carmack/status/568861553245728768 https://mobile.twitter.com/id_aa_carmack/status/568861553245...
    - emj 4y ago
      He also seems to like a timing/GPU/CPU debugger called PIX from MS, I'm impressed. I wish they had started with the hands on, but the presenters in this video[0] all show why print debug will never be enough. Getting back to the OP, for me even IDE integrated debugging is worse than print debugs. You need to so much data to make it useful for me, which makes things like PIX, APM and other application tracers the thing I go for during debug. [0] https://www.youtube.com/watch?v=UH-o5cG_QWo https://www.youtube.com/watch?v=UH-o5cG_QWo
musicale 4y ago
Logging - for debugging or for other purposes - is a very useful tool.
whartung 4y ago
As a general rule I prefer print debugging. I’ll step in with a breakpoint when I have to but odds are I’ve gone through a round of prints first. I do not enjoy stepping through all of the context setting up the system to fail. I’ve not tried a debugger that can “back up”, that may well be a different experience. But I loathe stepping through code, walking on eggs, overstepping, “oops, thar she blows, start over”. Like Bugs Bunny on the piana. Rather just toss in some prints, let fly, sift through the wreckage. My builds are fast enough to make the turn around acceptable.

maydup-nem 4y ago

> print debugging Curiously: https://project-mage.org/overcoming-the-print-statement https://project-mage.org/overcoming-the-print-statement

pjmlp 4y ago

That is why debuggers and OS support trace points and events for debugging at scale.

kqr 4y ago

I think you're onto something general here. At scale, there are two operations needed: zooming in on the details of interest, and surveying the big picture to find the details of interest. One or the other of the two are often lacking, either in power or flexibility. Critically, I don't think you get both power and flexibility along both types of operation and retain user-friendliness.

msravi 4y ago
cat, grep, awk, sed, cut, paste, column

sudosysgen 4y ago

There are ways to debug at scale that aren't step debugging. You can set conditional breakpoints, or breakpoints that run code, or even backwards debugging. You don't have to settle with print debugging, ever. But sometimes it's faster to use it.

some-mthfka 4y ago

> I can't but reflect back on another post I made today, which is that everything fails at scale. That reminds me of: Terry Davis' TempleOS Brutal Take Down of Linus Torvalds https://youtu.be/gBE6glZNJuU?t=388 https://youtu.be/gBE6glZNJuU?t=388 All computer people today have been jedi-mindtricked, they obsess on if there's one thing they all wanna show you they know is scaling. Everybody is obsessed with scaling. Guess what. Scaling works both ways. You can get bigger. What happens if you look the other direction and you scale down? It doesn't get bad, it gets worse when you scale up. It gets better when you scale down. I think it's a fundamental problem of flexibility of specialization vs generality. I laid out my thoughts on this on the website in the "On Flexibility" article (There's an article on print statements, too, by the way).

narag 4y ago

I just, can't imagine what benefit you get from opening an X gigabyte file. Maybe I don't fully understand the context, but... why shouldn't you open a big file? I haven't read the whole article, but I did read that the author complains that a 172 kb text file makes the editor slow. It seems that the syntax highlighting is the culprit. I have a similar problem with my current editor of choice. I used to have a "raw" visualizer for all kind of files. Sometimes the file format is just unknown and it's useful to take a look at its contents (does it start with PK?) or you want to make a quick overwriting edit (to change some binary flags) or edit text in a huge machine-generated text file without any formatting beyond line feeds. If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming. I agree wholeheartedly. It's a clear-cut case of the "don't repeat yourself" principle.

scruple 4y ago
Where's the pragmatism? I personally don't open GB size files (that's not true, I sometimes do but it depends on the format and I tend to use vim (which is a very minimal configuration on my system these days, since I've moved to Emacs) for them because I'm typically already in a terminal munging the thing anyway). I prefer to use the terminal to deal with these things because those tools can help me decompose the problem to a more reasonable space. That seems like a more useful way to spend my time than complaining that a massive file of text won't open on my editor for $REASONS, when it's, IMO, most likely that I wouldn't be able to make sense of the damned thing if I had it all opened in front of me anyway.
- narag 4y ago
  I believe the author of the article is criticizing Emacs for being a jack-of-all-trades that use neither the best approach for plain text (keep it simple, Syd) nor the best approach for code that I swear it's structured editing, after some time working in a system very similar to what some-mthfka describes in a sibling comment.
  - scruple 4y ago