Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasfcosta.com

Post reply on HN
Print view View original

91–100 of 248 posts

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

#91

Post by TeMPOraL »

gambler wrote: post #80
pjc50 wrote: post #69

Earlier quoted context omitted.

This isn't Starcraft, very few developers are limited by their APM throughput through the UI.

>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.

> 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.

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

#92

Post by jdright »

olig15 wrote: post #46
dangom wrote: post #36

Earlier quoted context omitted.

What 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.

Visual 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.

I'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.

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

#93

Post by estsauver »

cphoover wrote: post #54
noxToken wrote: post #42

Earlier quoted context omitted.

I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs. This isn't to say that there aren't terminal utils that aren't powerful enough to handle such a project. But being able to Ctrl + Alt + LMB an interface and being taken to the implementation (or shown a list of all implementing classes) or pulling a gr…

> "I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs." I think this for me is the gist of the problem... A lot of corporations prefer these large monolithic codebases, with a thousand different interfaces and abstract classes. I think this is a mistake in design, and prefer simple applications with sim…

I run a complex business. I can guarantee you that I would really prefer if it was a simple business with simple interfaces, dependencies and rules :)

It really depends on how much resources your company has, what you're trying to do/prove/show, and how long you have to do it. Google gets idolized for their software, but the reason they can have so much perfection in their software is the amount of money their core business throws off, not the other way around.

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

#94

Post by going_to_800 »

Used Atom and other IDEs for 5 years. 3 years ago switched to vim + tmux and love it. I'm very productive with my setup and I can't imaging going back.

I also love that I can git clone my dotfiles + an install script and I have my full dev environment on any machine in 2 minutes.

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

#95

Post by TeMPOraL »

lm28469 wrote: post #45
dangom wrote: post #36

Earlier quoted context omitted.

What 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.

Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.

I 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.

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

#96

Post by FerretFred »

Spearchucker wrote: post #64

The world moved from CLIs to GUIs. Guis have not only persisted, they've improved. If someone insists on using a CLI and nothing else, after all these years of the world having moved to GUIs, I wonder what prejudice is behind it. How, reasonably, can all these tools beat a thing like Visual Studio? Must limit job opportinities too...?

> If someone insists on using a CLI and nothing else, after all these years of the world having moved to GUIs, I wonder what prejudice is behind it.

No prejudice.. I run a dev/comms box on a Raspberry Pi Zero W that has 512Mb of RAM. I originally set it up with a lightweight GUI which would actually start up but was pointless to try and use for anything. Reverting back to CLI meant that I could now "do stuff", and I rarely use more than 70Mb memory even with tmux running.

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

#97

Post by gambler »

What are the chances that teletype simulation is the best possible way to interact with computers? This is what command line emulates:

https://www.youtube.com/watch?v=AIWZ_pbLYqQ

Yes, this was way better than punch-cards. But it was incremental and used completely arbitrary technology simply because it was available from somewhere else.

UI as a concept was poisoned by Windows and its shitty derivatives.

Like, there is no real reason you can't compose stuff when using GUIs. In fact, it should be easier than pipelining commands.

There is no real reason the keyboard should be crippled by working in a GUI. It should be easier to learn commands. (But have you noticed that we still don't have dedicated keys for cut, copy, pate, undo and redo? The most common operations present in almost all applications. But we have a Windows key and caps lock.)

Despite what people think, UI is still mostly unexplored territory with tons of potential for improvement.

BTW, my favorite code editor isn't an IDE. It's LINQPad, because it gives me immediate feedback without much noise. Going from it back to REPLs feels like a downgrade.

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

#98

Post by xemdetia »

fxfan wrote: post #56
xemdetia wrote: post #37

Earlier quoted context omitted.

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…

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?

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.

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

#99

Post by Blaiz0r »

I love using nvim as my daily editor, but one thing I get from posts like this are that the authors rarely have to develop any kind of UI themselves, this author states they work in JS, but it looks like it's backend node work.

I'd be interested to hear of any other stories from developers that use both terminal for almost everything but also have to have a web browser open for development.

The best I do is have my browser and my terminal open 50/50 on one screen, but this isn't ideal, just a compromise.

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

#100

Post by jolmg »

da_chicken wrote: post #48

> GUIs are bloatware. This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program. While that can certainly be done -- the -? and --h…

It's common to think that the goal of UI design is always about being as intuitive as possible, to minimize potential learning curves until they're basically non-existent. I don't think that's the only worthy goal, though.

Intuitiveness and power are often opposing goals. You often see a way to make an interface more powerful, let the user work more effectively and/or efficiently, at the cost of intuitiveness and having to increase a learning curve.

In your last paragraph, I feel you mean to imply that vi failed in its UI design, but I think it's one of if not THE best UI design I've ever come across. There was a learning curve, yes, but I don't care, it was well worth it given how much it's improved my efficiency of anything text-related in my work. The cherry on top is that shells and any readline-based REPLs implement vi keybindings, so learning how to use its UI has become tremendous leverage, since this means that vi-keybindings become the new main text-editing UI convention system-wide.

I don't understand your point about the web-browser. You say how great it is that its UI has not changed much (although I think it has) in so many years, then you say how bad it is that vi's UI has not changed much in so many years. Also, web-browsing is mostly about text, so I can't see it being much of a contrast with your earlier point about terminals being better for text things.

About having conventions, CLIs probably have more conventions than GUIs, so I don't really get that point either. It's not just about --help, the concept of options, of long ones, and short ones, and them having arguments and all that are conventions. vi and emacs keybindings in many CLI programs are also conventions. If having conventions is great, I think CLI has GUI beat.

Post reply on HN