It's quite interesting to me the way that different "programming cultures" exist around debuggers.
If you grew up doing windows C++ development, looking at things in a debugger is your first step. You only resort to printing values if you can't immediately see what happened in the debugger.
A lot of other envioronment/language cultures are the opposite. Obviously both have their place, but I do feel like more people should use the debugger as the first step instead of the last.
For embedded applications, especially robotics, it tends not to be a great default because it stops the process, which tends to be bad for realtime control loops. That said, a complete hang is the situation where I absolutely would try to get a debugger attached and get a backtrace as one of the first things to try.
This kind of stuff is why devs doing safety critical work often painfully reinvent the wheel. Even if you’ve personally read the code yourself and think you understand it, there’s always some latent defect that arises from someone else’s bad assumptions.
Yeah. Actually, as I read it, I'm not sure if the robot is running WebRTC or not (In my comment I assumed it was)
But yeah it would be much more predictable for everyone if the robot didn't use WebRTC or the fancy logging library, and there was a WebRTC shim on the laptop to get the visuals into a browser.
The longer I think about that 10 ms control loop, the more I hope they aren't running any WebRTC thing on the same hardware cores as the control loop.
Man I miss embedded robotics work. So fun to write a control loop / algorithm and then see it play out in the real world. <robot crashes into wall> Whoops, guess we better review that routine...
The last photo appears to show the view out the author's office in Fort Mason. Didn't know they had offices there, that's quite a nice view of the Bay.
> But I will never call into a library I don't fully understand while holding a mutex again. Fool me once.
Nice sentiment and an admirable goal. Not really actionable in practice. Even if we disregard all userspace libraries out there, fully understanding the most frequently used syscalls is a monumental task already. You have to pick your battles in terms of understanding parts of a complex system.
Sometimes I yearn for the Haskell or Idris style of programming where a dependency can do nothing harmful or stupid without me passing in permission.
Then I think about having to pass in thread handles and file handles to logging libraries. I don't know. It would be a cool option. There is probably a hack for `tracing` that would let me manage the logging thread myself.
Software is so complex these days. The funny solution of doing static-allocated C with no threads and no logging isn't gonna work for me. You aren't going to have WebRTC in from-scratch C.
It's quite interesting to me the way that different "programming cultures" exist around debuggers.
If you grew up doing windows C++ development, looking at things in a debugger is your first step. You only resort to printing values if you can't immediately see what happened in the debugger.
A lot of other envioronment/language cultures are the opposite. Obviously both have their place, but I do feel like more people should use the debugger as the first step instead of the last.
For embedded applications, especially robotics, it tends not to be a great default because it stops the process, which tends to be bad for realtime control loops. That said, a complete hang is the situation where I absolutely would try to get a debugger attached and get a backtrace as one of the first things to try.
If you’re working in robotics and don’t have fully deterministic event based replay you need to find a new middleware.
I print first and get a feel for the code... Debuggers always slowed me down, and yes this was for c++
That auto flip back and forth between before and after is the most annoying thing I've seen since the blink tag was removed.
yeah I would like to read the code before it switches but nope
This kind of stuff is why devs doing safety critical work often painfully reinvent the wheel. Even if you’ve personally read the code yourself and think you understand it, there’s always some latent defect that arises from someone else’s bad assumptions.
Yeah. Actually, as I read it, I'm not sure if the robot is running WebRTC or not (In my comment I assumed it was)
But yeah it would be much more predictable for everyone if the robot didn't use WebRTC or the fancy logging library, and there was a WebRTC shim on the laptop to get the visuals into a browser.
The longer I think about that 10 ms control loop, the more I hope they aren't running any WebRTC thing on the same hardware cores as the control loop.
Man I miss embedded robotics work. So fun to write a control loop / algorithm and then see it play out in the real world. <robot crashes into wall> Whoops, guess we better review that routine...
The last photo appears to show the view out the author's office in Fort Mason. Didn't know they had offices there, that's quite a nice view of the Bay.
> But I will never call into a library I don't fully understand while holding a mutex again. Fool me once.
Nice sentiment and an admirable goal. Not really actionable in practice. Even if we disregard all userspace libraries out there, fully understanding the most frequently used syscalls is a monumental task already. You have to pick your battles in terms of understanding parts of a complex system.
Oof lol.
Sometimes I yearn for the Haskell or Idris style of programming where a dependency can do nothing harmful or stupid without me passing in permission.
Then I think about having to pass in thread handles and file handles to logging libraries. I don't know. It would be a cool option. There is probably a hack for `tracing` that would let me manage the logging thread myself.
Software is so complex these days. The funny solution of doing static-allocated C with no threads and no logging isn't gonna work for me. You aren't going to have WebRTC in from-scratch C.
Haskell has exceptions, so dependencies can still do plenty of harmful stuff ;)
[flagged]
Please don't do this here. If a post seems unfit for HN, please flag it and email us at hn@ycombinator.com so we can have a look.
Meh, I enjoyed reading it. I could be LLM-assisted but also I have a bunch of younger devs on my team who do actually write like this
You’re welcome to not like the article, and it can even be LLM-assisted, but that doesn’t mean it’s slop
You’re welcome to enjoy the slop, doesn’t change what it is
I stopped reading a couple paragraphs in because it felt so mechanical and AI generated. No personality to it.
You're absolutely right!