In part 1 of this series, the terminal tool is covered. Through that post, as well as some further exploration of the command line (with some terminal program), you should begin to see your computer as a filesystem.

Using a command line interface rather than a graphical one (such as Mac's "Finder" or Windows "Explorer") likely initially feels inhibiting. Clicking and dragging is easier than typing. A post or series of posts will not dislodge that view. It will take experience with the terminal and other text based programs to see the massive amount of flexibility and utility available therein. In other words, the "why" follows the "what" unless you establish a placeholder "why," likely in the form of some authority telling you that it's important. Maybe that's this series. Maybe it's not.

You can develop your sense of your machine as a filesystem without the terminal, and you can program without such a view or making use of the tools that come with a terminal (you can even use an online editor).

I caution against that approach not because it isn't "real programming," but because it gives up a lot of control of your workflows and narrows your choices of tools. The creation of a GUI requires a more complicated set of skills, a longer development time, and less portability. Additionally, GUI styles have a shelf-life. Text-based (Command Line or "CLI") programs can be make quickly, often by just one person, and the decision to expose or hide functionality is comparatively easy to calibrate (and to be generous with, due to the lower amount of effort and collaboration required). Additionally, the interfaces of command-based tools tend to be preserved and don't require new designs for maintenance. For these reasons, you'll find a broad set of tools from multiple eras of programming available within text-based interfaces.

Now that we've reiterated the usefulness of the terminal, and command line programs (which cultivate the view of machine-as-filesystem), let's talk about what is in the filesystem: files.

Files

Files are text. Deep down, they have "encodings" and are all 1's and 0's somehow, but that's not how we interact with them. For our purposes, they are readable text. Sometimes, that text looks like this:

class GoodStuff
  def do_something
    puts 3
  end
end

or this:

div{
  color: #000;
  background-color: #FFF;
}

or even this:

sajldf adsl fjsafsa

sdafs
af
saf
sa
fas
fasdsjl  fsaj fsal jfasf

The contents don't matter yet. What matters is that what is inside of them is somehow readable to us (Note that in the last example, the characters are readable, even if the text makes no sense).

Files have Names and Extensions

Maybe that first file is called good_stuff.rb. Maybe the second is main.css. Maybe the third is jibberish.txt.

The names are just labels. The "extensions" of .rb, .css, and .txt are useful hints as to what contexts the contents of the files would be useful in, but neither the names nor the extensions prescribe using the file in any particular way. You could ask a ruby interpreter to try to read any of those files, and it would throw an error on the last two. And if you asked a ruby interpreter to read a valid ruby program (like the first one), even if its name was jibberish.txt or I_am_not_a_ruby_file.not_ruby it would happily read it anyways.

Names are useful for us to know what's going on, but the programs that "execute" the files care about the contents of the files, not the names (for the most part). Let's address some exceptions now.

Programs that Care about Extensions

Our first exception to this is the open command that was covered in the previous post. This command acts as a double click, which considers an MP3 to be something suitable to be opened by a music player, vs. a PSD file, which it would want to open with Photoshop (same as double click would try to do).

If you're used to a GUI interface, you might expect this behavior most of the time (double clicking a file opens that file with a program to "execute" it). But as programmers, we're interested in files as text, because those are files we can manipulate.

Through this lens, a web browser doesn't view html files, it executes them, or in other words, interprets them to provide a GUI for them.

Similarly, double-clicking on a word document (a .doc file) to open it in word doesn't open it in the sense that we care about as programmers.

We'll come back to why this matters and how to tell if your file is immediately useful to us as programmers in a while. First, let's talk about how to edit the types of files we care about.

Text Editors

You can find dozens of viable text editors for free. You can find a few viable ones that cost money. You can find things called "IDEs" or "Integrated Development Environments" which are text editors with extra features (sometimes of dubious value and sometimes custom tailored to a specific purpose).

Generally, the most important feature that they allow is to create, edit, and delete text. The file is saved. The file can be opened for editing. These files may contain "code" (but could be simple "text" as well).

You could spend weeks or months researching the "best" text editor, but again, you can skip some of that uncertainty by getting something good enough. Atom is good enough. Vim and Emacs have a lot to teach, but Atom is a simpler tool to start with. It has a few peers in the "modern and not too complicated" category, but start there. After learning its features it will be very easy to change to or try out others in the same class if you feel like it later on.

"Uneditable" Files

Many files you encounter are not made primarily to be opened by a text editor and manipulated directly (ie. they are not "code" or "text"). The first is those that are specifically intended to be executed by some program that is not a programming language compiler or interpreter. The examples given before of MP3s, PSDs, or Word documents all fall under this category. Additionally, these files may be intentionally "obfuscated" (mixed up and oddly organized) to thwart reverse engineering or be "compressed" so that they can be smaller. The specifications for these files may be available or proprietary. They may be easy or difficult to edit (note that you can still use an editor with these, but it is harder because their primary purpose is not to be human readable).

Another type of "uneditable" file you'll encounter are "compiled" files. Sometimes, a programming language has an "interpreter" which reads the code you write and executes it right away. Other times, a programming language has a "compiler" that translates your code into something simpler for the machine (but not you) to understand. In those cases, you'll usually see 2 different commands: one to "compile" your "source code" and another to execute the compiled program (a distinct file from your source code). These compiled files are unlikely candidates to be edited directly, and if you open them with a text editor, you'll see a lot of nonsense (just like if you opened an MP3 or PSD).

Who Cares?

In the first part and the intro to this one, we discussed the terminal as a tool to give you more autonomy over the workflows of your machine. Directly editable files give you the second half of the equation. Through them, you can (given an understanding of the relevant programming languages and other systems) take on the role of "creator" of computer programs, rather than the "user" of them. Using a text editor (or maybe even creating your own!) is how you do this.

Again, yes, there are graphical programming languages and that very well can be "real programming," but ignoring the flexibility of terminals and text editors will drastically reduce your options.

Finally, note that a career in programming affords both creation of files in the sense we mean here, and by defining workflows for others. Consider your role in both of these schemes. For a take on a newly novel but classically generous approach to doing this in web development, see this post.