In the Scouts you get badges for the things you learn, and you show them off by wearing them on your sleeve, once a parent has stitched them on.
Lately I’ve started curating aliases in bashrc. For anyone who hasn’t used it, it’s a file in which you can store settings for controlling your computer, including abbreviated versions of commands you use a lot (aliases). Some people like to share these files, or snippets from them, to give other programmers ideas for which shortcuts to include in their own collection.
The nature of the file lends itself well to this sharing. You do the work of learning some new command, practise using it until it is part of your everyday toolkit, and then make a shorter reference to it. These references become a list of what you know and can do, and a neat little resume of your command line experience.
I installed Atom today as I needed some kind of IDE without forking over a lot of money, or spending time on configuring something. This meant trusting the claim that it works straight out of the box.
Later as I considered whether or not I would use it beyond the one task I needed it for, I googled “vim in atom”. This made me realise that I’ve become acclimatised to Vim to the point that I want its functionality in anything I use, and also begin to wonder why I didn’t just stick to using “vim in vim“.
Luckily, the search results page contained answers to both of these questions.
Why do I use Vim? Partly to score NeckbeardHacker kudos from Unix greybeards, but mainly because it allows you to compose commands so neatly from smaller “words”, as discussed in Why Atom Can’t Replace Vim by Mike Kozlowski. Having become used to hitting commands for “delete three words” (d3w) and suchlike, it’s hardly desirable to go back to Ctrl+This+That shortcuts.
But I’m not a Vim power-user, and as such I want more. Thus, my second question; why don’t I just use vanilla Vim? It lacks a shiny GUI, with lovely nested directory trees, and the plays-well-with-others style of a typical modern IDE. And so I’m waiting for a suitable neovim, or until then, Vim in Atom.
prurient having, or characterized by lascivious or lustful thoughts, desires, etc. ochre a moderate yellow-orange to orange colour moribund in a dying state, near death bibulous fond of or addicted to drink sepoy (formerly) an Indian soldier in the service of the British venal open to bribery impeach to accuse a public official, before an appropriate tribunal, of misconduct in office acquiesce to submit or comply without protest widdershins in a direction contrary to the usual, e.g. anticlockwise diatribe a bitter, sharply abusive denunciation, attack, or criticism
(definitions copied or adapted from dictionary.reference.com)
One might argue that a book about code is somehow behind the times—that code is no longer the issue; that we should be concerned about models and requirements instead. Indeed some have suggested that we are close to the end of code. That soon all code will be generated instead of written. That programmers simply won’t be needed because business people will generate programs from specifications.
Nonsense! We will never be rid of code, because code represents the details of the requirements. At some level those details cannot be ignored or abstracted; they have to be specified. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code.
From Clean Code, Robert C. Martin.