4 ms·

In 2000-2006 I implemented garbage collectors in C on Linux. I used Emacs and GDB, and likely also DDD and GDB from within Emacs. I don't think there was anyt

In 2000-2006 I implemented garbage collectors in C on Linux. I used Emacs and GDB, and likely also DDD and GDB from within Emacs. I don't think there was anything better back then. It's been a long time since I used C, but I wonder whether VSCode really gives a better experience than Emacs. Nowadays you can use Emacs with an LSP server, which is likely also what VSCode is doing. And there are Emacs distributions like Spacemacs and Doom Emacs that take away the configuration pain. As someone who has used Emacs for a very long time, I'd be tempted more into looking at CLion from JetBrains instead. Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause. But that might just be my background with garbage collectors: in that case the sympton only becomes visible a long time after the actual problem occurred. The sympton was often dereferencing a pointer that failed, while the problem was the garbage collector writing a wrong value for that pointer in one of the earlier garbage collections. And that led to a lot of assertions in the code to catch problems early on.

omegabravo 4y ago
Language Server Protocol (LSP) came from the VSCode team.
alkonaut 4y ago
> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. I don’t understand this sentiment about “modern” (interactive, user friendly) debuggers. Simply because you have a tool doesn’t mean you have to skip the step of trying to understand the code. Is the suggestion seriously to avoid having tools that are objectively better because there may be a temptation to use them too early, whereas having only more primitive tools would do better? I have seen the same argument about syntax highlighting. That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly…
- BlargMcLarg 4y ago
  >That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly… On the contrary, I get quite annoyed losing track of indents and scoping. VSCode finally adding colored brackets has been a blessing in navigating legacy code with way too much nesting in the face of developers still unable to keep their code from scrolling horizontally and dividing methods / using different paradigms to prevent overnesting. Also helps to just not have to spend the limited amount of focus on things that an IDE can cover for you. Programming has become far more complicated (no, not complex) in many ways, and we as a species haven't magically gotten a lot better at understanding it while we seem awfully good at writing things even more complicated.
- noisy_boy 4y ago
  > I have seen the same argument about syntax highlighting. That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly… The amount of times color change has indicated syntax error to me makes it a no brainer. Sure, some systems may have an older editor that doesn't have color highlighting, but that's a rare scenario for me. I'm not going to give up the huge benifit just to "train" my mind for such rare cases.
- rvdginste 4y ago
  > Simply because you have a tool doesn’t mean you have to skip the step of trying to understand the code. Exactly. Maybe that was not clear from my comment, but my point is basically that using the most fancy tools is not gonna help a lot when you don't start with getting an understanding of the code.
deleted 4y ago
[deleted]
badsectoracula 4y ago
> In 2000-2006 I implemented garbage collectors in C on Linux. I used Emacs and GDB, and likely also DDD and GDB from within Emacs. I don't think there was anything better back then. Around 2003-2004 or so i used Anjuta on Linux which provided a Visual Studio-like environment with integrated debugger, C++ code completion, project management, etc. I used it for all my C and C++ development as it was both fast and featureful. Sadly the developers decided to rewrite some core part (probably my first brush with the GNOME approach to software engineering) and the rewrite was so buggy that crashed pretty much all the time, forcing me to move elsewhere.
robenkleene 4y ago
> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. > And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause. Did you watch the video? He spends a significant amount of time talking specifically about why he thinks what you are saying here is misguided.
- rvdginste 4y ago
  I actually did watch the video. Don't understand me wrong: I don't have anything against a good IDE and a good debugger. I currently work with C# and use Rider. Still, for me personally, I need to study the code and know what to expect before I start the debugger. It makes the debugging session a lot more useful and efficient. And, actually, like John Carmack said that other people told him, in a way, I do "replay" the code in my head while reading it. And a lot of times, I already figure out what the error is when reading the code. But, I will often still debug the code to verify that what I'm thinking is true: I do trust the debugger more than my brain. Aside from that he also mentioned that nowadays software systems tend to be complex and too big to completely fit into one's mind. I agree with that, but IDEs make it easier to isolate the code in the system that is relevant for the issue at hand: you can find the call sites of a method, the use of results, the origin of input values and so on. I don't know how good IDEs are currently for C/C++, but those things are standard for C# and Java. And with those tools, it really is not that hard to get a rough view on where and how a piece of code is used in a big system. Obviously, this will be easier in a well-designed system than in a spaghetti-code system. It is important to know all the contexts in which the code you are debugging is used. Often people are focused on the one specific context in which a user saw a bug, and they focus on that, start a debugging session for that, fix the code for that and break the usage in the other context... because they do not take the time to read and understand the code. And that is also where unit/integration tests come into play. So, nothing against the use of good IDEs and debuggers, but always be sure to understand the code you are changing.

omegabravo 4y ago

Language Server Protocol (LSP) came from the VSCode team.

alkonaut 4y ago

> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. I don’t understand this sentiment about “modern” (interactive, user friendly) debuggers. Simply because you have a tool doesn’t mean you have to skip the step of trying to understand the code. Is the suggestion seriously to avoid having tools that are objectively better because there may be a temptation to use them too early, whereas having only more primitive tools would do better? I have seen the same argument about syntax highlighting. That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly…

BlargMcLarg 4y ago
>That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly… On the contrary, I get quite annoyed losing track of indents and scoping. VSCode finally adding colored brackets has been a blessing in navigating legacy code with way too much nesting in the face of developers still unable to keep their code from scrolling horizontally and dividing methods / using different paradigms to prevent overnesting. Also helps to just not have to spend the limited amount of focus on things that an IDE can cover for you. Programming has become far more complicated (no, not complex) in many ways, and we as a species haven't magically gotten a lot better at understanding it while we seem awfully good at writing things even more complicated.
noisy_boy 4y ago
> I have seen the same argument about syntax highlighting. That pretty colors makes for sloppy code reading and monochrome text means you read slower and thus more thoroughly… The amount of times color change has indicated syntax error to me makes it a no brainer. Sure, some systems may have an older editor that doesn't have color highlighting, but that's a rare scenario for me. I'm not going to give up the huge benifit just to "train" my mind for such rare cases.
rvdginste 4y ago
> Simply because you have a tool doesn’t mean you have to skip the step of trying to understand the code. Exactly. Maybe that was not clear from my comment, but my point is basically that using the most fancy tools is not gonna help a lot when you don't start with getting an understanding of the code.

deleted 4y ago

[deleted]

badsectoracula 4y ago

> In 2000-2006 I implemented garbage collectors in C on Linux. I used Emacs and GDB, and likely also DDD and GDB from within Emacs. I don't think there was anything better back then. Around 2003-2004 or so i used Anjuta on Linux which provided a Visual Studio-like environment with integrated debugger, C++ code completion, project management, etc. I used it for all my C and C++ development as it was both fast and featureful. Sadly the developers decided to rewrite some core part (probably my first brush with the GNOME approach to software engineering) and the rewrite was so buggy that crashed pretty much all the time, forcing me to move elsewhere.

robenkleene 4y ago

> Regarding the comment about the debugging. For me personally, I always take the time to study the code first before I start debugging. A lot of times I already find the problem by just reading the code and even if that is not the case, I have a much better understanding about how the code is supposed to behave and that makes the debugging session a lot more useful. > And I say that because I have the impression that it is common for developers to dive straight into a debugging session without a good understanding of what the code is doing or trying to do. It's like they see the sympton and want to fix the sympton instead of fixing the core cause. Did you watch the video? He spends a significant amount of time talking specifically about why he thinks what you are saying here is misguided.

rvdginste 4y ago
I actually did watch the video. Don't understand me wrong: I don't have anything against a good IDE and a good debugger. I currently work with C# and use Rider. Still, for me personally, I need to study the code and know what to expect before I start the debugger. It makes the debugging session a lot more useful and efficient. And, actually, like John Carmack said that other people told him, in a way, I do "replay" the code in my head while reading it. And a lot of times, I already figure out what the error is when reading the code. But, I will often still debug the code to verify that what I'm thinking is true: I do trust the debugger more than my brain. Aside from that he also mentioned that nowadays software systems tend to be complex and too big to completely fit into one's mind. I agree with that, but IDEs make it easier to isolate the code in the system that is relevant for the issue at hand: you can find the call sites of a method, the use of results, the origin of input values and so on. I don't know how good IDEs are currently for C/C++, but those things are standard for C# and Java. And with those tools, it really is not that hard to get a rough view on where and how a piece of code is used in a big system. Obviously, this will be easier in a well-designed system than in a spaghetti-code system. It is important to know all the contexts in which the code you are debugging is used. Often people are focused on the one specific context in which a user saw a bug, and they focus on that, start a debugging session for that, fix the code for that and break the usage in the other context... because they do not take the time to read and understand the code. And that is also where unit/integration tests come into play. So, nothing against the use of good IDEs and debuggers, but always be sure to understand the code you are changing.