FRONT END, BACK END, HIGH LEVEL, LOW LEVEL Part I

by James Lincoln Warren

I know you’re disappointed to see me instead of Leigh, but his computer problems are still so severe he couldn’t be with us today. And if Leigh, who was a star at IBM, has computer problems, you know that they’re pretty serious. So in his honor, I’m going to write about computers. Today is all geek speak, but it’s exposition—to understand how any of this has any bearing on writing short crime fiction, you’ll have to tune in tomorrow. (I figured since I’m doing two columns back to back this week, I might as well combine them as a two-parter. )

I’m not a complete ignoramus in computer science myself. When I re-entered civilian life back in the 80s, I naturally looked for a job in the defense industry, since it was what I knew. I had several interviews, and they all told me that they loved me, BUT—“You’re not an engineer.”

“I know I’m not an engineer,” I’d reply. “I’m not interviewing for an engineering job.”

“Yes, but you’re not an engineer. We’re looking for an engineer.”

I never did get a job in the defense industry, but looking for one motivated me to go back to school and study something technical to beef up my résumé. So I got a certificate through UCLA Extension in Computer Science. This is essentially the same curriculum as a B.S. in Computer Science at UCLA, but without the electives. That was twenty years ago, and Computer Science has come a long way in two decades, but trust me—the fundamentals and concepts are still the same. Believe it or not, all computers are computationally equivalent. The power of a computer has nothing to do with what it actually does, but rather how fast it can do it, as well as how much data it can store.

The other night I was at a social event, and at the same dinner table, two men were getting to know each other. One of the inevitable questions is such circumstances is, “And what do you do for a living?”

In this case, the answer was, “I’m in the I.T. department of a big financial services company.”

“Really? What do you do?”

“I design our web applications—but I’m at the front end, and there are only three of us. The guys at the back end are in a different department.”

Now there’s a term I hadn’t heard in a long time. In Computerese, the term front end usually refers to having to do with the user interface—it’s the part of a program that acts as a translator between the human and the machine. This is not exactly the same thing as standard IO or graphical interfaces, but it includes them. Back end is where the actual work gets done, the invisible part of the program. From a software engineer’s point of view, that’s a gross over-simplification of the implications of these terms, but they’ll do for now.

For decades, well-written computer programs have always been modular. In the early days, this was called structural programming, and meant that essential blocks of code were arranged in the most logical and efficient manner to execute the program. Contemporary programming languages generally enforce structural programing, like C and its variants C++ and C#, whereas very early languages, like FORTRAN, COBOL, and BASIC, didn’t. Still, even if you were struggling with FORTRAN, it was easier if you took a structural approach.

The good habits required by structural programming are still alive and well, but as programming languages became more powerful, the modules and the organization thereof evolved. Most programs and languages, for example, make use of predefined bundled libraries of functions, which means that every time you want to perform a common task, say, like resizing a window on the screen, the programmer doesn’t have to write the code from scratch to make it possible when you need it—he only makes a call to the library. Likewise, object-oriented languages have modules that have “inheritance”—you can define “objects” of data or functions or both combined (which is how it’s usually understood), and use such objects to create offspring objects for particular uses. This greatly simplifies complex tasks, such as generating a graphical user interface.

Some modules are front end (e.g., generating windows) and some are back end (e.g., building a data base). Sometimes the front end is specific to an operating system and the back end is general—an example of this is your browser. The internet mostly runs (although not exclusively by any means) using something called the Xenix Standard Operating Environment, but your home computer probably runs on Windows, the current Mac OS, or Linux. If you have a Windows-based browser, it will not run on a Macintosh, but the World Wide Web (being the back end) it’s used to communicate with is the same for both Mac and PC. In other instances, the front end is general and the back end is specific to a particular computer architecture, as with, for example, the original object-oriented language/OS, SmallTalk, which looks and acts exactly the same on every machine using it, but the insides of which have to be tailored for the specific machine it’s running on.

The critical thing is that the front end and the back end have to be able to talk to each other for the program to work.

But all this talk of languages reminds me of another antipodal pairing in computer science, this one specific to language: high level and low level. High level means writing in an English-like computer language (like C or Pascal). This is essentially a very strict form of shorthand. A human programmer reading it will (mostly) understand it. Low level, on the other hand, means zeroes and ones—what programmers call machine language, what the computer is actually using to compute, and is complete gibberish to most humans. (There are also mid-level languages called assemblers, which fall in between, but let’s not get into that here.) A high level language is therefore similar to the front end, and a low level language to the back end.

Got that?

Now think about these things if you have a few moments of leisure before tomorrow, because that’s when I’m going to explore how these concepts relate to telling stories.