[jwhite]

I appreciate your point, but I think the choice to write all or parts of an application in shell depends a lot on what you need to achieve. Writing 100 lines of shell to glue parts of your application together may be the best way to ship something today, even if you plan to replace that with another language in 3 or 6 months time.

Would you care to give a link to your guide? I'd be interested to read it.

[sethrin]

With a few caveats:

* It's a work in progress and a bit lacking in visual presentation at the moment

* The target audience is the novice developer

* I am writing from my own experience and I am not an expert

* "comprehensive guide" should probably have been "comprehensive primer". This is what I think beginning devs should know about the shell.

https://tenebrousedge.github.io/shell_guide/shell_guide.html

Commentary, contributions, and criticism are invited.

As far as 'shipping something today' is concerned, that's what keeps me from learning vim. At the moment I'm both working and going to school full-time, so I feel like I can't quite justify the time investment, but I know I'm holding myself back from being a far more effective programmer.

I also have an acquaintance doing computational biology for whom Bash is an essential part of his toolkit for DNA analysis. Bash sometimes is the right tool for the job. It excels at text processing. It's just archaic and ugly, and we have nicer options available for programming languages.

(and now that my SO is up I think I'll watch this video)

[thomastjeffery]

> 'shipping something today' is concerned, that's what keeps me from learning vim.

If you want to learn vim (I would definitely recommend you do), learn a little at a time. Vim is better suited to this approach than you might think.

People tend to focus on vim's learning curve, but as soon as you grok 3 things, you can do everything you used to do with normal editors. Then all you need to do is learn one small function at a time.

1. :command

:w save the file :q quit vim

2. Normal mode

You are here. Pressing a key runs a function. Escape cancels. u is undo, Ctrl-r is redo.

Every key has some specific use. You can learn them one at a time.

My favorite is . (the . key). It repeats the most recent action at the cursor.

3. Insert mode

Pressing i puts you in insert mode. Here you can enter text like normal until you press Escape

Remember that everything that happens between pressing i to pressing Escape is one action that can be undone or redone.

Later you will learn that a s r and o all do similar things to i.

[jwhite]

Thank you. Looks like you've packed a lot of good stuff in there already.

I only skimmed so far, but this quote stuck out:

"Programming is fundamentally a way to save human labor, and that includes our own labor."

I'm continually amazed at how many software engineers seem to miss this point.

[sethrin]

Yes, that line came out of arguments with greybeards about the problems of the younger generation and using all these fancy frameworks and wasting memory and CPU cycles.

I will also add the further caveat for anyone else who arrives here that this was written in stolen hours in the last two weeks, and specifically because the page of 'Assumed Knowledge' referred to in the introduction seems to have been the only instruction in the shell given at Epicodus' Intro to Programming. I'll never love Bash as a programming language, but given that it's a tool developers use every day, I do think there's a certain minimum amount of knowledge required to use it well.