[godelski]

  > Build as a library so other people can build other interesting things as well 

I LOVE this!

I firmly believe so much tech has gone to shit because things are no longer hackable. We say "move fast and break things" but we try so hard to prevent that that when we do break things we just create bigger messes and debt, so no one cleans it up. It seems slower to write hackable code but that's in the moment. In the long run it is much faster. Not to mention you get added benefits of others being able to contribute more easily with a lower likelihood of actually breaking shit.

[Analemma_]

Is gdb another thing like gcc where the un-hackability and un-extendability was a deliberate choice by rms to ensure nobody would ever build proprietary toolchains on top of it?

[debatem1]

I don't know if it was deliberate, but writing code that interfaces with GDB is unpleasant enough that I opted to build our debugger-like tooling in eBPF + pyelftools instead.

[dooglius]

No, GDB has a pretty good Python extension framework

[mort96]

That's not comparable. That lets you extend GDB with your own additions. Having the debugger work as a library means being able to incorporate the debugger's functionality into other systems.

[junon]

Yes, this. I write a lot of my own GDB tooling for debugging my kernel.

[godelski]

gdb is a bit old and my comment is really more about building things in general.

You should always make things hackable, not just for others, but for you. One truth to coding is that the final thing will never end up where you think it will. So if you don't make your code flexible (i.e. hackable) then you're going to keep breaking it while fixing it. Things will continue to be patches and quick fixes. Nothing is more permanent than a temporary fix that works.

Truthfully, this is part of the unix philosophy. Make your programs small and integratable. The strategy is not to be finished, because there is no end, the strategy is to be adaptable, because there is no end.