How I'm still not using GUIs in 2019: A guide to the terminal

Re:How I'm still not using GUIs in 2019: A guide to the term... by xemdetia on Thursday February 28, 2019 @10:34AM (#19272008)

I feel most people that have used a command line workflow that need a GUI for debugging GDB's TUI is generally adequate even with large debugging projects. It's not a perfect 1:1 to the magic that Visual Studio gives you, but it is useful even with very large projects. Then again people who are terminal oriented usually use/look for other styles of debugging compared to people who have a solid IDE where the debugger just has more leverage. There's plenty of projects where all you are going to get from the field is a coredump, so building other methods to triage problems is more important: for instance a reliable replay system to rerun a trapped issue in a test environment.

If you are from gamedev land though everything is rigged around working with Visual Studio, so the debugging strategies/workflow I feel are more related to that than anything else. You also (generally) are debugging relatively locally to the problem as opposed to continents away. GDB and TUI stuff is wonderful if you are 6+ timezones away from the problem.

[ Parent | on HN ]

Re:How I'm still not using GUIs in 2019: A guide to the term... by fxfan on Thursday February 28, 2019 @11:05AM (#19272300)

The goal is not to stick to a particular style- it's to use the best tools for the job. why settle for gdb when there is VS Which is light years ahead. just like why use vscode when there is vim which is light speed faster?

[ Parent | on HN ]

Re:How I'm still not using GUIs in 2019: A guide to the term... by xemdetia on Thursday February 28, 2019 @12:00PM (#19272803)

I made no indication of 'settling for gdb,' you can use gdb in plenty of places where Visual Studio doesn't make any sense at all and provided some examples. If you haven't looked at the GDB TUI you might be surprised on how competent it is and having a well supported python interface to automate or enhance specific debugging for a project is pretty great. GDB hooking a runaway process in production that's using up a ton of resources is also much easier to do from shell than trying to coerce Visual Studio to do it.

It is also possible that the kind of things you are debugging also don't fit Visual Studio and better served by tools and things like WinDbg. This comes up when you are doing kernel driver debugging or really having to work with lots of symbol server shenanigans when you have kernel dumps from all sorts of random versions of Windows.

There's a lot of tools out there, and Visual Studio is often not the best tool for the job even for debugging. Settling for Visual Studio has its own set of compromises. As I mentioned for gamedev the Visual Studio experience is the current de facto standard for engines like unreal and as far as I am aware many of the SDK's for consoles, and all of the asset creation tooling from Maya, 3dsmax, etc. There are just other things that exist in the world than the primary pipeline that Visual Studio services with fantastic tech.

[ Parent | on HN ]

Re:How I'm still not using GUIs in 2019: A guide to the term... by btschaegg on Friday March 01, 2019 @02:10AM (#19278544)

While I agree on the "pick the right tool for the job" part, your comment makes me suspect that you have not had a look at GDB for very long (or at all).

I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.

[ Parent | on HN ]