Why do people still use goto?

Can I ask you a question? Yeah you, with the keyboard and mouse! I need to ask you something very important to our your career. You write code, right? I don’t care which platform or language you use. We’ll get to that in a moment. Are you a developer? That’s my main question. You write programming logic don’t you? You do? (If you don’t goto end of post.) Great! Keep reading!

What language do you use?
Don’t shout it out yet! Hold your responses until the end when there’s time to key in the little square thingy. But answer this. What language do you code in? Why? Does it make you feel productive? Why do you feel productive working with [insert name of your preferred language here]?

Responses will range from closures support to web browser friendly, to multi-platform I’m sure. Here’s the real answer… the one everyone really feels but hardly any one pays attention to. It’s closer to your native language than… The actual reason there are so many programming languages is the same reason there are so many spoken languages and variants. People feel the need to express themselves. Believe it or not, there’s probably a twist in your programming tools of choice that allow you to express yourself in a particular way. If you’re like me, and forced to work in a particular language then you’ve probably devised or thought of devising your own.

I don’t care about none of that!
Wait! There are those of you who take the mechanical approach to software design. Maybe your an occasional developer that doesn’t have the experience of coding every day and slogging through mounds of logic. Maybe you’re not as obsessed with the programming as you are with the end result. Maybe you’re brand new to development and you don’t quite get all the conceptual mumbo-jumbo behind it. Whatever the case, you just don’t care about the art of programming. It’s just the thing that gets in the way of the sound and graphical output of what you really care about. You see code as the input and an application as the output and it really doesn’t matter what shape/color the code comes in. Keep reading fellah, this still applies to you.

Programming is all about expressing human concepts and interactions in a form that a machine can follow. When it comes down to it, a machine can only follow on or off or a continuous stream of ones and zeroes. The code we provide must be converted to this stream before anything happens. The exception, of course, being interpreted programming but I’ll get to that in a second. Very few people provide computers directly with swaths of ones and zeroes with which to follow, and why? Keying a large array of randomly alternating digits is counter productive. It doesn’t map back to the human intention. There are a select few who would argue, “I’ve implemented my own kernel using assembly and I found it very productive as I can run old computers at nearly twice the speed of modern computers.” In these cases the computer was still not provided with the alternating array of what’s essentially boolean values. A slightly higher level grammar is used.

Higher Level Grammar Abstraction
High level grammars provide a means of abstraction from the actual mechanics of a machine. We use them all the time. They are all designed with one purpose, one goal. To provide an abstraction for the thing they control. All compiled languages as well as interpreted languages fall under this umbrella. Whether you’re controlling the output of machine code, or the execution of abstract steps or logic (as with interpreted systems) on a machine you use a high level grammar to do so. Coding “SBA” is a small abstraction over “0x10” which is shorthand for “00001100”.

if(a!=b) {
   a = b;

…is an abstraction over the following (loosely guessed following an assembly table):


The point in all of this is that you can’t just tell the machine, “Go do this count-down thing and while you’re at it show a picture of what’s sitting in front of you.” We’d like to speak that naturally. Maybe in few few decades it will be a reality. But currently we’re building up a stack of abstractions that will ultimately get us there. In the last case above we use mnemonics to remind us what the instruction does. It’s a small abstraction that always ties a specific command to a single numeric instruction. The one to one relationship leaves us programming in a very mechanical way. In the case preceding the assembly code we have a higher set of abstractions defined, each of which is a command or statement that can be interpreted into one or more assembly instructions. The benefit is that we have abstraction over the mechanical expressiveness of assembly and possibly abstractions over the machine we are programming since assembly can be CPU/machine specific it pains us to have to think about which set of commands to use each time. There is another benefit in that some of the commands or statements can begin to match closer to the grammar we use in everyday life. When was the last time you told your buddy Rob, “Say man… go PSH(B) then CMP(A) and finally BNE. Ok cuz?” However you may have said “Rob, if the money I allocated to my first account is more than what I have in my second account make them equal because I need to be sure I have enough cash for this vacation.” This reads somewhat similar to:

if(firstAccount.balance()>secondAccount.balance()) {
   double anAmountToTransfer = firstAccount.balance()-secondAccount.balance()
   firstAccount.transferTo(secondAccount, anAmountToTransfer);

Who’s reading your source code?
That brings me to the final point I wanna make. Why do we write in any programming language? Does the machine really care if we use semicolons to terminate each statement? Do you think the compiler cuddles up with the pages of your source code at night and reads itself to sleep? Are we all authors working on the next best seller like “Twilight” or “The Girl With The Dragon Tatoo”? The purpose of source code is two fold. It forms the instructions of what the machine is to do and it leaves a history or documentation for what we wish the machine to do. Then when our intentions don’t match the actual behavior of the application, we (people) pick up the source code then decide where the disconnect (intention vs. execution) is. Here’s a disturbing fact that I bet you don’t think about. You read, at a minimum, twice as much source code as you write in any given day. By nature, you are a source code interpreter. So the next time you are tempted to tell someone about your occupation, instead of “programmer” tell them you are an “interpreter”.

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