If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is great, then the application is great. The user is pleased and there is harmony in the world.
[...]
The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.-- Geoffrey James, The Tao of Programming
A human-readable language to control computers. SourceCode written in a ProgrammingLanguage may either be compiled into a BinaryExecutable or ByteCode by a Compiler or executed directly by means of an Interpreter.
These languages are highly abstract compared to how the machine actually executes them. Data types and data structures in these languages are often encapsulated in a large shell of metainformation that the programmer never gets (and indeed never needs) to see, managed by the language implementation on the fly behind the scenes to accomodate the code's needs. These languages are designed to make it easy for the programmer to express the problem at hand without much red tape. The complete opposite to systems programming languages, they're highly preferable for userland applications that do not require execution speed over everything. Code written in these languages often is or can be much easier to maintain than a comparable lower level language implementation, if only due to its reduced size. Especially very simple tasks tend to have ludicruously high ratios of low level language code size to high level language code size.
These languages make no attempt to conceal the MachineCode's view of their data structures. Simple data types are directly derived from those the CPU supports, and the memory layout of complex data structures is usually known to the programmer. As the predominant CPU architecture is the VonNeumann architecture, they all follow its principles as well. They're also all imperative languages. Sometimes called "glorified AssemblyLanguage", it is generally the point of such languages to be compiled.
Java only barely fits this definition because it abstracts the memory layout away from the programmer (which is in fact its entire point), but is still here because its design is otherwise the same as that of any other machine oriented language.
These languages are designed for low-level software: drivers, OperatingSystems, game engines, any code that has to go really fast. They are necessarily compiled machine oriented languages and allow quite precise control of the resulting MachineCode.
Strangely, to date they tend to be very "unsafe" languages too. In code written in C, the systems programming language for Unix, it's easy to introduce tiny bugs that mysteriously screw everything up from time to time -- not something you want your OperatingSystem to do. Modula2 is the exception to this rule.
Code in these languages is a series of instructions for how the computer does its work (as opposed to functional languages where the computer figures out the sequence of instructions and declarative languages where the computer is only given facts and figures out everything for itself). Most widely adopted languages fall in this category, even if they're not explicitly listed here.
Functional programming is a paradigm based loosely on the LambdaCalculus approach to ComputerScience, in which everything in a program is a function.
In pure functional programming, there are no side effects; you cannot assign a value to a variable more than once, only return values from functions. Therefore, a function's return value depends only on the parameters passed. As a result, you can even mathematically prove the correctness of a program. You can also easily "memoize" functions, ie shortcircuit their execution by look up in a cache the return value of a previous call to a computationally expensive function for the same set of arguments. Purely functional programming also allows the computer to execute all parts of the program in arbitrary order to arrive at the desired result by using LazyEvaluation and PartialEvaluation?.
Programmers generally prefer imperative programming as they find it easier to understand and build practical applications with. Indeed, some things that depend on side effects and are easy in imperative programming are unreasonably hard to solve in pure functional programming - I/O is an example. However, problems that may seem terribly difficult in imperative programming are often trivial in pure functional programming.
It has been theorised this preference for imperative programming is a result of most people learning imperative programming languages (C++, BASIC, Java etc). If they even learn functional programming at all, it is usually much later and in much less depth, so they never really learn to think like a functional programmer. Perhaps if more programmers were taught to think in a functional style from their infancy we would see more applications written in functional languages.
As that page mentions, ObjectOrientation is mostly a style and only to an extent a paradigm of programming, and so need not be supported by a ProgrammingLanguage to write programs in object oriented fashion. Although applicable to any language, ObjectOrientation tends to be used to make modularization and code reuse easier mainly in imperative languages which inevitably suffer from a lack of complexity management mechanisms. The following languages are ones which do support this style directly:
These languages are not intended to be used for serious work, but to stretch the brain. They attempt to make programming difficult at least by making code very hard to read, sometimes also hard to write.
This selection is pretty small, although it contains the well-known, popular specimens. For a far more exhaustive treatment of the subject, check out the 
Esolang wiki.
You might also be interested in PolyGlot.
As the name implies, these languages apply mostly to a very small problem domain for which they are offer powerful abstractions. While often even turing complete, they are not intended to be used as general purpose languages. Trying to coerce them into such a role almost invariably results in impossibly unreadable code.
Basic is a high level languish.
APL is a high level anguish.
Don't learn these unless your idea of fun is something like stabbing yourself in the eyeball with a fork repeatedly. Or if you are in bad need for money, because some of them were implementation languages of choice in certain areas in the past and have left behind a large legacy of code that needs to be maintained. (Some programmers would still consider selling their body sooner than working in these languages.)
93 pages link to ProgrammingLanguage:
