Hacker News Reader

Comment by dpbriggs | Hacker News Reader

I highly recommend checking out his YouTube channel [0]. He's an _incredibly_ thoughtful person and provides good lessons in staying focused and keeping scope down.

I consider him a mentor and his approach to software is something I really resonate with. He has a keen focus on software quality but understands he can't make everything perfect in one sitting. This approach helped me get away from decision paralysis in my projects and at work.

This isn't even mentioning how much I've learned about software in general from his videos. Whether it's debugging kernel bootstrap assembly, porting doom, writing a live feedback GUI editor, implementing syscalls, to messing around with the dynamic loader. He's really got a video for it all.

And he tackles each video with such clarity and careful consideration. I really can't speak higher of the man.

[0] https://www.youtube.com/c/AndreasKling/videos

View on HN

Nice tip, I started with something short - writing a screenshot utility:

https://youtu.be/3BF-vUts3ws

Ed: i really enjoyed the video, but I feel it could have been even better (and shorter) if he used a proper debugger for the second part. But I don't know if that is available in the os.

The more I use a debugger, the more I realize I should use a debugger, and the earlier I should use a debugger.

Advice/directions to start early with a debugger might be the best part of Zed Shaws "Learn C the hard way". Eg:

https://github.com/zedshaw/learn-c-the-hard-way-lectures/blo...

(not a full featured chapter, but note that this is fairly early - exercise 4).

On a related note, it appears Shaw doesn't use the/any debugger at all in the ruby book, which is frankly quite crazy - ruby has great debuggers and repl. But that's a digression.

For a blog post that illustrate how one might do "debug driven" (or "debug first) development, see: https://nikhilism.com/post/2021/experiencing-smalltalk/

(Smalltalk and lisp does this very well - you can't AFAIK quite go that far with c++, but it's what all systems should aspire to, as a baseline (70s debug experience) ).

Debuggers are a great learning tool, but I’ve found they’re useless when diagnosing production issues. At best, you’re using C/C++ and after the crash, you get a minidump from a customer/server.

Eventually, I learned to write code that was so obviously correct and had such good error messages that I haven’t needed to use a debugger in a long time.

In fact, I don’t even know how to invoke a debugger for most languages I know.

Edit: The other good trick is to write your code so that it keeps enough state on the heap to extract useful information from core dumps. For instance, you can keep global references to lists of state that helps track issues down, and make sure they work as expected in -O3 builds. I have definitely played that game in the past.

They are only useless when the production is built with stacks that don't support stuff like Application Insights, ETW or JFR/JMX.

Reminds me of the time needed to write an application that would be particularly hard to test (was critical, handled distributed state). Managed to write it so obviously correct, that I couldn't think of anything to test before releasing the clustered version. I only ever managed to find 2 bugs, both of which were silly and unimportant.

During development, I did use REPL to run/evaluate most of the functions, on 1-2 inputs, and found a couple of silly, immediately evident bugs. Development took a couple of days, testing was about as mentioned and I really didn't want to debug.

These days, I'm amazed how people can stand to write anything at all complicated in haphazard ways, but then get to spend similar or greater time playing whack-a-mole with bugs to maybe get most of the important bugs.

Yes, good tooling can make debuggers usable. OTOH, if you need debuggers, I would consider it a shortcoming of the programming methods/structures/styles and usually even entire stacks, where debugging is practically necessary.

Debuggers aren't quite as useful with C++ indeed. But that's a good reason to use C++ less. I diagnose issues drastically faster with a debugger all the time. Often I'll write a unit test that reveals a bug, but just looking at the code doesn't quite reveal where the bug is. But sticking a few breakpoints in the right places and examining the data structures directly makes it really obvious.

Eventually, I learned to write code that was so obviously correct and had such good error messages that I haven’t needed to use a debugger in a long time.

Nobody needs to use a debugger, just like nobody needs to use most tools. They're just very helpful when they work correctly and are used correctly.

I've spent much of my career debugging C++ in rather large code bases, after inserting said bugs myself usually. If you have a set if inputs that make the problem reproducible, a debugger usually makes finding the error trivial. The only times it has taken a while is when someone (not me in this case) has done something horrible with unsafe casts, ignoring data hiding to violate a class invariant, or memcpy, or... So basically old style C. Building for release with debug info helps. Debugging with a debug build is easier sometimes, but sometimes it masks or in rare cases, creates bugs.

Andreas has made a couple of videos about why he purposefully doesn’t use a debugger (which I can’t find now) but it’s related to how he prefers to focus on a whole programs behavior and work out what’s wrong from his understanding of what it’s doing by reading the source and logs.

Incidentally Linus doesn’t use a debugger either.

Interesting. To each his own, of course - but in this one particular video, the print-debugging he does, might have been quicker and easier in a debugger (or perhaps with a core dump?). Then again, maybe not in c++.

I admit, I work mostly with ruby these days, which of course has a quite decent repl and debug experience (still whish it had full smalltalk style crash(missing method) > debugger > fix/add method > resume). Apparently someone did try that with python/rpython in the "topaz" ruby vm, but it seems abandoned. Maybe we'll get it for more languages via graal vm at some point?).

I'm used to fix and understand issues in big C++ codebases, and while eventually use a debugger, i feel that printing while passing is much better because you can see the bigger picture.

Is like putting a bell in each step so when the running bunny passes over it rings.

Later you see every place the bunny passes over and what it did, i feel its much faster to grasp and understand whats happening.

Debugging feels very slow, and i mostly use it to analyze core dumps. Also in multi-threaded/multi-process code it can change the result/output as other parts (like processes) might still run detached from the debugged thread.

Anyway, i don't like forced rules, you should use whatever works the best for you, because in the end we all have a intelligence to analyze things for our particular scenario much better than someone with a generalized point of view can.

We should always be open to learn and to see other perspectives but once we are settled we should also learn to trust ourselves and bend the "rules" when there's a need.

Multiple threads can change behavior, especially if it is a thread safety problem you are debugging. Debugging takes time mostly to reproduce the bug. If you had rr I think it might be as fast as using good logs.

That's somewhat true, it changes to me when rr works and so you can basically do print where you want and going back if you forgot something.

There's a scene in Netflix's The Queen's Gambit where two skilled Chess players are driving to New York. During the monotonous drive, they decide to play Chess. But they do so entirely verbally, no board involved as they are skilled and are able to hold the boards state within their heads.

The best way to explain how I debug is through this metaphor. I don't need the debugger to know what's happening. I know exactly what's happening with my code. The only reason I use print statements is to know what's being returned to me through other people's black boxes. I don't want to be limited to one black box query per run, so I can add multiple statements exactly where I think the black box is being weird.

I use a debugger to step into libraries and other people’s code regularly. Irrespective of whether I can or cannot hold the logic in my end I don’t find it particularly useful.

I’m not sure why a useful utility is so polarising. It’s a helpful aid - like a chisel in a carpenter’s toolbox.

> Smalltalk and lisp does this very well - you can't AFAIK quite go that far with c++, but it's what all systems should aspire to, as a baseline (70s debug experience)

Actually that was were we were going to before Java took over the stage.

"Lucid Energize Demo VHS 1993"- https://www.youtube.com/watch?v=pQQTScuApWk

https://dreamsongs.com/Cadillac.html

IBM also built on those ideas for the 4th release of Visual Age for C++.

http://www.edm2.com/0704/vacpp4/vacpp4.html

https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir...

Yes. I did come across:

https://github.com/topazproject/topaz

From: "When a Mouse Eats a Python: Smalltalk-style Development for Python and Ruby" https://2017.programming-conference.org/details/MoreVMs-2017...

But it seems abandoned?

I guess maybe maglev ruby on the gemstone platform does move the needle a bit closer:

http://maglev.github.io/docs/persistent_code.html

> I guess maybe maglev ruby on the gemstone platform does move the needle a bit closer:

For Ruby, "pry" gets you at least some of the way there with MRI. It's nowhere near the "full experience", but it has taken a lot of inspiration from Smalltalk, and it's just an entirely different world compared to IRB.

I should clarify; I specifically meant being able to do stuff like write a high level sketch of a module, then simply run it, and implement missing methods and classes as you go. Similar to writing a red/failing test - then filling in functionality.

I suspect a image-like (as in lisp/smalltalk image) view of the code is needed for this to work well (hence the link to "persistent code" for maglev/gemstone).

That said, I do use pry/byebug a lot - but I there might very well be features I'm not aware of.

Pry does allow that with some caution. You can dip into files from the pry prompt ("edit <methodname>" opens the right file at the start of the method definition) to add methods and reload a class ("reload-code" or "reload-method"), and if you want to you can relatively easily rig things up so you're thrown into a pry prompt on method missing, implement the missing method, and reload the relevant file and retry the call.

Though I'll usually have a "boot" file that loads all pre-requisites and just call functionality from a pry prompt and edit/reload as needed rather than try to continue from a method missing or exception.

This is why many IDEs have the workspace concept, as it allows to create a metadata database with the information that would otherwise be part of the image.

Oh, there's apparently a repl for clang/c++: "cling"

http://code-ballads.net/read-eval-print-loop-repl-in-c/

https://code-ballads.net/generated-notebooks/cpp/repl_cling/...

https://github.com/root-project/cling

https://blog.jupyter.org/interactive-workflows-for-c-with-ju...

There's been some discussion on hn before, but I couldn't find anything particularly recent (or interesting tbh).

Then there is of course rr, as seen recently on hn:

"Instant replay: Debugging C and C++ programs with rr" https://news.ycombinator.com/item?id=27034588

And I also came across "inspector"- which unfortunately appears to be abandoned?

"Inspector - A drop-anywhere C++ Repl" https://news.ycombinator.com/item?id=16360738

Relevant: his youtube video on why he does not use a debugger https://www.youtube.com/watch?v=epcaK_bhWWA&t=404s

Andreas doesn’t prefer using debuggers. He’s actually touched on the subject a few times in his videos.

+1 on this! The game porting series is what got me into watching his videos.

Normally, I can't focus longer than 5 minutes on programming videos, but Andreas's are fantastic to watch! Porting Diablo was just inspiring to see, missing a syscall? No worries, we'll just implement it!

I don‘t know much about OS development or C++ but I still watch his videos because of his thoughts on life as a software engineer.

Any specific video you would recommend that highlights his thoughts on life as a software engineer?

Not the person you're replying too, but I think you might find this video [0] interesting. He's describing his motivations and worries around making a web browser for SerenityOS.

A quote from that video (3:25) really stuck with me. He describes how he saw people joking online that the web-standards are so insane that it's impossible to build a new web-browser:

"The way I respond to that type of energy is to just really want show people that this is silly, not too complicated... mythologizing something that humans have done and humans will do again"

He clarified with a reflection on the hubris of it - new browsers can be made; not impossible; just takes an incredible amount of work taken a step at a time [1]. I really respect that.

Not exactly his thoughts on life _as_ a software engineer, but contains some thoughts on software engineering.

[0] https://youtu.be/-YlVex4nbfw

[1] http://serenityos.org/

These are high praises and more than enough impetus to watch Andreas’ videos and check out SerenityOS. Thank you, all.

From tfa:

> With no drugs or other vices to pass the time, the days seemed impossibly long.

Is honest, resonant, and bodes well, but it’ll be work to convince myself this [0] is more like ol’ skool X than ~WinNT circa 2000 — it’s not making me serene atm.

[0] https://awesomekling.github.io/assets/writing-this-post.png

I am watching this video now.

https://www.youtube.com/watch?v=KehSJ_fdTxU

It has a tour of features for SerenityOS... They have built an impressive amount of stuff at an incredibly high pace.

Totally tangential, but I just checked out one of his "Cat Talks", looks like he's basically casting from his bed. BUT the sound was so well recorded I had to actually check to make sure the sound was coming from my headphones and not the computer or someone in the room even. Wow, really would love to read about his recording set up that he can do that from his bed.

Reply on news.ycombinator.com