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

541–550 of 603 posts

Re: The Grug Brained Developer (2022)

#541

Post by melodyogonna »

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…

I think you're misremembering here, the other party is Ken Thompson not Brian K

Re: The Grug Brained Developer (2022)

#542

Post by chickenzzzzu »

mdaniel wrote: post #527
chickenzzzzu wrote: post #525

Earlier quoted context omitted.

Find me a bank that will give me a 150k collateralized loan and after 2 years I will give you the best AAA game you've ever played. You choose all the features. Vulkan/PC only. If you respond back with further features and constraints, I will explain in great detail how to implement them.

I suspect you're trolling, but if not then this is the kind of thing that kickstarter or indiegogo are designed to solve: give me money on my word, in 2 years you get license keys to this thing, assuming it materializes. I was going to also offer peer-to-peer platforms like Prosper but I think they top out at $50k

I agree with you, but I would prefer to not socialize the risks of the project among thousands of individuals, because that lessens their ability to collect against me legally.

By keep just one party to the loan, and most important, by me offering collateral to the loan in the event I do not deliver, then it keeps enforcement more honest and possible.

Furthermore, the loan contract should be written in such a way that the game is judged by the ONE TIME sales performance of the game (no microtransactions) and not qualitative milestones like features or reviews. Lastly, I would add a piece of the contract that says two years after the game is released, it becomes fully open source, similar to the terms of the BSL.

This is the fairest thing to the players, the bank, and the developer, and it lets the focus be absolutely rock solid on shipping something fun ASAP.

Re: The Grug Brained Developer (2022)

#543

Post by jcgl »

kryptiskt wrote: post #292
bandrami wrote: post #156

Earlier quoted context omitted.

Why would you want a GUI debugger?

Having the code, the callstack, locals, your watched variables and expressions, the threads, memory, breakpoints and machine code and registers if needed available at a glance? As well as being able to dig deeper into data structures just by clicking on them. Why wouldn't you want that? A good GUI debugger is a dashboard showing the state of your program in a manner that is impossible to replicate in a CLI or a TUI i…

I don’t disagree that a visual debugger made with a proper GUI toolkit is better than a TUI. However, nvim-dap-ui[0] does a pretty good job.

[0] https://github.com/rcarriga/nvim-dap-ui

Re: The Grug Brained Developer (2022)

#544

Post by zelphirkalt »

dgb23 wrote: post #45
12_throw_away wrote: post #11

This has by far the best discussion of the visitor pattern I've yet to come across.

I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern. https://craftinginterpreters.com/representing-code.html#the-... I remember reading through it and not understanding why it had to be this complicated and then just used a tagged u…

If you work in a language that can pass closures as arguments, then you don't need a special visitor pattern. It is one of those patterns, that exists because of limitations of languages. Or, if you want to call passing a closure visitor pattern in some cases, it becomes so natural, that it does not deserve special mention as something out of the ordinary. You may be too smart for it.

Re: The Grug Brained Developer (2022)

#545

Post by zelphirkalt »

recursivedoubts wrote: post #75
dgb23 wrote: post #45

Earlier quoted context omitted.

I don't work in typical OO codebases, so I wasn't aware of what the visitor pattern even is. But there's an _excellent_ book about building an interpreter (and vm) "crafting interpreters". It has a section where it uses the visitor pattern. https://craftinginterpreters.com/representing-code.html#the-... I remember reading through it and not understanding why it had to be this complicated and then just used a tagged u…

I love crafting interpreters and mention it on grugbrain: https://grugbrain.dev/#grug-on-parsing but the visitor pattern is nearly always a bad idea IMO: you should just encode the operation in the tree if you control it or create a recursive function that manually dispatches on the argument type if you don't

An implementor of a data structure might take precautions for users of the data structure to perform such visiting operations by passing in a visitor-like thing.

Re: The Grug Brained Developer (2022)

#546

Post by zelphirkalt »

ahartmetz wrote: post #77
12_throw_away wrote: post #11

This has by far the best discussion of the visitor pattern I've yet to come across.

I care about naming, and I find the name of the visitor pattern infuriatingly bad. Very clubbable. I think I have never created one called "Visitor" in my life. Given the syntax tree example from Wikipedia, I think I'd call it AstWalker, AstItem::dispatch(AstWalker) and AstWalker::process(AstItem) instead of Visitor, AstItem::accept(AstVisitor) and AstVisitor::visit(AstItem). "The walker walks the AST, each items sen…

But the idea of the visitor pattern is not, that it itself walks a tree. The idea is, that it doesn't know how to walk the tree and will be passed in elements from the tree, to its visit method. It does only need to know what to do with one element at a time. The walking is implemented elsewhere.

Re: The Grug Brained Developer (2022)

#547

Post by josephg »

dgb23 wrote: post #481
josephg wrote: post #194

Earlier quoted context omitted.

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?

Yeah that sounds right. Thanks for the correction!

Re: The Grug Brained Developer (2022)

#548

Post by mrngm »

GrumpyYoungMan wrote: post #218
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…

Debuggers are great until you have to work in a context where you can't attach a debugger. Good old printf works in every context. By all means, learn to use a debugger well but don't become overly dependent on them.

I'll introduce you to our bespoke tool that automatically restarts processes when they exit... and redirects stdout/err by default to /dev/null :D

Re: The Grug Brained Developer (2022)

#549

Post by kryptiskt »

fingerlocks wrote: post #514
kryptiskt wrote: post #505

Earlier quoted context omitted.

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

Yes, but in a GUI debugger the stack and everything else is available all the time and you don't have to enter commands to see what the state is. It even highlights changes as you step. It's just so plainly superior to any terminal solution.

Re: The Grug Brained Developer (2022)

#550

Post by pramodbiligiri »

sesm wrote: post #498
prmph wrote: post #405

> complexity very bad Oh boy, this is so true. In all my years of software engineering this is one of those ideas that has proved consistently true in every single situation. Some problems are inherently complex, yes, but even then you'd be much, much better off spending time to think things through to arrive at the simplest way to solve it. Again and again my most effective work has been after I questioned my prior…

Many talk complexity. Few say what mean complexity. Big brain Rich say complect is tie together. Me agree. Big brain Rich say complexity bad. Me disagree. Tie things necessary. If things not connected things not solve problem.

Haha. But I thought Rich Hickey was making the simple point that don't intertwine things than can be kept separate!

P.S: For those wondering what this refers to, here is his talk: https://youtu.be/SxdOUGdseq4?t=1896

Post reply on HN