Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

331–340 of 603 posts

Re: The Grug Brained Developer (2022)

#331

Post by writebetterc »

mort96 wrote: post #316
writebetterc wrote: post #311

Earlier quoted context omitted.

>How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically 10 minutes. >If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. Typically always compile with debug support. You can debug an optimized build as well. Full recom…

10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with. Have you tried out the Mold linker? It might speed it up significantly. > You can debug an optimized build as well. Eh, not really. Working with a binary where all variables are optimized out and all operators are inlined is hell.

>10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with.

I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit.

> Eh, not really. Working with a binary where all variables are optimized out and all operators are inlined is hell.

Yeah, but sometimes that's life. Reading the assembly and what not to figure things out.

>That must absolutely suck to work with.

Well, you know, I also get to work on something approximately as exciting as Chromium.

Re: The Grug Brained Developer (2022)

#332

Post by TZubiri »

hajhatten wrote: post #329
TZubiri wrote: post #322

Earlier quoted context omitted.

https://i.imgflip.com/9xrblc.jpg

There's a time and place for everything, and an escalation of tooling/environmental context for me. 1. Printing vars in unit tests may be the fastest first approach. If i know where the bug may be. 2. When that fails i usually bring in debuggers to unit tests. 3. When these aren't helping, you need debuggers on the entire binary. 4. Still stuck? Use a debugger in production.

Isn't 4 very unsafe? I wouldn't trust my code to pause in places that it doesn't usually pause in.

3. What if the binary interacts with other networked computers, you gonna debug all of them? Do you end up instrumeting the whole internet? You scope out, you spiral out of control until someone puts a limit.

Re: The Grug Brained Developer (2022)

#333

Post by mort96 »

writebetterc wrote: post #331
mort96 wrote: post #316

Earlier quoted context omitted.

10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with. Have you tried out the Mold linker? It might speed it up significantly. > You can debug an optimized build as well. Eh, not really. Working with a binary where all variables are optimized out and all operators are inlined is hell.

>10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with. I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit. > Eh, not really. Working with a binary where all variables are optimized out and all operator…

> I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit.

Yeah, which is why I was talking about source files. I was surprised that changing 1 source file (meaning re-compiling that one source file and then re-linking the project) takes 10 minutes. If you're changing header files then yeah it's gonna take longer.

Re: The Grug Brained Developer (2022)

#334

Post by Cthulhu_ »

titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

It's been years since I last used a debugger, but then, it's been years since I last worked on code that was complicated enough to warrant it.

Which is a good thing! Easily comprehended code that you can reason about without stepping through it is good for grug brain.

Re: The Grug Brained Developer (2022)

#335

Post by writebetterc »

mort96 wrote: post #333
writebetterc wrote: post #331

Earlier quoted context omitted.

>10 minutes for linking? The only projects I've touched which have had those kinds of link times have been behemoths like Chromium. That must absolutely suck to work with. I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit. > Eh, not really. Working with a binary where all variables are optimized out and all operator…

> I don't know the exact amounts of time per phase, but you might change a header file and that will of course hurt you a lot more than 1 translation unit. Yeah, which is why I was talking about source files. I was surprised that changing 1 source file (meaning re-compiling that one source file and then re-linking the project) takes 10 minutes. If you're changing header files then yeah it's gonna take longer.

FWIW, I've heard from people who know this stuff that linking is actually super slow for us :). I also wanted to try out mold, but I couldn't manage to get it to work.

Re: The Grug Brained Developer (2022)

#336

Post by withinboredom »

isoprophlex wrote: post #330
default-kramer wrote: post #95

Earlier quoted context omitted.

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

I swear I'm not making this up; a guy at my current client needed to join two CSV files. A one off thing for some business request. He wrote a REST api in Java, where you get the merged csv after POSTing your inputs. I must scream but I'm in a vacuum. Everyone is fine with this. (Also it takes a few seconds to process a 500 line test file and runs for ten minutes on the real 20k line input.)

I mean, it would be faster to just import them into an in-memory sqlite database, run a `union all` query and then dump it to a csv...

That's still probably the wrong way to do it, but 10 minutes for a 20k line file? That seems like poor engineering in the most basic sense.

Re: The Grug Brained Developer (2022)

#337

Post by jemmyw »

demosthanos wrote: post #127
titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

I personally use both, and I'm not sure I find the argument about needing to step through convincing. I put the debugger breakpoint at the same place I might put a print. I hardly ever step through, but I do often continue to reach this line again. The real advantage is that you can inspect the current state live and make calls with the data.

However, I use prints a lot more because you can, as you say, usually get to the answer faster.

Re: The Grug Brained Developer (2022)

#338

Post by ay »

titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

There might be another factor at not using the debugger beyond the pure cluelessness: often you can’t really run it in production. Back when I started with coding (it was Turbo Pascal 3.0, so you get the idea :-), I enjoyed the use of the debugger quite a lot.

But in 2000 I started working in a role which required understanding the misbehavior of embedded systems that were forwarding the live traffic, there was a technical possibility to do “target remote …” but almost never an option to stop a box that is forwarding the traffic.

So you end up being dependent on debugs - and very occasional debug images with enhanced artisanal diagnostics code (the most fun was using gcc’s -finstrument-function to catch a memory corruption of an IPSec field by an unrelated IKE code in a use-after free scenario)

Where the GDB shined though is the analysis of the crash dumps.

Implementing a “fake” gdb stub in Perl, which was sucking in the crash dump data and allow to leisurely explore it with debugger rather than decoding hex by hand, was a huge productivity boon.

So I would say - it’s better to have more than one tool in the toolbox and use the most appropriate one.

Re: The Grug Brained Developer (2022)

#339

Post by strken »

TeMPOraL wrote: post #298
strken wrote: post #269

Earlier quoted context omitted.

As I said, conditional . As in, you add logging to your code but you either remove it at compile time or you check your config at run time. By definition, work you don't do is not done.

Conditionals aren't free either, and conditionals - especially compile-time - on logging code are considered by some a bugprone anti-pattern as well. The code that computes data for and assembles your log message may end up executing logic that affects the system elsewhere. If you put that code under conditional, your program will behave differently depending on the logging configuration; if you put it outside, you e…

This is getting a bit far into the weeds, but I've found that debug output which is disabled by default in all environments is quite safe. I agree that it would be a problem to leave it turned on in development, testing, or staging environments.

Re: The Grug Brained Developer (2022)

#340

Post by nmeofthestate »

demosthanos wrote: post #127
titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

I disagree - using an interactive debugger can give insights that just looking at the code can't (tbf it might be different for different people). But the number of times I have found pathological behaviour from just stepping through the code is many. Think "holy f**, this bit of code is running 100 times??" type stuff. With complex event-driven code written by many teams, it's not obvious what is happening at runtime by just perusing the code and stroking one's long wizard beard.
Post reply on HN