Hacker News Reader

Comment by ACow_Adonis | Hacker News Reader

I think they know less than the people who were using computers back then.

The difference is of course that today computers are used by more of the general public for communication, office, and media consumption, rather than (only) bunch of tech savvy specialists.

Most of my generation and the generation that followed barely have a concept of a computer beyond "press the thing to make things happen". They know no more about their telephones now than did the people using the landlines of 20 years ago, or how much most people understood the internals of TV or radio or fridges.

As for running circles around people while using a GUI, while I accept there are specialized fields and exceptions that disprove the rule, outside of marketing presentations I just don't see it happen. As much as any generalisation can be valid, the GUI does not run circles around anyone that can actually program and is generally the mark of the computer novice/consumer...

View on HN

>As much as any generalisation can be valid, the GUI does not run circles around anyone that can actually program and is generally the mark of the computer novice/consumer...

That is patently false. There are hard core GUI users, from VFX and 3D artists to DAW and NLE operators, graphic designers and many more, than run circles around any "command line" person for the tasks they actually do.

Just as there are tons of programmers using Visual Studio and other GUI platforms, than can program far more efficiently with the intelligent autocomplete, integrated debuggers, profilers, and such, than some CLI-jockeys who think they are more efficient with their pimped Emacs or Vim.

Is Rob Pike and his GUI editor/environment a "novice/consumer"? What about tons of excellent Windows programmers? What about Notch?

> As for running circles around people while using a GUI, while I accept there are specialised fields and exceptions that disprove the rule, outside of marketing presentations I just don't see it happen. As much as any generalisation can be valid, the GUI does not run circles around anyone that can actually program and is generally the mark of the computer novice/consumer...

I wonder. Every time I see a colleague using command line to do git operations I get itchy and think to myself "oh, come on! I could've done this in gui in seconds". Each interface has its time and place, but to me using a GUI is more of a mark of valuing one's time than that of a novice.

> Every time I see a colleague using command line to do git operations I get itchy and think to myself "oh, come on! I could've done this in gui in seconds".

What operation could you possibly perform significantly faster in a gui than on the command line? I can think of tons that would be far, far slower in a gui.

> to me using a GUI is more of a mark of valuing one's time than that of a novice

I would argue the exact opposite. GUIs are there to make things accessible to non-power users. A command line is just infinitely more expressive and will let you be much more efficient if you learn to use it effectively.

With nearly every program that I use I start by depending heavily on the GUI and then transition to using almost exclusively keyboard shortcuts as I become a power user, as GUIs are fundamentally inefficient.

> What operation could you possibly perform significantly faster in a gui than on the command line? I can think of tons that would be far, far slower in a gui.

Sticking to the Git example: - visualising history (in gui it is just there) - opening old versions of files - visualising a complete log of a file and then jumping to individual diffs/commits

The fact that in a decent GUI everything that could possibly be a link is, is very useful. I do not ned to go around copy pasting SHA1 sums. I drop down to command line when I need an occasional filter-branch or do some arcane incantations. But maybe Git is a bad example because it has a notoriously bad CLI.

Some other example, debugging. For me it seems that you can actually see whether a programmer uses a visual debugger or a cli. If they have to drop down to GDB then their code will most probably be sprinkled with useless debug macros.

Setting break points, jumping from function to function is easier with visual debugger and a good IDE. (note that the IDE can be emacs or vim running in a terminal session for what I care)

> With nearly every program that I use I start by depending heavily on the GUI and then transition to using almost exclusively keyboard shortcuts as I become a power user, as GUIs are fundamentally inefficient.

Keyboard shortcuts are awesome of course, but I think they are so efficient because there is a GUI around. In a GUI you can always see more state at the same time. This is because graphics can sometimes pack more than text in the same space (e.g.: a visualised Git tree or a graph spitted out from callgrind)

I couldn't agree more with this. I generally prefer command-line tools like vim and gdb, but for getting a view on things like file history or browsing the output of tools like callgrind? GUIs are the way to go. Horses for courses.

I think it depends on the operations being performed. Adding a subset of the changed files? Holding ctrl/cmd and clicking the files is probably faster than typing all those names out on the command line.

Need to pull some new code though, or commit changes? I think "git pull" or "git ci -m 'Message'" is faster than opening up a complicated GUI window with lots of decisions to make.

Your colleague doesn't use completion?

To me, using CLI is like having a conversation, with much richer vocabulary, than GUI. That's just pointing at things.

Of course they do, but typing stuff is just physically slower for some operations. Typing git log, then scrolling through the pages of text in order to find the interesting change will always be slower than a right click -> log and then "pointing at things".

I think your conversation metaphor is good, but in a GUI the answer can be richer and interactive. A CLI can only manipulate text, a GUI can manipulate text where necessary and use a better medium (images, graphs, tables) where necessary.

There are always advantages and disadvantages of both approaches. I always shudder when I recollect configuring IIS using GUI ;).

CLI does not need to manipulate text only necessarily, see the command line in AutoCAD for example.

But yes, GUI in many cases is a better way, I wouldn't want to have cli-only Photoshop-like app (or even cli-only CAD modeller). The point is to recognize effectivity of both approaches for a given problem, at the given abstraction level.

Would you rather have a conversation with your car "left 20 degrees, now right, slow down a little, whats the speed atm?" or just turn the wheel and press some pedals?

That's not a good example - the conversation with the car would be "take me to {someplace}", which couldn't necessarily be a specific name of the place, it could be "where I met with {someone} {sometime} ago". Think Star Trek conversation with the computer ;).

There would be no point in micromanaging the car using a limited vocabulary.

But I can't go to command line and tell it "delete all of the files from the project X I do not want anymore" or "find me the change in this file in the history that caused bug Y".

Sometimes it is better to mass delete files with a find, grep and rm, sometimes an auto-filtered search and cmd+a cmd+delete is better.

>I wonder. Every time I see a colleague using command line to do git operations I get itchy and think to myself "oh, come on! I could've done this in gui in seconds"

A lot of the CLI usage feels fast because its busywork.

Reply on news.ycombinator.com