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

511–520 of 603 posts

Re: The Grug Brained Developer (2022)

#511

Post by duderific »

kakuri wrote: post #475
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…

I loved Chrome's debugger for years, then build tools and React ruined debugging for me. Built code largely works with source maps, but it fails often enough, and in bizarre ways, that my workflow has simply gone back to console logs. React's frequent re-renders have also made breakpoints very unpleasant - I'd rather just look at the results of console logs. Are there ways I can learn to continue enjoying the debugge…

I find myself doing a mix of both. Source maps are good enough most of the time, I haven't seen the bizarre failures you're seeing - maybe your bundling configuration needs some tweaking? But yes, the frequent re-renders are obnoxious. In those cases logging is generally better.

Conditional breakpoints help alleviate the pain when there are frequent re-renders. Generally you can pinpoint a specific value that you're looking for and only pause when that condition is satisfied. Setting watch expressions helps a lot too.

Re: The Grug Brained Developer (2022)

#512

Post by default-kramer »

9rx wrote: post #470
1-more wrote: post #466

Earlier quoted context omitted.

I'm just talking null-less FP languages such as Haskell and Elm, not a full proof system such Lean and Agda or a formal specification language such as TLA+. I'm not sure I agree with your prior that "your tests are also going to 'deal with "what if this input is null?" everywhere' cases and whatnot." Invalid input is at the very edge of the program where it goes through a parser. If I parse a string value into a type…

Assume that there was room for null. What is your concrete example of where null becomes a problem in production, but goes unnoticed by your tests?

How many people actually write exhaustive tests for everything that could possibly be null? No one I've ever met in my mostly-C# career.

I can confirm that at least 30% of the prod alerts I've seen come from NullReferenceExceptions. I insist on writing new C# code with null-checking enabled which mostly solves the problem, but there's still plenty of code in the wild crashing on null bugs all the time.

Re: The Grug Brained Developer (2022)

#513

Post by kibibu »

johnfn wrote: post #265
kibibu wrote: post #243

Earlier quoted context omitted.

I'm sorry, but this juxtaposition is very funny to me: - John Carmack loves debuggers - Debuggers are most useful when you have a very poor understanding of the problem domain

If you listen to what he has to say, it’s quite interesting. He would occasionally use one to step through an entire frame of gameplay to get an idea of performance and see if there were any redundancies.

I really tried but could not take to Lex Friedman's interview style.

Re: The Grug Brained Developer (2022)

#514

Post by fingerlocks »

kryptiskt wrote: post #505
fingerlocks wrote: post #502

Earlier quoted context omitted.

You get all of that in the terminal debugger. That’s why dwarf files exist.

All the information is there, but the presentation isn't. You have to keep querying it while you're debugging. Sure, there are TUI debuggers that are more like GUI debuggers. Except that they are worse at everything compared to a GUI debugger.

I don’t know what debugger you’ve used but the entire query command is `f v` in lldb for the current stack frame

Re: The Grug Brained Developer (2022)

#516

Post by 9rx »

1-more wrote: post #491
9rx wrote: post #490

Earlier quoted context omitted.

> But right now I don't have to write defensive tests that include null. You seem to misunderstand. The question was centred around the fact that unexpected null cases end up being tested by virtue of you covering normal test cases due to the constraints on execution. Explicitly testing for null is something else. Something else I suggest unnecessary — at least where null is not actually part of the contract, which f…

Oh the errant nulls only ever came up when I was writing dynamically typed languages. Is that what you're asking about?

Not specifically, but if that is where your example comes from, that’s fine. It’s all the same. What have you got?

Re: The Grug Brained Developer (2022)

#517

Post by Kwantuum »

frollogaston wrote: post #468
monkeyelite wrote: post #425

Earlier quoted context omitted.

> debuggers don't work here It’s impossible? Or would take engineering work to enable

It's not a realtime system kind of thing where the debugger would change the behavior too much... It's possible with enough engineering work, but nobody has put that work in, in fact they had a debugger for some staging envs that they deleted. Lately they keep adding more red tape making it hard to even run something locally, let alone attach a debugger. I guess you can attach a debugger for unit tests, but that's no…

> I guess you can attach a debugger for unit tests, but that's not very useful.

That is in fact incredibly useful

Re: The Grug Brained Developer (2022)

#518

Post by api »

nyarlathotep_ wrote: post #215
api wrote: post #180

Earlier quoted context omitted.

There is now an entire generation of developers steeped in SaaS who literally don’t know how to do anything else, and have this insanely distorted picture of how much power is needed to do simple things. It’s hard to hire people to do anything else. People don’t know how to admin machines so forget bare metal even though it can be thousands of times cheaper for some work loads (especially bandwidth). You’re not exagg…

Thanks for making me feel less alone in this perspective--it's always been kind of verboten to say such a thing in those kinds of workplaces, but all my software type friends agree completely. The "entire generation of developers" paradigm is all over in different domains too--web programmers that seem to honestly think web development is only React/Angular and seem to have no idea that you can just write JS, python…

One way of looking at it is that there are about the same number of programmers today with a deep understanding of the machine as there were in the 90s. There are just 3-4X more programmers who are just after a career and learn only the skills necessary and follow what seem to be the most employable trends.

Same goes for users. There are about the same number of computer literate users as there were back then. There’s just a new class of iPad/iPhone user who is only a casual user of computers and the net and barely knows what a file is.

Re: The Grug Brained Developer (2022)

#519

Post by 9rx »

default-kramer wrote: post #512
9rx wrote: post #470

Earlier quoted context omitted.

Assume that there was room for null. What is your concrete example of where null becomes a problem in production, but goes unnoticed by your tests?

How many people actually write exhaustive tests for everything that could possibly be null? No one I've ever met in my mostly-C# career. I can confirm that at least 30% of the prod alerts I've seen come from NullReferenceExceptions. I insist on writing new C# code with null-checking enabled which mostly solves the problem, but there's still plenty of code in the wild crashing on null bugs all the time.

> How many people actually write exhaustive tests for everything that could possibly be null?

Of those who are concerned about type theory? 99%. With a delusional 1% thinking that a gimped type system (read: insufficient for formal proofs) is some kind of magic that negates the need to write tests, somehow not noticing that many of the lessons on how to write good tests come from those language ecosystems (e.g. Haskell).

> I can confirm that at least 30% of the prod alerts I've seen come from NullReferenceExceptions.

I don't think I've ever seen a null exception (or closest language analog) occur in production, and I spent a lot of years involved in projects that used dynamically typed languages even. I'd still love for someone to show actual code and associated tests to see how they ended up in that situation. The other commenter, despite being adamant, has become avoidant when it comes down to it.

Re: The Grug Brained Developer (2022)

#520

Post by tom_ »

ipdashc wrote: post #207
bandrami wrote: post #156

Earlier quoted context omitted.

Why would you want a GUI debugger?

Honestly, I consider myself pretty comfortable with the terminal and vim and whatnot, but I've never been able to get into using GDB. For me I feel like a debugger is one of those things that's just so much better as a proper GUI.

I can't do it either. Something about typing commands that have some kind of grammar and pressing Return to submit each one for consideration just throws me off. Don't make me think. Thinking is typically what got the code into this mess in the first place - whether too much of it or too little, it doesn't really matter. Time to try some other approach.
Post reply on HN