This is Programming as Überblick and should give a short and comprehensive overview that embraces a certain kind of superficiality. When you're new to programming, it might be interesting to get the whole picture before diving into excessive details that might or might not be confusing because of the new terminology.
Please feel free to correct and add what you think is necessary, but please do not extend this page with unnecessary detailed informations. If you feel that would be interesting, think about adding a link to a new page instead.
Programming Languages
At the beginning was ASM - Assembler. Assembler is also often called “Machine-Code”, because it is intended to be read by - well - machines. Assembler has instructions that are built into a chip. CPUs are Integrated Circuits that have the ability to do some basic calculations, for example adding two numbers would require the instruction add. Some higher level calculations require invoking many lower level calculations. Because the processing time can be measured per instruction, there are cheap calculations (e.g. multiplying by 2) or expensive calculations that may require some time (e.g. dividing by 1.23456789).
Assembler has the advantage that it’s very fast, but the massive disadvantage that it’s optimised to be read by machines and not humans. That’s why there are higher level languages. Usually, all of the following languages are either interpreted in a scripting environment and/or compiled to machine code. The computer is then processing the compiled machine code.
There are probably thousands of different languages, some are very ancient, some are brand new, some are complicated to learn, others very easy; some are rather abstract and some have been created to be similar to natural human language (mostly english). Some run very fast, some are painfully slow, some are perfect for 3D-renderings, other do amazing things with texts.
Before using a language, you might want to consider the strengths and weaknesses. You will find many resources on the internet. “You used {langName} to write WHAT?!” is a good starting point.
Aside all the obvious differences, all of these languages are using the same concepts and vary only in syntax, flavour and abstract design patterns.
If you understand these concepts, you’re ready to learn almost any programming language. In fact, you are probably even able to use them right away when you know about:
- Variables & Datatypes
- Functions
- Objects
Obviously there’s more…
…but that’s not so important for a general understanding, e.g.:
- Comments (//, /*, #)
- Operators
- Assignment Operator (=)
- Arithmetic Operators (+, -, /, * …)
- Logic and Binary Operators (==, !=, <, >, &&, !)
- String Concatenation Operators (+, .)
- …
- Statements and Expressions
- Flow Control
- Conditionals (if-then-else, switch-case, …)
- Loops (for, while, …)
- Design Patterns
- Coding and Naming Conventions
Variables
A variable…
- stores a value of a certain datatype
- has a local or global scope
- might be private or public (depending on the language)
- might be mutable or immutable (depending on the language)
- should have a descriptive name (by convention), typically like a property, like “name”, “color” or “isVisible”.
There are typed and untyped languages. An untyped language declares variables with no specific datatype, for example JavaScript:
var aNumber = 1; var aName = "Michael";
or PHP:
$aNumber = 1; $aName = "Michael";
a typed language must use specific datatypes for variables, for example C:
int aNumber = 1; char aName[] = "Michael"; // actually an array of chars
or Java:
int aNumber = 1; String aName = "Michael";
Some typed languages allow changing the type of a variable. This is called typecasting or just casting, e.g.
int aNumber = (int)aFloat;
There are primitive datatypes. These values are typically stored directly in a variable:
- BOOL
- int (byte, char, short, long)
- float (double)
and then there are complex datatypes. These values which are mostly “objects” are too large to fit inside a variable that has only one 8/16/32/64-bit size. Instead of storing a value, these variables contain an address that points to an address in the RAM (working memory) of the program, where the actual values are stored. But unless you’re coding in a C-flavoured language, you usually don’t have to worry about this.
An address in memory might look like this:
0xFFF212B44723AC23
Complex datatypes might be (e.g.):
- Arrays
- Strings
- Numbers (e.g. not differentiating between int or float)
- Objects (of all kind)
Functions
Functions are a very important concept, so important that there’s a name for programming using mainly/only functions (in contrast to object oriented programming, though it’s obviously not mutually exclusive): functional programming, which is ideally stateless (that means there should be little to no properties or global variables storing a specific state)
Functions…
- group functionality
- take zero or more arguments
- return nothing or something
- should be named verb-like (as a convention), because they do something, e.g. add(), count(), setup() or greetSomeone()
A function in JavaScript looks like this:
function functionName( paramA, paramB ) {
// do something
return something;
}
In typed languages, there is usually a return type (and argument types), for example in C you know that this function requires/accepts two arguments of type int and returns a number of type int:
int add( int a, int b ) {
return a + b;
}
Objects
Object-Oriented Programming (OOP) or object-based languages fill many shelfs in bookstores, but in the end, it all comes to this plain and basic concept:
Objects:
- encapsulate data, actions and behavior (some of it exposed and publicly visible, some of it private and internal)
- have
- Properties (=> Variables: what the object is/has)
- Methods (=> Functions: what the object can do)
- can be instantiated, that is: created in memory
- usually from a class (there is one class, but many instances)
- may inherit from their parents or to their children
- may expose public properties by Accessors (= Getter/Setter functions)
Now here’s a strange thing: Parents usually know about their children, but children should not know about their parents!
That’s a design pattern btw and if you think about it, it makes sense: Cross-references are a really bad thing. Well, at least in the nerdy world of programming. Not so much in the real world I suppose. Even though it’s still a valid metaphor.
Further Links
- The Hello World Collection
- Online Compiler
- For esoteric (fun!) languages there are JavaScript interpreters:
- Nerdy Joke …that you’re now able to understand :-)
This page is part of the Überblick course from Michael Markert at the University at Buffalo, State University of New York / Fall Term 2014.