over time I’ve been growing accustomed to knowing my dependencies. after all, how can I depend on some code functioning correctly, if I don’t even know how it works, or what to do to repair bugs in it? or even where to go to customize it to my liking?
2024-04-09 it’s largely annoying to me that compilers ship without their source code, nor do they ship with debug symbols. it would be great if whenever
rustccrashes on me while incremental-compiling the treehouse (and it does so pretty often), I was able to catch the crash with a debugger and step through the code to see what happened.2024-04-09 I wonder what the world could have been, had we been compiling and optimizing software on users’ computers rather than downloading ready-to-use, but opaque binaries.
2024-04-09 I imagine a world where I can tell the computer “I’d like to debug this crash” after the compiler crashes, and it will download the relevant sources and let me single-step through the code to see what happened.
2024-04-09 and then I could edit the source code and submit the patch right where I’m standing rather than having to go through complicated and lengthy processes of cloning repositories, bootstrapping, reproducing, and such. imagine fixing compiler bugs on real codebases rather than having to come up with isolated, reproducible examples first.
2024-04-09
package managers like Cargo make using someone’s code incredibly easy, and that’s really cool. we should be encouraged to share reliable, well-tested code instead of reinventing half-baked solutions every time we need a thing.
2024-04-09 but I think at the same time they make understanding someone else’s code kind of an afterthought.
2024-04-09 to integrate a library into your C++ project you usually have to browse through their CMake build files to figure out how they name their build targets. and while doing that, through cursory glances at
CMakeLists.txt, you gain knowledge of what knobs can be tweaked in the project, how it builds. you may even stumble upon a list of source files, which can give you clues as to the underlying architecture.while this can hardly be called understanding the code, at least it gives you a peek into how it’s structured.
2024-04-09
Cargo on the other hand makes it needlessly difficult to poke at someone’s code.
2024-04-09 Cargo treats dependencies as immutable, which means that a given version of a package only compiles once per your project. you can’t go poking at the package’s files for debugging purposes - you can’t insert
dbg!(x)expressions where you need them, which is really annoying. the only way I know of is to use overrides, but compared to editing an already vendored dependency, those are quite cumbersome to set up…2024-04-09 then you need to edit
Cargo.tomlto override the dependency2024-04-09 and don’t forget to revert the changes to
Cargo.tomlonce you’re done. unlike editing a vendored dependency, which will appear under a very visible path in Git, it’s pretty easy to forget to check yourCargo.tomldiff before staging/committing changes. I mean, I edit myCargo.tomlall the time, adding in libaries and stuff. so why would I look at every single change?2024-04-09
most of the time not knowing your software is largely fine - not everyone has the time to deeply inspect a piece of software, deciphering functions, consulting manuals, asking the authors (when possible.)
2024-04-09 what I’m saying is that we should be encouraging more engineering practices and tools that enable us to inspect and poke at our dependencies when we need it.
2024-04-09 don’t fear code; respect it like it’s your Holy Mountain. a place to tinker with stuff, and occasionally wreak havoc, anger the fuck out of the gods, and let them kick your ass with an
EXCEPTION_ACCESS_VIOLATIONor anotherSegmentation fault (core dumped). and then Steve kills you but you start another run anyways because this game of chasing bugs and perpetually improving software is just too damn addicting2024-04-09