Computer Programming Concepts

Concept 1: Understanding Logic

Logic is unwavering, unbiased and blatant. Logic is on or off, 1 or 0, black or white; each choice or decision being precipitated by the result of the previous choice or decision and is made without emotion or judgment. It begs the question, "where did the first logical decision come from then"? Sorry, this isn't a philosophical article (but most serious programmers tend to be a bit philosophical). Logic is a core computer programming concept that transcends all computer programming languages and is the foundation which allows us as people to create computer programming languages.

Concept 2: Understanding Compound Logic

Compound logic simply put is, 'logic compounded together". Compound logic is 1 or 0 AND black or white, on or off AND up or down. Compound logic is multiple logic decisions working harmoniously together to produce a single logical result. Compound logic can be combined with other compound logic to produce, 'compounded compound logic'.

Concept 3: The difference between compiled and interpreted languages

All computer programming syntax regardless of origin must be reduced to a form that the computer will understand called, 'machine language' before the computer can run or 'execute' the syntax. There are two approaches to this requirement, compilation or interpretation. A compiled programming language is a language that has a utility that takes your finished syntax and compiles it into machine language, usually into the form of a file that the computer can execute (with respect to the operating system your using) such as; '.exe', '.com' ... etc. Compiled languages can produce files that are self-contained and execute independently of the program that created them.

Interpreted languages are essentially the same as compiled languages except in how their syntax is handled. Unlike compiled languages, interpreted languages DO require an external program (often made by the company or person that created the programming language) that is responsible for interpreting your finished syntax into machine language in an 'on demand' fashion. To further explain, the interpreter program is executed by the computer and interprets your finished syntax and translates it into machine language so that the machine can understand it. The interpreter program typically does not save the interpreted result (because that essentially would be compilation) and would need to re-interpret the syntax the next time it is executed.

Both methods produce the same end result, machine language. Compiled and interpreted language have their own pros and cons but an explanation beyond that gets us into another article altogether.

Concept 4: The difference between procedural and event response programming

The difference between procedural and event response programming has a little to do with the constraints placed on the programmer by what features the language supports but by in large has to do with the personal style of the programmer writing the syntax.

Procedural programming in my opinion is symbolic to English reading, top to bottom and left to right. It is a 'steps' oriented way of writing syntax. An example of procedural programming is akin to a chore list;

1. Do abc
2. Do def
3. If def can't be done do ghi otherwise do jkl
4. Do xyz

Procedural programming lends itself to being easily read because of its more simplistic appearance (versus it's event response counterpart) but generally represents a less than efficient way of writing syntax. Over the course of an entire program's written syntax, a procedural style of writing will lend the programmer to potentially duplicating syntax rather writing reusable and more efficient syntax. It is generally uncontested that a procedural style of writing syntax represents an 'old school' way of programming.

Event response programming is like going to the library to select a particular book on a particular subject for a particular purpose. Rather than selecting the library's entire collection of cookbooks and then deciding what you want to cook, you first decide what you want to cook and then select one or two book(s) from the library that cover the genre of food that you are cooking. The end result is less overhead, now you only have one or two books explicitly related to your topic that your responsible for versus the library's entire collection of cooking books.

Applying the library example to computer programming; rather than load all the resources and syntax into one lump (in the case of procedural programming) we fractional-ize the syntax in to logical 'classes'. These 'classes' contain class members and each member of a particular class is generally related in some manner to other members of the same class. These class members are called, 'methods'.

When our program is executed it waits for input or an 'event' to respond to. Based on different factors of the event our program now has the right information to know what class and class methods to use in order to properly handle or respond to the event. An event example could be a user typing a sentence into a box and pressing a button and a response example could be a class and class method that makes sure every character in that sentence is lower case. Event response programming is a topic that is inches away from opening the doors to OOP or Object Oriented Programming, which I will reserve as a topic for another article!