Zealots trying to convert unbelievers is plain obnoxious. Your choice of editor isn't a religion so use what you use and I'll use what I use and you don't have to worry that what I'm using isn't what you are.
The author believes that <Technology X> is superior to the alternatives, and wrote a blog post complaining about people who pressure its users to switch away. That's not exactly Jehovah's Witness knocking on your front door to thrust a magazine in your hand. In fact, the conclusion section starts with, "Do whatever you want. Don't learn it if you feel it's too much effort just for nothing.". The gist of this piece doesn't seem to be "converting" anyone. Ironically, it seems to have been inspired by receiving such pressure from others.
Half of Hacker News consists of discussing why all users of last week's fad should abandon it and jump onto this week's fad (e.g. "MySql -> Postgres -> MongoDB -> back to Postgres"... "Ruby -> Scala -> Node -> Go -> Rust -> Julia", etc). If you're looking for obnoxious zealotry, there are plenty of better threads in which to look.
You are missing the very point of a shell. Text gives you power, composability and flexibility that you simply cannot achieve with a GUI. Automation becomes extremely easy because of this.
Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work instead of breaking your concentration.
Vim has its own vocabulary, and the essence of vim commands is composability. You imbibe this vocabulary over time and editing text becomes effortless like stringing together words to form sentences and sentences to form paragraphs.
The shell is so successful precisely because it uses text as a common representation for all data. It simply wouldn't work with a mouse. Many people have tried this and failed.
Computers are good at manipulating text and humans are good at understanding text. The abstract geometry that you have to use to describe mouse movements is neither intuitive, nor is it easy to process.
Can you think of any big things that you lose though?
> Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work...
I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though.
> The shell is so successful precisely because it uses text as a common representation for all data.
Successful in what way? As successful as GUIs?
> Computers are good at manipulating text and humans are good at understanding text.
Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell.
They each have pros and cons. GUIs are generally more discoverable. Terminals are /way/ more flexible, faster, and customizable if that's your job and you take the time to learn them.
> Can you think of any big things that you lose though? Definitely. Customizing behaviors. I work with image sequences a lot. "ls" is used to list files in a directory "lss" is a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui, you need to re-write your whole file-browser or have one with some plugin system that support this (I don't know of any).
> I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though. That's a terrible analogy and a half-truth on both sides. Jumping to the mouse does slow things down, but I use GUI file browsers without a mouse just fine. The only thing I can't do out of the box is resize and move windows around--navigating through directories is fine.
> Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell. I think the difference is that guis offer more spacial queues and persistent information than terminals do. Someone who has never used a computer would be equally confused at how a mouse or scrolling worked. Humans are not terrible as memorizing text commands, there's just no need to use them everyday and a gui is usually good enough. Fewer people can drive a stick-shift or parallel park now that it's generally unnecessary. It's not that it was difficult. I imagine in a few generations after automation takes off driving a car at all will be difficult for most people.
You didn't say how you arrived at the conclusion that shells are "so successful". How are you measuring that?
> ...a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui...
Those things are eminently possible with a GUI without writing your own file browser since most major file browsers offer a range of extensibility options. Also, GUI automation is a thing and it works well. Just last month I wrote a simple script to automate image extraction from a program that didn't provide any API for it. As a matter of fact, I didn't even have to write most of the script because the computer aided me by recording my mouse clicks.
> Jumping to the mouse does slow things down.
Looking up commands and configuration protocols slows things down way more though.
> Someone who has never used a computer would be equally confused at how a mouse or scrolling worked.
Equally as confused as they'd be when presented with nothing more than a blinking cursor? I don't think so... Once you move the mouse and see the pointer move, it's pretty obvious how movement works. Sixty seconds is enough time to accurately convey complete operating instructions for a mouse. Teaching someone how to use a shell would take much more time I imagine.
Anyway, I use a shell when it suits me and a GUI when that suits me, but most importantly, I am not a bigot or an elitist about it. I don't think that there is one true way to do things.
It hasn't been explicitly said, but all of these arguments are implicitly about file browsing and file management. I can't imagine anyone exclusively using commandline tools for things like audio editing, browsing the web, etc.
I'm genuinely interested, how would you write something like that for a file browser on any platform?
A GUI program can do everything that a command line app can do and more, but unless we discuss exact requirements I can't answer the question very precisely. In terms of input and output I think there are generally more options with a GUI though.
Funny story on this topic - last night I was playing around with Fedora 21 + Gnome 3 and when I used git (in a terminal), whenever it needed a username or password it would pop up a GUI with a single text input. It's called askpass and I still haven't found out what exactly necessitates such a workflow, but I thought it was pretty hilarious.
> ...on any platform.
Command line programs don't work on every platform. Far from it. They don't even work on every Linux distro and especially not with normal usage on variants such as Android. So that's a bit of an unfair requirement to add just for GUI apps, don't you think?
I think we're in agreement that they both have pros and cons. It certainly can be easier to write a command line application that works on all platforms. I wasn't arguing against that - I was arguing with the guy on this thread who seemed to think that command lines are the single best way to interface with the computer. The guy who responded to almost every dissenting point of view...(not you). I didn't realize that it was not you at first, but my first response was to that person.
There are a lot of things I like with a terminal; history, tab completion, man pages (all OS help pages are generally useless. The only aspect I've ever liked is OSX's searchable help menu that will hightlight menu options). On the gui end you can't beat the discoverability, window management, but a big win is an undo stack. I feel like touchscreens are a step back in discoverability (but they have their own merits).
I think terminal people really latch on to the composibility of Unix apps that are provided via pipes. I've seen people try to come up with a gui equivalent (copy/paste is the closest), each gui feels like a walled garden (almost as bad as iOS apps). Something like AppleScript or D-Bus tries to address this, but I feel like if you're writing a script its basically a less-interactive shell. Automator seems like a decent take on this, but not too many apps expose an api for that and I've struggled trying to get it do what I wanted.
Just one question regarding the program you described - you're talking about the "lss" command you wrote, correct? You said that it exists in order to "group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial".
I don't know how you're grouping image sequences together, but I can't imagine why a GUI wouldn't be able to represent image groups as well as or better than a terminal program. Could you tell me? Alternatively, is your program open source? I'd love to check it out.
Here's a custom file open menu from one of those apps that wrote their own implementation (you can expand down to see the individual files): http://www.tweaksoftware.com/static/documentation/rv/current...
Here's a Python library with generic grouping logic: https://github.com/4degrees/clique
The hooks are there to do it though, at least in Windows Explorer and Gnome/Nautilus. Something very similar built into Windows with html file/folder groups and zip files. There are tons of third-party Windows Explorer extensions that change the way files are displayed. You can definitely create virtual nodes and hide nodes that you don't want to show (even in native open/save dialogs).
While I have no doubt that it would be possible on OS X, I suspect that easy-to-use hooks are not available for Finder like they are in Windows Explorer. You can write a QuickLook extension for Finder though.
(Some file browser extensions are easier to write than others. The image sequence in particular would definitely be easier to implement
Plan 9's ACME or it's descendant probably.
The fact that you have not made a single counterargument to any of my points betrays a lot.
Now you can feel fulfillment when you log into your graphical OS and instantly open gazillion terminal windows to bypass all the progress that has been made in last 20+ years... because computers are better processing text then graphics.
I grant you one thing: when you sit in your cafe pretending to work on something infinitely more important then everyone else, girls/boys will be impressed by the complexity of your screen...
This argument ("Oh I use <insert console based editor> because I can use it on my laptop or via SSH on the server") is fucking stupid.
If you can learn how to use fucking vim or emacs, you can learn how to use configuration management - either through a "full blown" tool like puppet/chef/ansible/etc or through config packages (if you're on debian) or even through plain old shell scripts.
Except when it's not really your call. And you have to poke around files so far down behind God's back through a shared desktop Enterprise VPN IE-only plugin-fest, that you don't even know which way is 127.0.0.1, then you're happy that you have vim on Dear Client's pointlessly supported RHEL boxes by default.
And othertimes, when you want to debug something that only happens on a live/production server.
Editing files on the server live is - in itself - not right or wrong. Doing it as a regular workflow is what's bad.
Oh, and if you're editing system config files for systems administration tasks? That's on the server. As GP said, if you come from a sysadmin background, you're used to using a keyboard-only editor. And Vim sure beats ed.
If you're doing it infrequently this is even more of a reason to use a reproducible system, otherwise recreating the environment when the inevitable happens is even harder (you don't even have the benefit of repeated steps to aid you in the process)
I know some of the existing tools are a massive overhead for small operations - that doesn't make the goal in general any less worthy.
I agree calling it better than any other editor is erroneous. There is emacs too, but that's about it.
I'd argue with that.
You need type completion because your brain shouldn't worry about whether the method is called `updateBufferFromStorage` or `updateBufferStorage`, it should be focused on writing the best possible code.
Emacs is a good Elisp environment. Evil-mode turns it into a good editor :P
I agree with the statement "use the right tool for the job", but people shouldn't diabolize something without knowing why others swear by it. FYI, in most cases we use Vi(m) because it's the fastest text editor available, not an IDE.
Granted if what you are doing is actually editing text then it makes sense to use Vim or Emacs, but I find that I relatively rarely do that.