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

271–280 of 603 posts

Re: The Grug Brained Developer (2022)

#271

Post by fingerlocks »

dpkirchner wrote: post #257
fingerlocks wrote: post #242

Earlier quoted context omitted.

All these print debugging advocates are blowing my mind. Are most people unaware that both lldb and gdb have conditional pass throughout breakpoints with function hooks? In other words, you can create a breakpoint that just prints its location and doesn’t pause execution. You can script this so all function entry/exists, or whatever, are logged without touching the code or needing to recompile. You can then bulk togg…

I can't tell you how many times lldb has failed to hit breakpoints or has dumped me in some library without symbols. This was in Xcode while writing an iOS app, maybe it's better in other environments. Print debugging, while not clever or powerful, has never once failed me.

Sometimes the debugserver is flakey, I’ll give you that. But some that also sounds like UI quirks such as ambiguous breakpoints on a function definition with default initialized default values.

You can attach lldb without Xcode. Or you can open the lldb terminal in Xcode, pause execution, and inspect the breakpoints manually

Re: The Grug Brained Developer (2022)

#272

Post by ozim »

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 wonder if Brian Kerninghan was using modern tooling or that comment was using quote from 70’s.

Re: The Grug Brained Developer (2022)

#273

Post by vharish »

dkarl wrote: post #103
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.

That's what I've observed empirically over my last half-dozen jobs. Many developers treat decomposition and contract design between services seriously, and work until they get it right. I've seen very few developers who put the same effort into decomposing the modules of a monolith and designing the interfaces between them, and never enough in the same team to stop a monolith from turning into a highly coupled amorph…

I think monoliths are not such a good idea anymore. Particularly with the direction development is going w.r.t the usage of LLMs, I think it's best to break things down. Ofcourse, it shouldn't be overdone.

Re: The Grug Brained Developer (2022)

#274

Post by mort96 »

tcoff91 wrote: post #255
johnfn wrote: post #208

Earlier quoted context omitted.

On the other hand, John Carmack loves debuggers - he talks about the importance of knowing your debugging tools and using them to step through a complex system in his interview with Lex Friedman. I think it's fair to say that there's some nuance to the conversation. My guess is that: - Debuggers are most useful when you have a very poor understanding of the problem domain. Maybe you just joined a new company or are e…

Adding print statements sucks when you are working on native apps and you have to wait for the compiler and linker every time you add one. Debuggers hands down if you are working on something like C++ or Rust. You can add tracepoints in your debugger if you want to do print debugging in native code. In scripting languages print debugging makes sense especially when debugging a distributed system. Also logging works b…

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

If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. And then I'll have to hope that I can reproduce the issue without optimizations.

Re: The Grug Brained Developer (2022)

#275

Post by scotty79 »

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…

What's insane is that debuggers could support at least 80-90% of print debugging workflow with a good UI.

The only thing that's really missing is history of the values of the watches you added, all in one log. With filters because why not.

For some reason I never seen this option in any debugger I tried.

Re: The Grug Brained Developer (2022)

#276

Post by arkh »

demosthanos wrote: post #107
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.

> 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 think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a networ…

> Developers almost universally lack discipline.

Or developers are given a deadline and no slack to learn the code base. So developers will tactically take the fastest route to closing their ticket.

Re: The Grug Brained Developer (2022)

#277

Post by mort96 »

hobs wrote: post #154
geophile wrote: post #147

Earlier quoted context omitted.

I am also in the camp that has very little use for debuggers. A point that may be pedantic: I don't add (and then remove) "print" statements. I add logging code, that stays forever. For a major interface, I'll usually start with INFO level debugging, to document function entry/exit, with param values. I add more detailed logging as I start to use the system and find out what needs extra scrutiny. This approach is ver…

A log is very different than a debugger though, one tells you what happened, one shows you the entire state and doesn't make you assemble it in your head.

I've never had a debugger show me the entire state. I'm not even sure I want to know the entire state, but GDB has a lot of issue with anything but the most basic data structures most of the time, and I always need to explicitly ask for what I want to see by calling things like operator[] (and then hope that the particular operator[] wasn't optimized out of the final binary). It's not exactly a great experience.

Re: The Grug Brained Developer (2022)

#278

Post by TeMPOraL »

demosthanos wrote: post #216
neogodless wrote: post #213

Earlier quoted context omitted.

> time to decide where to put print statements But... that's where you put breakpoints and then you don't need to "single-step" through code. Takes less time to put a breakpoint then to add (and later remove) temporary print statements. (Now if you're putting in permanent logging that makes sense, do that anyway. But that probably won't coincide with debugging print statements...)

True, but then you're still left stepping through your breakpoints one by one. Printf debugging gives you the full picture of an entire execution at a glance, allowing you to see time as it happened. The debugger restricts you to step through time and hold the evolution of state in your memory in exchange for giving you free access to explore the state at each point. Occasionally that arbitrary access is useful, but…

You can use tracepoints instead of breakpoints, or (easier, at least for me), set up breakpoints to execute "print stack frame, continue" when hit - giving you the equivalent of printf debugging, but one you can add/remove without recompiling (or even at runtime) and can give you more information for less typing. And, should this help you spot the problem, you can easily add another breakpoint or convert one of the "printing" ones so it stops instead of continuing.

And of course, should the problem you're debugging be throwing exceptions or crashing the app, the debugger can pause the world at that moment for you, and you get the benefit of debugging and having a "printf log" of the same execution already available.

Re: The Grug Brained Developer (2022)

#279

Post by rkomorn »

arkh wrote: post #276
demosthanos wrote: post #107

Earlier quoted context omitted.

> 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 think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a networ…

> Developers almost universally lack discipline. Or developers are given a deadline and no slack to learn the code base. So developers will tactically take the fastest route to closing their ticket.

This. You'll take "too long", you'll be told you're overthinking/overengineering, people will preach iterating, that done is better than perfect, etc.

It's not developers that lack discipline. It's CTOs, VPs, etc.

Re: The Grug Brained Developer (2022)

#280

Post by pydry »

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…

>Young grugs: learning this skill is a minor superpower. Take the time to get it working on your codebase, if you can.

TIL Linus Torvald is a young grug.

Post reply on HN