This comic definitely speaks to me on a deep emotional level, but at the same time one of the things I like so much about computers is they're essentially unbreakable.
Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk.
(Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
Probably a bad example. Hammers are quite more unbreakable than computers, and the equipment you'd need to fix a computer hardware failure might also be more specialized (e.g. in the case of a short on a laptop motherboard). I'm no woodworker, but I imagine with a hammer you can get away with a stick and a hand-saw. Maybe a rock to hammer the wedge in. Can't imagine the hammer-head breaking.
> "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.
I recently got assigned to enhance some code I've never seen before. The code was so bad that I'd have to fully understand it and change multiple places to make my enhancement. I decided that if I was going to be doing that anyway, I might as well refactor it into a better state first. It feels so good to make things better instead of just making them do an extra thing.
Totally agree with this. I spent way too long fighting my dev environment last month before I finally sat down and properly configured everything. The ROI on fixing your tools is insane - what took me 2 hours of yak-shaving per week now takes zero.
The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.
I'm not convinced. At times it can be valueable, but at times you can go around in circles, changing checking variables/break points all the time, but never finding the problem. Often thinking about the problem and what is important is what you need. Playing in the debugger is fun and feels like progress, but it can just be a distraction from understanding the real problem.
I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
Ugh, this brings on flashbacks to when I had to work with Ruby, and the *** debugger would break with every single release. The RubyMine IDE that 45% of the company used was based on some bizarre custom Ruby gems to enable debugging, and that crap would take a month to be fixed by JetBrains. 10% used VSCode where debugging would sometimes work and sometimes not.
This is the reminder I needed. For some projects the python LSP I am using in Neovim just breaks sometimes. Always so frustrating when I start fuzzy searching instead of just jumping to a declaration or restart it.
hey, the idea of Krossover is actually dope! my sole question is, why does it exist?
I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful?
Calling Kotlin from Rust (and other languages) is useful when you want access to an existing Kotlin codebase and would rather avoid creating a full-blown port. I guess most people don't do things like this because creating bindings for languages that are not C (or C-like) is usually cumbersome. Krossover is trying to fill that gap for Kotlin. Does that make sense?
I takes less than 2 hours to chop down a tree [of the type Lincoln would have been chopping down with an ax - trees elsewhere may be different]. It doesn't take 4 hours to sharpen an ax unless you were mistreating it either though. So given 6 hours to chop down a tree I'd spend 15-20 minutes sharpening my ax (divided into several 2-5 minute sessions when I need a break anyway), 2 hours chopping the tree, and the remaining 3.5 hours reading a book. But I keep my tools in good shape so I don't need a long presharpending before the first cut.
I'm not physically in good enough shape to swing an ax for 2 hours, but I've done enough with an ax to know the above is right if I was in physical shape to do it.
More often than not I end up three or four tasks deep while trying to fix a tiny issue.
https://m.youtube.com/watch?v=_UZFI-8D5uA
Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk.
(Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
> "A good programmer, when encountering a debugger bug," he paused, cleared his throat, and said solemnly: "should immediately drop the program they're debugging and start debugging the debugger instead!" The auditorium once again erupted in thunderous applause.
My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.
I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
You're welcome.
I understand that one might call Rust from Kotlin for performance reasons (I do that often, Mozilla does, some others too), but Kotlin from Rust? where would it be useful?
no snark or subtext here, I'm genuinely curious
I'm not physically in good enough shape to swing an ax for 2 hours, but I've done enough with an ax to know the above is right if I was in physical shape to do it.