Like any­thing, learn­ing is an ongo­ing process that is never truly fin­ished, “A fool who rec­og­nizes his own igno­rance is thereby in fact a wise man, but a fool who con­sid­ers him­self wise — that is what one really calls a fool.” — Gau­tama Bud­dha. It takes time to grasp the con­cepts of the com­puter pro­gram­ming and then a con­tin­ual pur­suit of learn­ing to stay abreast the lat­est tech­niques and trends.

To be can­didly hon­est this arti­cle will not make you a pro­gram­ming mas­ter how­ever, it is my sin­cer­est hope that this arti­cle will give you an under­stand­ing of the con­cepts of com­puter pro­gram­ming. In order to begin to under­stand any pro­gram­ming lan­guage you need to wrap your brain around some concepts.

Con­cept 1: Under­stand­ing Logic

Logic is unwa­ver­ing, unbi­ased and bla­tant. Logic is on or off, 1 or 0, black or white; each choice or deci­sion being pre­cip­i­tated by the result of the pre­vi­ous choice or deci­sion and is made with­out emo­tion or judg­ment. It begs the ques­tion, “where did the first log­i­cal deci­sion come from then”? Sorry, this isn’t a philo­soph­i­cal arti­cle (but most seri­ous pro­gram­mers tend to be a bit philo­soph­i­cal). Logic is a core com­puter pro­gram­ming con­cept that tran­scends all com­puter pro­gram­ming lan­guages and is the foun­da­tion which allows us as peo­ple to cre­ate com­puter pro­gram­ming languages.

Con­cept 2: Under­stand­ing Com­pound Logic

Com­pound logic sim­ply put is, ‘logic com­pounded together”. Com­pound logic is 1 or 0 AND black or white, on or off AND up or down. Com­pound logic is mul­ti­ple logic deci­sions work­ing har­mo­niously together to pro­duce a sin­gle log­i­cal result. Com­pound logic can be com­bined with other com­pound logic to pro­duce, ‘com­pounded com­pound logic’.

Con­cept 3: The dif­fer­ence between com­piled and inter­preted languages

All com­puter pro­gram­ming syn­tax regard­less of ori­gin must be reduced to a form that the com­puter will under­stand called, ‘machine lan­guage’ before the com­puter can run or ‘exe­cute’ the syn­tax. There are two approaches to this require­ment, com­pi­la­tion or inter­pre­ta­tion. A com­piled pro­gram­ming lan­guage is a lan­guage that has a util­ity that takes your fin­ished syn­tax and com­piles it into machine lan­guage, usu­ally into the form of a file that the com­puter can exe­cute (with respect to the oper­at­ing sys­tem your using) such as; ‘.exe’, ‘.com’ … etc. Com­piled lan­guages can pro­duce files that are self-contained and exe­cute inde­pen­dently of the pro­gram that cre­ated them.

Inter­preted lan­guages are essen­tially the same as com­piled lan­guages except in how their syn­tax is han­dled. Unlike com­piled lan­guages, inter­preted lan­guages DO require an exter­nal pro­gram (often made by the com­pany or per­son that cre­ated the pro­gram­ming lan­guage) that is respon­si­ble for inter­pret­ing your fin­ished syn­tax into machine lan­guage in an ‘on demand’ fash­ion.  To fur­ther explain, the inter­preter pro­gram is exe­cuted by the com­puter and inter­prets your fin­ished syn­tax and trans­lates it into machine lan­guage so that the machine can under­stand it. The inter­preter pro­gram typ­i­cally does not save the inter­preted result (because the essen­tially would be com­pi­la­tion) and would need to re-interpret the syn­tax the next time it is executed.

Both meth­ods pro­duce the same end result, machine lan­guage. Com­piled and inter­preted lan­guage have their own pros and cons but an expla­na­tion beyond that gets us into another arti­cle altogether.

Con­cept 4: The dif­fer­ence between pro­ce­dural and event response programming

The dif­fer­ence between pro­ce­dural and event response pro­gram­ming has a lit­tle to do with the con­straints placed on the pro­gram­mer by what fea­tures the lan­guage sup­ports but by in large has to do with the per­sonal style of the pro­gram­mer writ­ing the syntax.

Pro­ce­dural pro­gram­ming in my opin­ion is sym­bolic to Eng­lish read­ing, top to bot­tom and left to right. It is a ‘steps’ ori­ented way of writ­ing syn­tax. An exam­ple of pro­ce­dural pro­gram­ming is akin to a chore list;

1. Do abc
2. Do def
3. If def can’t be done do ghi oth­er­wise do jkl
4. Do xyz

Pro­ce­dural pro­gram­ming lends itself to being eas­ily read because of its more sim­plis­tic appear­ance (ver­sus it’s event response coun­ter­part) but gen­er­ally rep­re­sents a less than effi­cient way of writ­ing syn­tax. Over the course of an entire program’s writ­ten syn­tax, a pro­ce­dural style of writ­ing will lend the pro­gram­mer to poten­tially dupli­cat­ing syn­tax rather writ­ing reusable and more effi­cient syn­tax. It is gen­er­ally uncon­tested that a pro­ce­dural style of writ­ing syn­tax rep­re­sents an ‘old school’ way of programming.

Event response pro­gram­ming is like going to the library to select a par­tic­u­lar book on a par­tic­u­lar sub­ject for a par­tic­u­lar pur­pose. Rather than select­ing the library’s entire col­lec­tion of cook­books and then decid­ing 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 cook­ing. The end result is less over­head, now you only have one or two books explic­itly related to your topic that your respon­si­ble for ver­sus the library’s entire col­lec­tion of cook­ing books.

Apply­ing the library exam­ple to com­puter pro­gram­ming; rather than load all the resources and syn­tax into one lump (in the case of pro­ce­dural pro­gram­ming) we fractional-ize the syn­tax in to log­i­cal ‘classes’.  These ‘classes’ con­tain class mem­bers and each mem­ber of a par­tic­u­lar class is gen­er­ally related in some man­ner to other mem­bers of the same class. These class mem­bers are called, ‘methods’.

When our pro­gram is exe­cuted it waits for input or an ‘event’ to respond to. Based on dif­fer­ent fac­tors of the event our pro­gram now has the right infor­ma­tion to know what class and class meth­ods to use in order to prop­erly han­dle or respond to the event. An event exam­ple could be a user typ­ing a sen­tence into a box and press­ing a but­ton and a response exam­ple could be a class and class method that makes sure every char­ac­ter in that sen­tence is lower case. Event response pro­gram­ming is a topic that is inches away from open­ing the doors to OOP or Object Ori­ented Pro­gram­ming, which I will reserve as a topic for another article!