7 ms·
I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost en
by olig15 8y ago
I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor.
Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph.
GUI's are definitely more than just bloat. Possibly not for what the author us developing, but there is definitely a use for IDEs/GUIs.
- dangom 8y agoWhat kind of navigation are you relying on that could not possibly work faster on a terminal? Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.
- lm28469 8y agoNavigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.
- TeMPOraL 8y agoI hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs. With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.
- NateEag 8y agoI've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol: https://code.visualstudio.com/api/extension-guides/debugger-extension https://code.visualstudio.com/api/extension-guides/debugger-... I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
- TeMPOraL 8y agoWow, thanks! And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true! [0] - https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode [1] - https://github.com/puremourning/vimspector https://github.com/puremourning/vimspector
- NateEag 8y agoAwesome - glad to be of assistance!
- flukus 8y ago> Navigation is rarely the limiting factor in development speed Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
- lm28469 8y ago> Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base. Isn't that a test coverage issue more than a navigation issue ? Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
- flukus 8y agoCode coverage is really high, legend has it that code coverage was tied to bonus a decade ago. The tests typically add more mental overhead than reduce it due to this. > Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage. It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.
- olig15 8y agoVisual Assist X is a VS plugin that everyone I know seems to have pre-installed wherever they work. It allows things like jump to file/symbol using a keyboard shortcut and fuzzy search. I imagine there's equivalent with vim, etc, but I also don't see how a terminal could be better/faster. Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.
- jdright 8y agoI'm in gamedev too, I basically do debugging for living with eventual actual development. Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio. I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive. I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.
- BurningFrog 8y agoIf anyone told you you can't navigate IDEs with a keyboard, they lied.
- pjc50 8y agoThis isn't Starcraft, very few developers are limited by their APM throughput through the UI.
- gambler 8y ago>This isn't Starcraft, very few developers are limited by their APM throughput through the UI. Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.
- TeMPOraL 8y ago> However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency. That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up. > You can become more efficient at low-level tasks by doing faster text editing. It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units. Also, for actual software engineering, nothing beats a pen and a piece of paper.
- kbutler 8y ago> Also, for actual software engineering, nothing beats a pen and a piece of paper. Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.
- TeMPOraL 8y agoPersonally, I use pen and paper (and a whiteboard) almost exclusively to draw and jot down very short notes. I do plenty of longer outlining when designing too (much more than drawing), and that happens in my text editor (Emacs, Org Mode).
- xemdetia 8y agoI 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.
- fxfan 8y agoThe 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?
- xemdetia 8y agoI 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.
- Scarbutt 8y agoSome game devs prefer to use VS with an external editor (as shown by Casey Muratori and Jonathan Blow in their live streams).
- pfranz 8y agoI watched Casey's earlier streams. The only thing he likes VS for is the debugger. He would say he's looked and hasn't found anything better, but expressed a strong desire to find something else. Since he started streaming he has moved (from emacs?) to I think http://4coder.net/ http://4coder.net/, which seems to have spawned from his audience. Similarly, a few debuggers have, too. https://remedybg.handmade.network/ https://remedybg.handmade.network/ https://lysa.handmade.network/ https://lysa.handmade.network/ but I think he still uses VS' debugger.
- dan00 8y ago> I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor. I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct renaming or finding all locations in code calling a certain function. I'm certainly not saying that it's as polished as 'Visual Studio', but it works pretty well. If tooling isn't baked into an IDE - which unfortunately is often the case - then pretty much every editor with some kind of extension mechanism can take advantage of it. > Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph. Yes, most visualization are text based. E.g. for showing the references for a function rtags uses the Quickfix-window of vim, which pretty much is just a list with one entry for every reference. I can now jump to every occurence in the list or even execute an operation on every reference, like I've removed the last parameter of the function call, and now I'm defining a vim substitution command for removing the last parameter and execute it on very item of the Quickfix-window. Sometimes visualizations are certainly helpful, but I never found them particular useful for software, because the more complex an application gets, the less useful the visualizations become. At some point you're less interested on the class level and more on the system level, but tools can't that easily detect what are the systems in an application. [1] https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags
- olig15 8y agoCode visualisations I agree aren’t that useful, and if I never have to look at UML style diagrams it’ll be too soon. The visualisations I’m talking about are mostly debugger tools. The parallel stacks view is life saving when you’re trying to figure out a deadlock. Having to scroll around this huge viewport with a cursor would just piss me off. I just can’t see how you could navigate a huge (10x screen width) node graph in a text terminal using vim style commands.
- dan00 8y ago
- 3pt14159 8y agoFor games, especially non-trivial ones, GUIs are fucking great. I couldn't possibly imagine writing game code without them. Anything else really visual, like CSS, and I need a GUI to feel productive. It's because the changes in the system are dynamic and cascade in unexpected ways. You make a box a little thinner and a heading flows to a new place and now the space between the heading and the image is off, etc. But I look at that very differently than an overall pronouncement on development. If I'm primarily interacting with data and transformations then GUIs are a disease that do nothing more than slow me down. Only when an analysis is truly one-time does Excel sometimes have an edge, but even there I really miss the adaptability of the terminal. The raw speed. The testability. The sheer maneuverability of it. The permanence.
- TeMPOraL 8y ago> Anything else really visual, like CSS, and I need a GUI to feel productive. It's because the changes in the system are dynamic and cascade in unexpected ways. You make a box a little thinner and a heading flows to a new place and now the space between the heading and the image is off, etc. Do you have some GUI for manipulating CSS with click&drag? Otherwise, isn't this use case handled by having an editor and a browser simultaneously open, and connected via live code reload. A web IDE can do this, but any other editor can do this too. This approach does work in gamedev too, but it's not popular - mainly because languages supporting REPL-driven development on live images are not popular in this sector. I agree though that there are tasks where GUIs are superior. But we're not talking about "regular" GUIs here, but domain-specific ones. Say, 3D editing. I can't imagine doing that from Emacs - the interface would heavily retard the feedback loop, in the same way GUIs slow you down when writing code. But then, Blender shows how one can apply Vim philosophy to 3D editing, resulting in a tool that embraces power users while still being GUI-driven.
- dwaltrip 8y agoSlight tangent, but may be interesting. I do a decent amount of CSS / HTML editing live in the chrome dev tools. I even sometimes move elements around by dragging them in the DOM tree UI. It can be a nice way of experimenting with UI design, as the feedback loop has less friction and can be much quicker, in some cases. One workflow is to write out an initial sketch of the HTML structure, with little to no CSS. The first round of the styling is then done in the dev tools, tweaking until it seems ok, then copying those styles from the inspector stylesheet into my code and saving, and then iterating further as necessary.
- gcb0 8y agoLearning a text editor plus ctags (etags) plus how to integrate your text editor to N compilers (syntastic) will make you equally proficient without fiddling with one IDE for each language. It sounds lame early in your career, but after a while, switching between C++, java, JavaScript (ok this one requires a little more involvement because the browser is the compiler of sorts), typescript, etc is very easy. When you switch languages/projects it is just a matter of opening a file with a different extension. All your text editor muscle memory is still there. If you use IDEs, today you are on a project that only builds in eclipse, tomorrow intellij, then you move back to C++ and have to use visualstudio... and you don't even know the Go To Line keyboard shortcut or Text Search...
- carlmr 8y agoThat's why I use VSCode. Not really terminal, but works on every language.
- gpderetta 8y agoOn the other hand I have worked on code bases in the 50M lines of code that would bring VS on its knees; people ended up just using it as a glorified text editor. Note I'm not knocking down on IDEs; as an Emacs user I would love reliable semantic indexing and navigation, but all the solutions that I have tried (rtags was the best) consume a lot of time and CPU indexing and switching branches often forces a rebuild. Currently, on a 1M lines code base I get around with projectile (which uses the project git as a file index) for file discovery and ag for brute force search, which at least on linux can search the codebase quickly.