There’s a difference between working in the command line and working in a desktop environment which I think is crucial to software developers’ formation.
When you’re working on a desktop environment, there’s a particular flow that shapes the way you interact with your programs and files: you’re working on a physical space, and to use your tools, you go to them, then get your data into them, use them, then get your data out, back into your desktop. For instance, if you want to take some data from a text document and perform numerical analysis on it, you’d go about it thus:
- Go to the place where you launch programs from, and open an editor
- browse for the document with the data
- get the data out, presumably by copying it into your system’s analogy of a clipboard
- Go to the place where you launch programs from, and open a spreadsheet program
- paste the data
- use the spreadsheet on it
- store the resulting document where you want to do it
The important part here is that you go to the tool then get the data in the tool.
In the command line, it would be a little different.
You would point the relevant tool at the document, extract whatever data you need, and point another tool at the resulting documents if you still need it. It’s the difference between:
- Navigate “Start menu -> programs -> accessories -> Notepad”
- Navigate the menu “File -> Open”
- browse for the document
- Type “editor name_of_the_document” or “editor /path/to/the/document”, or in the worst case scenario, “/path/to/editor –option-or-options /path/to/document”
There are some workarounds to this situation, like having default applications being able to open a file, or right-click and selct “Open With…”; but those actions feel very ad-hoc.
Thus the command line feels more like you’re reaching for a tool and using it where you need it.
A consequence of this is that when you write an application for use in the command line environment, no matter how simple it is, it feels as if you’re changing your operating system to suit your needs. When you develop simple desktop applications, it feels as if you’re building environments to put your data into.
From this peculiarity of each environment stem patterns of use. Tool chaining and piping feel like “reach for this, apply on file/data, then reach for that and apply it on the results”, which helps you think about the whole process seamlessly. Building tools to put into a chain means that they could do only very simple things, and still be very useful. Thus are early developers encouraged.
Customizing the whole system… is very encouraging, of course, and having “commands” or “actions” at your disposal which you’ve built yourself, as opposed to having “containers” into which to put the data for work, is very empowering.
There may be some way of chaining programs in a desktop environment, or creating simple software in such a way that it feels like you’re changing the whole system. I have not encountered either.
The most powerful feelings around desktop environments I’ve done stem from manipulating the PATH variable and having some daemons doing fun stuff around the UI, the kind of stuff that would give you pause and wonder whether my computer’s behaving oddly or if you’re imagining things. Doing this in a command line environment is par for the course, but feels no less empowering.
I am not talking from nostalgia here – grew up using GUIs, not CLIs. Indeed, even though my first programs were CLI-based, as I was using them from a GUI, the feelings of changing my environment to suit my needs didn’t come along until I’d started deploying software in a Solaris environment and started automating things.
When I discovered the feeling of changing the PS1 variable, customizing the .bashrc or .profile, creating aliases… it was then that I started being prolific in my CLI-program writing for practical purposes. It seeped into my other operating systems / work environments; I routinely create a directory for shortcuts to the programs I run, I tend to run programs with the “Run” option of the OS I’m using (Win+R in widnows, Win + program name in Ubuntu, Ctrl+Alt+T and run the program from the shell in most other linuxes, Command+Spacebar + program name in MacOS), write UI gadgets or other empowering shenanigans.
I think that much of this would’ve started earlier if I’d had a powerful command line as a primary tool for using the computer at the time I started learning how to code. I don’t mean to disparage GUIs; I just think the kind of feeling delivered by a good CLI and the patterns of use they encourage can be of great importance when starting to code, enough to make it at least a great complement to GUI-based computer usage and software development practices at the time of learning.