5 ms·
As an ABAP developer looking to get back into the normal world I'm a little scared about how debugging will be like. After playing around with a bit of C and t
by nottheengineer 3y ago
As an ABAP developer looking to get back into the normal world I'm a little scared about how debugging will be like.
After playing around with a bit of C and trying gdb, I asked myself if this is really what people use. The display constantly breaks and there's not a lot of stuff to quickly walk through code and visualize what it's doing.
If there's something I don't understand within 15 seconds in ABAP, I fire up the debugger.
ABAP is a ridiculously complicated language that's been getting more and more features tacked on for 30 years and there are now about 1000 instructions in it. I firmly believe that there are some instructions in there that not a single person on earth understands, so it needs a good debugger to make it usable.
I jump into the debugger before even trying to look at the code because it shows me everything in the usual editor component and I can navigate through it as fast as I can read, so it's basically assisted reading.
I couldn't imagine doing anything like that with GDB.
Am I just too stupid to go fast and quickly get information in GDB? Is there a better alternative that I completely missed. Is non-ABAP code just more abstract to a point where debugging in general doesn't make much sense anymore?
Tying that back to the article: I agree that making all important assumptions explicit with assertions helps a lot with not shooting yourself in the foot. I can usually test the result and use my trusty debugger to find problems without assertions as well, but that requires remembering all my assumptions and knowing exactly what I want my code to do. If I write the assumptions down, I don't have to remember them and the next dev will be able to see what I thought. I also don't need to check if they still hold true since the runtime does that for me and hands a short dump to anyone who violates them.
- matthews2 3y ago> trying gdb, I asked myself if this is really what people use. The display constantly breaks and there's not a lot of stuff to quickly walk through code and visualize what it's doing gdb has a tui that can show you multiple panes of information at a time, e.g. the source code, disassembly, and registers. Other tools like Emacs, Eclipse, and CLion can use gdb as a backend and provide a friendlier interface on top.
- agumonkey 3y agoand it has a python interface so you can improve some stuff if needs be
- jiggawatts 3y ago“You should use a scripting language to make it into something tolerable” is the most damning review of a program you can give. It’s basically saying: “It’s great software, once you finish writing it yourself.”
- agumonkey 3y agoYou can see things that way, but it could also have the wrong UI layer and people wouldn't like it, here you have freedom. But I'm an emacs user so obviously that fits my psychology :)
- jiggawatts 3y agohttps://youtu.be/urcL86UpqZc?si=YF-t8NNzDyOmG3QQ https://youtu.be/urcL86UpqZc?si=YF-t8NNzDyOmG3QQ https://en.m.wikipedia.org/wiki/Stockholm_syndrome https://en.m.wikipedia.org/wiki/Stockholm_syndrome
- eloisius 3y agoSeer is a decent front end for gdb https://github.com/epasveer/seer https://github.com/epasveer/seer
- jcparkyn 3y agoIt sounds like you'd be much more comfortable in an IDE with a debugger. Any reason you're not using visual studio or clion etc? Even vscode should be able to give you a decent debugging experience if you're not doing anything too complicated.
- andersa 3y agoNo, gdb is not what people really use. There is probably a correlation between using it and having a grey beard. Here's an example of modern tools: https://twitter.com/EskilSteenberg/status/1695337268691571025 https://twitter.com/EskilSteenberg/status/169533726869157102... https://youtu.be/CxKujAuz2Vw https://youtu.be/CxKujAuz2Vw
- bear8642 3y agoYet to watch video, but does visual studio support macros in immediate or watch windows? That so far has been my frustration when not remote debugging linux vm, where it becomes a gdb front-end
- olig15 3y agoYes, you can do basic stuff directly in VS watch did windows, or for more advanced stuff you can use NatVis - https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/debugger/crea...
- wudangmonk 3y agoYou have to use gdb unless you are using windows unless there is another debugger for linux that I'm not aware of. Watched the video and you pretty much have everything mentioned in it with just an lsp, compiler flags and a command that runs your program with a debugger. The only example that wasn't caught with just that was the p[3] example but that was caught by valgrind which is also something I have a command setup for. Really the only thing I was actually jealous of was at the very end of the video and it wasn't the hot reloading stuff, that's easy if you split your programs from the platform its running on. The ONLY thing was that the vs debugger lets you explore variables with a visual interface instead of having to write commands to do it. I've used it on windows and even though its usually busted and variables do not always update they sometimes do. At the very least just viewing the hiearchy of the structure is useful so that you can easily add the value you want to the watch window which usually does work.
- 3y ago
- dannymi 3y ago>After playing around with a bit of C and trying gdb, I asked myself if this is really what people use. The display constantly breaks and there's not a lot of stuff to quickly walk through code and visualize what it's doing. >I couldn't imagine doing anything like that with GDB. Am I just too stupid to go fast and quickly get information in GDB? Is there a better alternative that I completely missed. Is non-ABAP code just more abstract to a point where debugging in general doesn't make much sense anymore? As someone doing programming on unix since 2001, hell no, that's not what I use (directly), for the reasons you say. I mean gdb in the backend is okay. And gdb actually specifies Gdb/MI, a protocol to remote-control it. You can also use gdb directly locally this way, and then it sucks less. But nowadays I just use the IntelliJ IDEA IDE. I wrote https://github.com/daym/idea-native2-debugger https://github.com/daym/idea-native2-debugger which is a native debugger plugin (that uses gdb in the back) for IntelliJ IDEA Community Edition. You can also use CLion (requires you to subscribe--but it's totally awesome and has a lot more features) and that uses lldb in the back instead of gdb. Some of my friends use emacs with gdb debug thing. Seems to work OK too. Earlier in life I used https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/ a lot--but nowadays I just stay in IDEA. After you got used to IDEA, using anything else is like riding a kick-scooter after you got used to a motorcycle. emacs is also good as an IDE--but for me it just doesn't work well enough--and I'm not interested in having to maintain my editor configuration like an extra software project. You can also extend gdb with python plugins that make your variable printout nicer and/or more complete. It's very good.