Computer Science: Teaching Terminal

Finding the center of a circle
We find the center of a circle by exploring its edges…

I may have bitten off more than I intended to chew last week, when I began teaching the Apple computer program Terminal to my students in our Digital Arts and Sciences curriculum in seventh grade. For those who don’t know, Terminal is a command-line program, which allows one to navigate one’s hard drive via text commands rather than Graphical User Interface (GUI) commands.  It’s a layer closer to machine code than many of them are used to, and it’s a layer closer to the actual way that a computer operates than most of them really understand yet.

See, graphical user interfaces are actually a shell or interface between you and how your computer actually works.  On an Apple computer running Mac OSX of any level, as I understand it, the mouse clicks and the movement of the mouse’s X/Y axis are essentially giving instructions to Terminal, which is then translating those instructions into machine code for the computer’s hardware chip to read.  It’s more complicated than that, but the essence of it remains the same: the graphical user interface is a façade operating in front of the real software mechanisms.

I’m using Appendix A of Learn Python The Hard Way to teach the use of Terminal, and kids are finding it annoying. But they’re going to thank me when it comes time to write python programs, or at least I hope they will.  In the meantime, I’m finding it mildly scary for myself to be learning how to run computer commands this way.  It’s also been useful, though — when I found a program-test to see if the Shockwave bug in Bash affected me, I was able to figure out how to do the test.

I never intended to be a computer science teacher. If you’d asked me ten years ago what I’d be doing in a decade, I’d have told you, “Teaching history.”  But teachers have a funny way of being thrown for a loop late in their careers. Either they become skilled at a new area of study, or they become administrators.  I’ve become a little of both.  My computer science classes are still weighted heavily toward multimedia and typing and learning to make presentations, but at the same time I’m leaning into my weaknesses, and learning how to be a computer programmer and a teacher of computer languages.  It’s scary.  But at the same time, it’s going to make me a much more powerful and flexible teacher in a couple of years than I am now.

The result has been fascinating. I’ve been teaching some of my students geometry a year earlier than they would normally be exposed to it, by showing them how to use vector graphics programs to lay out geometry proofs.  It’s good practice for them, picking color and shape and line, and designing a problem’s solution-space.  Some of the kids have taken to animating them.  Others are working on short animated videos.  Still other students are learning to type, while others are learning HTML and CSS — first at the level of typing commands, and later on using a dedicated editing program.

An animated triangle proof
An animated triangle proof

It’s a bit of future shock, though.  For me, and for them.  So much of the class is not about learning, but how learning.  They’re learning how to program, how to build slideshows, how to choose fonts and colors and shapes.  It’s hardly what they normally experience in school.  It’s been hard learning for me, too — learning how not to touch the keyboard and mouse, learning how to give verbal and visual instructions instead of simply taking over their projects.  It’s been wild to discover the actual boundaries of what “digital natives” genuinely know how to do (which is more limited than we suppose).

I took up the role of our Design Thinking director at my school in part to teach many more hands-on skills with hammers, saws, knives and drills. Instead of doing that, I’m teaching kids to manipulate bits and bytes: to be graphic designers, slide-show creators, better typists, and now computer programmers.  It’s still design, but it’s a weirder kind of design than I expected to be doing.  So it goes.

3 comments

  1. On an Apple computer running Mac OSX of any level, as I understand it, the mouse clicks and the movement of the mouse’s X/Y axis are essentially giving instructions to Terminal, which is then translating those instructions into machine code for the computer’s hardware chip to read. It’s more complicated than that, but the essence of it remains the same: the graphical user interface is a façade operating in front of the real software mechanisms.

    When you run GUI programs, the Terminal application will not be involved at all. Command line programs you access through Terminal.app and a shell like bash may be invoked by a GUI program but usually not. GUI programs and most command line programs use APIs provided by the operating system to interact with data and other programs. GUI programs have to use a lot of APIs just to display and enable any interaction, it’s like the Carl Sagan quote, “if you wish to make an apple pie from scratch, you must first invent the universe.” Command line programs are far simpler so far fewer APIs are involved in getting to the point of allowing input but once at the point of doing something, the instructions to a system API from a GUI or command line program can be exactly the same.

    A shell like bash is very analogous to OS X’s Finder or Windows’s explorer.exe, it helps you access other programs. GUI programs have two-dimensional input and output. Using command line programs is like visiting Flatland, their input is one-dimensional. Command line output is one-dimensional too but thankfully we have the Terminal wrapping text, scrolling and buffering to make it roughly two-dimensional.

    Of course there are command line programs that have 2d interfaces (at least for output, if not input), ‘top’ is one, most text editors (nano, vi, emacs, etc.) are others. Those use other software like ncurses to do that, they’re like very basic graphical APIs with far fewer parts compared to a full GUI.

    That Python book appendix looks like a pretty good way to get started and I agree it’s good for students to get some experience with “going to the dark place” (boo to Apple for making Terminal have a white background by default, screwing up that idiom).

    • Dear Curtis,

      As you’ll see from the other comment I just approved, my friend Janet has also pointed out the challenges with teaching terminal as I have. It’s by saying this stuff aloud that I get corrected and reminded. I like the Flatland analogy. That was one of the better books I ever read — if I’m ever forced to teach mathematics, I’m putting it on the reading list, or more likely Sphereland, because it illustrates how mathematical concepts interact with physics quite well.

      Clearly I’m going to have to understand Bash better than I do now. I found a test to input by command line, to see whether or not our computers were affected by the bash bug that’s been in the news recently, and so my computer class ran that test yesterday. The results were interesting — some of our computers were vulnerable, and some appeared not to be. Not sure why that is, yet, but it raised a lot of interesting discussions.

  2. I enjoy seeing these things afresh through your eyes. They’re so familiar that it’s hard for me to perceive them the way a newcomer would.

    I’ve taught a couple very brief introductions to the command line. I feel it’s helpful to open up Finder or File Explorer alongside the command line, especially when we talk about navigating among directories. It’s hard to remember a sequence of directories in a path. Folks are often (but not always, to my surprise) familiar with Finder already. It shows the nested folders, and you can see your new files and folders appear in the GUI as you create them in the command line.

    If you try that, I’d appreciate feedback on the technique. I’m still improving how I present the command line.

    This looks fun, though it covers some commands you aren’t using:
    http://hewner.com/2010/07/02/mikes-ultimate-unix-scavenger-hunt/

    The Command Line Mystery requires you to use additional tools like grep ( find files containing a string ) and regular expressions ( find things that fit a pattern, e.g. a phone number is 3 numbers, dash, 3 numbers, dash, 4 numbers).
    https://github.com/veltman/clmystery
    The list of commands it uses are here:
    https://github.com/veltman/clmystery/blob/master/cheatsheet.pdf?raw=true

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s