Net by Matt

There are two basic ways that a program can be executed: continuously and event driven. The execution style is dictated by the programming language, and is almost always event driven.

In event driven code, nothing runs until there is a triggering event. This is often the user clicking a button, pressing a key, following a link on a web site, or it could be a machine generated event, such as data arrives on a port or a set amount of time has elapsed. In any case, once the triggering event happens, a portion of code is executed. In a calculator, for example, when the user presses the equals button, the corresponding portion of the program to add, subtract, multiply or divide is carried out.

Continuously executed programs run every line of code, from top to bottom, and then immediately begin executing at the top again. Every line of code has a distinct output that is updated on a more-or-less continuous basis, as long as the program and processor run sufficiently fast. The most basic type of this program is often referred to as “bit banging” and is often used in the programming of industrial equipment. It is called bit banging because these types of programs look at inputs from multiple single bit sources, often push buttons, position sensors or selector switches and based on the states of these inputs, turn on or off a single bit output. The code can often be broken down into several lines of if-then-else statements such as “if A or B are ON then turn ON C else turn OFF C.”

Interestingly, these two different styles of program execution, even though they are defined by the programming language, can be written in such a way that they behave as they other type of program. Consider the following lines of pseudo-code that are written in an event driven language:

Event (User Click)
While (1)
If A or B Then C Else D
If A and B Then E Else F
End While
End Event

The above program will execute continuously, even though the programming language is event driven. Strictly speaking, this code would “hang” the processor as it would be stuck in an infinite loop that only deals with inputs A and B. In reality, there is a supervisory program (an operating system in a computer, for example) that oversees everything that is going on and will pause the execution of this program and give processing time to other programs to keep everything running as expected.

Like the above example, a continuous execution program can be written to appear to execute as though it were event driven. Here is another pseudo-code example written in a continuous language.

If A then B
If B then C
If C then D

Even though all of these lines of code are executed over and over, the only way to get to D is to first trigger A, which triggers B and so on, in an event driven fashion.

One other interesting note, excluding the newer multi-core processor systems, any given processor can only execute one command at a time, and can only execute commands sequentially. The speed of a processor allows it to appear to handle multiple tasks at one.

After several years of programming in various languages for several different platforms there are several things I’ve come to realize about programming. I’ve broken it down into 3 separate topics, each with their own discussion. Each discussion will be added over the next few days.

The heart of any program is the algorithm that actually performs a task at hand. There are often plenty of auxiliary functions that typically must also occur in a program, but what makes each and every piece of software unique is how these functions are tied together to perform a task. Often the algorithm is the piece of code that requires the most debugging, the most attention to detail, and most importantly, a new and often creative idea. Auxiliary functions frequently are written by a third party, or in the case of many high level languages, may actually be features of the language itself. In PHP, as an example, there are functions available to query a database, write HTTP headers to a browser, read data from a web page or sort an array. All of these functions typically require no more than a line or two of code for them to perform a lot of work more or less automatically.

Let’s apply these functions to a basic model of the Google search engine. Things start off with a web crawler, an auxiliary function that gets a web page. The crawler then finds links on the page, opens them and continues on indefinitely.

The crawler feeds its data to Google’s algorithm called Page Rank. This is the core of their process. It counts up the number of links to a given page, and what context the page is linked to. Note that there are no pre-defined functions to handle this task, thus it is the main algorithm because it contains the new and creative idea mentioned above.

Next we move back to some auxiliary functions. The data that is generated by Page Rank is then stored in a database, another built in function in many programming languages. Then, when a user does a search, the database is queried and returns a response that contains pages that match the user’s input. Finally, this data is then sent to the user’s web browser, all of which can be handled by various functions that are already built into a programming language.

Please understand that this is a very simplified analysis of Google, and it was intentionally designed to show how an algorithm is a small part of an overall program, but is what makes every program unique.

Downloading videos from Youtube is easier than ever. Simply change youtube.com in the title bar to pwnyoutube.com when you’ve viewing a video. It will bring you to a page with the option to download either the standard quality or the high quality video. Just click one of the links to start downloading.