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

481–490 of 603 posts

Re: The Grug Brained Developer (2022)

#481

Post by dgb23 »

josephg wrote: post #194
demosthanos wrote: post #127

Earlier quoted context omitted.

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…

There's another story I heard once from Rob Pike about debugging. (And this was many years ago - I hope I get the details right). He said that him and Brian K would pair while debugging. As Rob Pike told it, he would often drive the computer, putting in print statements, rerunning the program and so on. Brian Kernighan would stand behind him and quietly just think about the bug and the output the program was generati…

You might be confusing Brian with Ken?

Re: The Grug Brained Developer (2022)

#482

Post by osigurdson »

recursivedoubts wrote: post #449
zero_shift wrote: post #447

Earlier quoted context omitted.

What exactly is complexity? How do I recognise it? When do I tell whether something is complex or I am just not very familiar with it?

really hard questions but complexity bad

If Grug sees new code base, sometime Grug get anxiety about learning new code. What in it for Grug? Says Grug. Rather start new project and say "complexity bad" to other Grugs. If other Grug or big brain disagree, create Grug tribe - show bible to other Grugs and big brains. Must convert to Grug way or leave team. Complexity bad.

Re: The Grug Brained Developer (2022)

#483

Post by frollogaston »

glurgl wrote: post #364
frollogaston wrote: post #134

Earlier quoted context omitted.

The only useful definition of a "service" I've ever heard is that it's a database. Doesn't matter what the jobs and network calls are. One job with two DBs is two services, one DB shared by two jobs is one service. We once had 10 teams sharing one DB, and for all intents and purposes, that was one huge service (a disaster too).

Yes! My viewpoint also. I've been very alone in that view over the last few decades. Nice to know there's someone else out there.

At least it's widely considered bad practice for two services to share a database. But that's different from orienting your entire view of services around databases. The case of one job with two DBs matters too, mostly because there's no strong consistency between them.

Re: The Grug Brained Developer (2022)

#484

Post by dgb23 »

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…

Console logs in the browser have some unique advantages. You can assign the output to a variable, play with it etc.

But yes, any code that is inside jsx generally sucks to debug with standard tooling. There are browser plugins that help you inspect the react ui tree though.

Re: The Grug Brained Developer (2022)

#485

Post by 1-more »

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?

In a world where I am writing a language with null and have half-implemented a grown up type system by checking for null everywhere and writing tests that try to call functions with null (EDIT: and I remembered to do all of that), I guess we could say that I'm at the same place I am right now. But right now I don't have to write defensive tests that include null.

You're asking about a circumstance that's just very very different from the one I'm in.

Re: The Grug Brained Developer (2022)

#486

Post by zero_shift »

osigurdson wrote: post #482
recursivedoubts wrote: post #449

Earlier quoted context omitted.

really hard questions but complexity bad

If Grug sees new code base, sometime Grug get anxiety about learning new code. What in it for Grug? Says Grug. Rather start new project and say "complexity bad" to other Grugs. If other Grug or big brain disagree, create Grug tribe - show bible to other Grugs and big brains. Must convert to Grug way or leave team. Complexity bad.

Grog is not Grug. Grog talk like Grug, walk like Grug, obey rituals of simplicity worship like Grug. But Grog secretly just mean: anything he didn't invent, not worth learning, anything not making his resume-weave, not worth doing. So Grog is always saying, boo! complexity here! rewrite time!!

Re: The Grug Brained Developer (2022)

#487

Post by osigurdson »

zero_shift wrote: post #486
osigurdson wrote: post #482

Earlier quoted context omitted.

If Grug sees new code base, sometime Grug get anxiety about learning new code. What in it for Grug? Says Grug. Rather start new project and say "complexity bad" to other Grugs. If other Grug or big brain disagree, create Grug tribe - show bible to other Grugs and big brains. Must convert to Grug way or leave team. Complexity bad.

Grog is not Grug. Grog talk like Grug, walk like Grug, obey rituals of simplicity worship like Grug. But Grog secretly just mean: anything he didn't invent, not worth learning, anything not making his resume-weave, not worth doing. So Grog is always saying, boo! complexity here! rewrite time!!

Grug like say - No True Grugsman. Only True Grug pure Grug.

Re: The Grug Brained Developer (2022)

#488

Post by 0xbadcafebee »

recursivedoubts wrote: post #450
0xbadcafebee wrote: post #415

Me no like grug perpetuate complexity myth. Little grugs no understand complexity is not monolith. Me want fix that. Complexity not bad. Complexity just mean "thing have many consideration". Some thing always have many consideration. Not bad if useful and necessary. Complexity still difficult and raise problem. So try avoid complexity when unnecessary and no add value. But shun complexity bad when it detract value or…

that's a good point, but complexity bad

if complexity bad, then houses bad, air conditioning bad, roads bad, clothing bad, farming bad, computers bad, ....

simpler to live naked in wood, use big rock hunt food. but grug really like pizza. use computer order pizza, leave tip on app. grug no have to social interact, make grug happy.

manage complexity well and it make good result, worth occasional pain. soon complexity become normal.

Re: The Grug Brained Developer (2022)

#489

Post by drewhk »

osigurdson wrote: post #482
recursivedoubts wrote: post #449

Earlier quoted context omitted.

really hard questions but complexity bad

If Grug sees new code base, sometime Grug get anxiety about learning new code. What in it for Grug? Says Grug. Rather start new project and say "complexity bad" to other Grugs. If other Grug or big brain disagree, create Grug tribe - show bible to other Grugs and big brains. Must convert to Grug way or leave team. Complexity bad.

Grug hurt itself in its confusion!

Re: The Grug Brained Developer (2022)

#490

Post by 9rx »

1-more wrote: post #485
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?

In a world where I am writing a language with null and have half-implemented a grown up type system by checking for null everywhere and writing tests that try to call functions with null (EDIT: and I remembered to do all of that), I guess we could say that I'm at the same place I am right now. But right now I don't have to write defensive tests that include null. You're asking about a circumstance that's just very ve…

> 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 for the purposes of our discussion is the case. Again, we're specifically talking about the testing that is necessary to the extent of covering what is missing in the type system when you don't have a formal proof language in hand.

> You're asking about a circumstance that's just very very different from the one I'm in.

But one you've clearly had trouble with in the past given your claims that you weren't able to deal with it. Otherwise, how would you know?

Perhaps I can phrase my request in another way: If null isn't expected in your codebase, and your testing over where the type system is lacking has covered your bases to know that the behaviour is as documented, where are the errant nulls going to magically appear from?

Post reply on HN