08.07.20
Computing Fundamentals
2020 figosdev
Index
- Chapter 1: Start With Perfection
- Chapter 2: Controlling Your Computing
- Chapter 3: Miseducation
- Chapter 4: Computing vs. Marketing
- Chapter 5: The Psychology of Developers
- Chapter 6: Freedom is Personal
- You are here ☞ Chapter 7: Computing Fundamentals
Chapter 7: Computing Fundamentals
Summary: “A graphical interface is better, for some things — sometimes. But it will also put a lot more on our plates.”
Ask people to explain computing in as few words as possible, and many will start telling you about 1s and 0s. They’re not wrong, binary computing is very useful and quite relevant in our modern world of tiny silicon-based switches.
But if you want to understand the fundamentals of computing, 1 and 0 doesn’t tell you very much. A few computers, like the Harwell-Dekatron WITCH, even processed or stored numbers in base 10 like we normally do on paper. But what are these numbers doing?
“A few computers, like the Harwell-Dekatron WITCH, even processed or stored numbers in base 10 like we normally do on paper.”As mentioned in the first chapter, modern computers evolved from automatic calculators. Creating a program is really telling the machine to move numeric values into certain places.
At the most fundamental level — where I never do much of anything and a “low-level” coder could tell you far more, you are working exclusively with numeric codes for everything.
If that sounds incredibly tedious, it is. The main thing that people do on this level (called “machine code”) is find ways to make coding easier.
In the very early days (the 1960s were futuristic by comparison) when someone wanted to use a computer, they would do all of it in numeric machine code, or they would punch data into cards that helped correspond single-character codes with numeric (consecutive) physical positions that the computer could read with a card reader.
These numeric codes went into “dictionaries” or paper code books. After some months or so, you might find that you had a dictionary with several useful computer “routines” in it.
“The difference between an interpreter and a compiler is a like the difference between hiring a personal translator and commissioning a translated work.”The goal of making these hand-coded dictionaries into automatic programs became the basis for the first compiler. Like the BASIC interpreter in chapter 2, the job of a compiler is to translate codes that are friendlier to a human into numeric codes the computer understands.
This was a revolution for most of us, and while it started in the 1950s, by 1964 this revolution was exactly what made a beginner friendly computer language like BASIC possible.
Now instead of coding the letters H-E-L-L-O (SPACE) W-O-R-L-D into numeric ASCII codes (or Baudot teletype code, since ASCII didn’t exist until around the same time BASIC did) and then entering the code to move the numeric data somewhere that it can be output to the screen, you just say:
10 PRINT "HELLO WORLD"
And run the program. Seems like a lot of trouble just to say two words, but before that it was a lot worse!
If you have followed along and actually installed Core on your “thought experiment” PC, you can run a single line of code very similar to the above line. Just type:
echo Hello World
It will do exactly the same thing, only this command is for a 1970s-UNIX-style “shell” interpreter, rather than 1964 BASIC.
The difference between an interpreter and a compiler is a like the difference between hiring a personal translator and commissioning a translated work.
“The general rule is that compiled programs are better for tasks where speed is very important, but interpreted tasks are better for code that is going to be constantly tweaked.”If you are talking to other people, and have a translator with you, the translator will do the “interpreting” for you as other people talk. Every time you run an interpreted program, you need to run the translation program.
While this has certain costs in terms of efficiency, it means that when you want to change something, you don’t have to wait for it to translate the entire program again — you can just start running the new version of the code immediately.
A compiler on the other hand, translates the entire program into computer-ready instructions. Whenever you run the compiled program, it will run without being compiled again — but every time you change something you have to wait for the entire thing to compile.
“When you first run Core, it’s not obvious whether the thing you’re using is more sophisticated than the chip from the early 80s running BASIC on the C64.”The general rule is that compiled programs are better for tasks where speed is very important, but interpreted tasks are better for code that is going to be constantly tweaked.
Many, though not all of the friendlier languages are interpreted, because it is easier to find and fix problems with shorter waits (or more complicated processes) between edits.
When you first run Core, it’s not obvious whether the thing you’re using is more sophisticated than the chip from the early 80s running BASIC on the C64. That’s because all it gives you for an interface is text on a screen.
If you’re used to fancy rectangles with animation and even video, you might look at a simple command prompt and wonder if this is just a throwback to the 70s. But this is an old cover on a much newer book.
Someone who has only used DOS or a C64 can marvel at everything Core has behind the prompt. With a single command you can download a file or a webpage from the Internet.
It might not be available with Core, but with Tiny Core or CorePlus you can play your MP3 files from the command line. And you can run Python, which is more advanced than pretty much any BASIC interpreter or compiler, ever.
“It might not be available with Core, but with Tiny Core or CorePlus you can play your MP3 files from the command line. And you can run Python, which is more advanced than pretty much any BASIC interpreter or compiler, ever.”What’s more, you can make it do these things automatically, in response to certain events or specific times — you can even make it do these things in the “background”, so that you can keep working or have it do more than one task at the same time.
Sure, you can do all of those things with a graphical system as well. And you need a lot more code to make that happen — and lots more code means lots more opportunities for large projects to go wrong.
Apart from being a geek’s canvas, the command line is also where you go if some parts of the system (like all that graphical stuff people run on top of the OS) aren’t working properly. You can fix a number of things from the command line; it’s a bit like opening the bonnet of your car.
“Apart from being a geek’s canvas, the command line is also where you go if some parts of the system (like all that graphical stuff people run on top of the OS) aren’t working properly.”But the best part about the command line is that it’s faster and easier to write code for. Nearly all frameworks for graphical tools add considerable overhead in terms of resources and code you must tend to.
When you talk to a voice assistant, you’re doing something very similar to using the command line.
Selecting things from a series of menus can get tedious when you know the things you want. Imagine if instead of telling someone “I’d like the chef salad” your only choice was to open the menu, find the salad you wanted, and point to it — and you had to order everything else that way too. When people order fast food, having a menu in front of them often slows them down.
If you had to order that way every day, or for 20 people, you would really start to hate flipping past page after page after page after page, poking at every item with your finger. Sometimes menus help with unfamiliar tasks. Then again, they had menus for the command line as well:
1. Run Tetris
2. Run Word Processor
3. Quit
It isn’t the point of this chapter, but you could — with only things available to you from Core, code a little menu that displayed a list like the one here, using numbers to run each relevant command, with a number (or letter) that could tell the menu to quit.
Sometimes, instead of creating a menu, the easier thing to do is just take a command that already exists and giving it a name you prefer.
If you like the editor that’s called “nano” but just want to say “edit” or even “e” (why not both? You can do both if you want) you can create a second command so that whenever you hit the letter “e” and then hit enter, it will run nano. That’s even less work than hunting through icons on the desktop. Setting this up is also less work than creating a menu.
“A graphical interface is better, for some things — sometimes. But it will also put a lot more on our plates.”You can do far more than that, but menus are nice and easy. Shortcuts are nice and easy. Graphical environments can hide a lot of complexity, but they introduce even more of it in the process.
I’m using a graphical environment to type this — in a window next to another window, in a text editor I helped create — but did very little of the actual coding for.
And I’m running it in CorePlus. So don’t think I’m “fundamentally” against graphical environments or anything. A graphical interface is better, for some things — sometimes. But it will also put a lot more on our plates. █
Licence: Creative Commons CC0 1.0 (public domain)
Content is available under CC-BY-SA