2 ms·

> Yet, the alternative, the rich man's debugger, introduces another tool into the project, something I try to avoid I would not call this introducing a tool in

> Yet, the alternative, the rich man's debugger, introduces another tool into the project, something I try to avoid I would not call this introducing a tool into the project. The debugger is not part of the project. I would call this utilizing the tools that are already built into your editor to make yourself more productive, instead of kneecapping yourself to only printing things. Talking to the main point of that paragraph - using a debugger and having hot reloads are not mutually exclusive. You can use hot reloads to rapidly see live changes, then use breakpoints to inspect state if required. Additionally, that a debugger "cannot change the implementation" is not universally true; this varies by language and debugger, see Erlang/Elixir. When people say things like this, it makes me think they simply lack the knowledge on how to effectively use a debugger, or they (or their language ecosystem) have not invested in good tooling.

molteanu 2y ago
One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project and that will result in a different style of developing software, tool-wise. One thing I saw happen in C development is, because the projects were so big and a reload after a code edit would also require a re-initialization phase to bring you back to that point in the code you were before you made the change, is that at one point you introduce the scripting language the debugger offers. Small files, at first, to set-up global state, to call the right functions, etc, since the project was meant to be debugged as a whole and not worked on in individual buildable and runnable code files. Like the classic maths library, for example, extracted into a different file and developed individually, without taking into account the rest of the project. That speeds up the development velocity, for example. And you can test it against locally available sets of data, like lists, matrices and what have you. Yes, I've used the Common Lisp debugger. But I also use JavaScript to pay the bills, so to speak. I've wrestled for months on end with the nodejs debugger and its integration with Emacs. Lost connections, wrong configs, random errors, etc. I still think the debugger is an extra tool, like a code editor is an extra tool, the finished product doesn't have any trace of what code editor you've used in the process. So if you can make your life easier without one, why not, there is no absolute requirement that you should use a debugger, for our example. Anyway, that is my reasoning. It might be wrong, it might be right, but it's taken from actual practice. Some people might have different experiences and that is fine, too.

molteanu 2y ago

One way to look at it is that, if I rely on a debugger and the style of development it promotes I will not try to make those reload times shorter for my project and that will result in a different style of developing software, tool-wise. One thing I saw happen in C development is, because the projects were so big and a reload after a code edit would also require a re-initialization phase to bring you back to that point in the code you were before you made the change, is that at one point you introduce the scripting language the debugger offers. Small files, at first, to set-up global state, to call the right functions, etc, since the project was meant to be debugged as a whole and not worked on in individual buildable and runnable code files. Like the classic maths library, for example, extracted into a different file and developed individually, without taking into account the rest of the project. That speeds up the development velocity, for example. And you can test it against locally available sets of data, like lists, matrices and what have you. Yes, I've used the Common Lisp debugger. But I also use JavaScript to pay the bills, so to speak. I've wrestled for months on end with the nodejs debugger and its integration with Emacs. Lost connections, wrong configs, random errors, etc. I still think the debugger is an extra tool, like a code editor is an extra tool, the finished product doesn't have any trace of what code editor you've used in the process. So if you can make your life easier without one, why not, there is no absolute requirement that you should use a debugger, for our example. Anyway, that is my reasoning. It might be wrong, it might be right, but it's taken from actual practice. Some people might have different experiences and that is fine, too.