I haven't really been programming for a while until recently and this is kind of what I'm doing. I'm using cloud 9 and usually use vi in one of the windows/tabs for editing.

I'm no expert but I feel confident in saying that making explicit attempts to save "brain space" because it is "limited" is not a valid concept in regards to the human brain.

I also don?t think we?re making an apples-to-apples comparison. There?s a lot of stuff that can be done on a command line that can?t be done in a GUI or that would be just as hard to figure out in a GUI.

Yeah, gui didn't win in popularity because it was strictly better than cli (like suzzer claims). It won because its good enough at the simple stuff and that's what most people need.

For power users there are many instances where cli is better. And it really isn't that hard, you just need to use it regularly and it becomes muscle memory. If you're doing something infrequently then google finds the answer in 2 seconds, no memorisation needed.

E.g. I use git in cmd line exclusively. When I go to a junior devs machine and try to help them with a git issue they show me sourcetree and I'm completely lost. So the barrier is there for gui as well. You need to build a mental model and that takes time.

If you?re looking for the search string in the target that seems pretty normal. Although so does saying I?m looking in my target for this search string. Thanks Obama...

We live in the golden age! You can use the google for all the Linux stuff you used to have to have linear feet of reference books for! The best excuse for multiple monitors is so you can have the google on one and a terminal on the other!

It actually is. There was a study done on London cabbies and they found the amount of memorization required for the job pushed out other stuff. I doubt however that the amount of memorization required for Unix is significant in that regard.

I just don't like having to memorize stuff and think (more or less) self-evident stuff is a superior model. Trying to remember things cold feels painful to me, which is why I struggle so much with Spanish. Having a visual cue makes it a million times easier.

**** R in the ear for returning part of the failing line of code but no line number.

Do you think Spanish people feel the same? Nothing in any CLI or GUI is "self evident", just like English is not self evident to humans and Spanish is not always a struggle. You have learned GUI at an early(er) age (presumably the specific weirdness of Mac GUI to boot), and are mistakenly assuming a) this stuff you've spent years memorizing is "self evident" to anybody, and b) nobody can spend a similar time learning CLI.

To me this seems totally absurd coming from an accomplished programmer, you surely do not have to rack your brain trying to remember the structure of a JS for loop, and wish for a colourful set of GUI icons added to your IDE so you can reach for the mouse and click to produce one for you each time you need it.

I specifically said more or less self-evident and I specifically said I complain about confusing GUIs all the time. But once I get it I rarely have to google a gui to remember how to do something.

I've used ps aux | grep node about 10k times and I still routinely type -aux if it's been a few weeks since I last used it. That feels inefficient to me. Maybe I just suck at rote memorization.

As far as coding, again like I mentioned - 99% of my coding is concept-related. The syntax I need to memorize is minimal compared to the concepts. And I still have to look up **** like slice() when I need it.

With *nix it feels like the opposite ratio - 99% memorizing things and 1% concept. All that street knowledge London cabbies spent years memorizing got more or less replaced overnight by Waze (although I'm sure they're still taken care of in some protectionist way).

Can vi do code auto-complete btw? Because that's a good example of having a context-aware list of available options (at one click, not in a man page or off in google). It's not like I'm just talking about GUI - I'm talking about context aware choices that don't have to be looked up off in some secondary process.

There are autocompletion plugins available for vim. But like others, an IDE that supports vim key bindings is definitely best.

Nothing to do with UI is “intuitive,” not without the user already having some familiarity with computers. Mac vs Windows makes this really clear, switch and you break all the metaphors you’re used to and struggle to do the mapping to the new OS, and it doesn’t really matter which way you switch. Mobile apps have started making applications more discoverable but most of that comes from having a tightly focused set of features and a common set of functionality imposed by the OS. It’s not like PC/Mac apps who decide to redo their whole UI to make it look cool.

Suzzer didn't say anything about "intuitive" just the lasting ability of the learning process. And I definitely agree with him.

he said:

Ok yea true, I was mostly looking at more recent posts. I guess I'm reading his general stance as more focusing on the "learning it once" aspect, where typing a complicated sequence of symbols (while potentially more powerful and faster, I'll gladly admit) is harder to stick in the memory.

The CLI is probably worse than a GUI for trying to figure something you do once a month or less often, but is easier to document someplace so you can find it later.

Remember when I took that home wine making class, and forgot how to drive?

I actually find suzzer's approach to this really surprising. But... I guess I came into computers in the DOS / Apple IIe era, where typing stuff was just the expectation.

I really disliked IDEs for most of my career and only started using one like a year or 2 ago. I still revert to emacs a lot - in comparison the IDE is slow, and it sucks at plain editing. It's macro recording is not great in comparison, and it might have a built in scripting language but I already know emacs lisp, so...

I don't use GUIs for things that have a decent non-gui counterpart - like, I use git/svn/cvs/etc from the command line exclusively.

As a project lead/architect I tend to have a bunch of projects open at the same time in Sublime, and I flit back and forth a lot to grab stuff from one from the other. Global search across not the whole project but a specific subset of files (IE - exclude node_modules), and sometimes replace, with easily scannable results that can drill down to the file - is probably my biggest requirement. I know you can do all this with vi/emacs. But I can't imagine it's this easy.



Git's another example. With SourceTree and there's barely anything I had to memorize. I had the whole thing picked up in a day. Maybe a few more days to learn the quirks. Again - I suck at remembering stuff like flag syntax.

Also no one's ever shown me a good command line way to selectively back out (discard) changes that remotely matches what you can do visually in source tree.



I can chose to discard all changes (discard file) or one hunk or even some line if I highlight the lines. Gives me the freedom to make all kinds of crazy debugging code, then just discard it when done. Maybe there's a simple way to do this with command line, but I always show it to command line people and they say something like "yeah that's a lot easier".

I find myself wanting to do global search/replaces like... once a year.

ETA: for global search I am usually using git grep.

Doing git 100% from the command line is a huge leak, sourcetree etc is critical to quickly do some very tedious stuff like comparing commits and checking out commits (detached head)

Disagree, I'm with Wolfram. Superior diff visualization is literally the only advantage I can think of for a GUI. Checking out detached head on the command line isn't hard, not sure what you're referring to...

Most of my in depth debugging involves figuring out exactly where it broke which usually involves a ton of both checking out commits and comparisons (specifically click on commit in sourcetree and control click on other one which maybe not everyone knows about) which would take me like 3x longer just on the command line but ymmv.

I"m in the total opposite camp. I truly abhor GUI for anything programming related. The git GUI stuff is plain awful. I notice that a lot of these complaints are more vim-related, but everything discussed here is easy with Emacs, even the IDE stuff.

An example of GUI vis-a-vis command line is working with Postgres. PgAdmin wins for executing a query and seeing the output in a clean grid, making quick changes to the data, and other small things like that. PgAdmin fails against the command line for hard-core admin stuff, and you sacrifice fine-grained transaction isolation, which is very important when doing migrations and ETL and general development. There is a reason some people don't respect people who must use a GUI -- some things just aren't possible.

Suzzer, if you really can't remember ps aux | grep node, why don't you have a bash script, and why not have that bash script include the kill command? If you do something twice, you should script it, IMO.

Remembering a script name you rarely use isn’t easier than flag formatting on a command you rarely use...

Maybe he doesn't use it that often, but he would also get the benefit of having the script under /usr/local/bin, so it's auto-complete now. If he calls the script "node-kill" or something similar, he only has to type "no" and he can get auto-complete options. Scripting doen't mean you have to call everything two-letter names.