We control computers by writing code that is executed by the central processing unit (CPU).

With an increasing degree, this code models the functions performed by the computer and its parts, and how they work together. Such code has a syntax and semantics which together comprise a computer language. Computer languages have during the last 50+ years undergone big changes. They have become easier to use, more expressive and more structured than the first generations.

First Generation
Code of the first generation programming language [G1] was entered through physical switches on the computer and involved commands to move data bits to and from registers, compute on these and more. A sequence of such commands is known as code. Specifically, code that a machine can read and understand according to its logical design is called machine code [M1], which is in contrast to human readable code. The first generation of programming languages is all about machine code. Such code give fast executions but is tedious to write and is brittle [C1] to changes. Second Generation

Improves on first generation by providing code as human readable source code with logically structures. The source code must be assembled into machine code before it can be executed by a CPU. This assembly step is done by anassembler.
Such languages are sometimes still used for kernels and device drivers, i.e. the core of the operating system and for specific machine parts. More often, such languages are used in areas of intense processing, like graphics programming, when the code needs to be optimized for performance. 2GL source code is not portable across processors or processing environments. Third Generation

Improves on second generation by making a language architecture independent, i.e. no longer tailored to the processor or environment, which requires a compiler to make machine code for the CPU. Some, like Java, make use of an intermediate code which is run by a virtual machine, reaching further architecture independence. In such a case, only the virtual machine needs to be run by something that is architecture specific. This generation support structured programming. Fourth Generation Improves on 3GL and their development methods with higher abstraction and statement power, to reduce errors and increase development speed by reducing programming effort. A 4GL is designed with a specific purpose in mind. This offers a high potential. 4GL are not always

successful, sometimes resulting in inelegant and unmaintainable code. However, given the right problem, the use of an appropriate 4GL can be spectacularly successful.

Examples: Oracle Forms, PL/SQL, Revolution language, SAS, SPSS, SQL Fifth Generation Improves on the previous generations by skipping algorithm writing and instead provide constraints.
While 4GL are designed to build specific programs, 5GL are designed to make the computer solve a given problem without the programmer. This way, the programmer only needs to worry about what problems need to be solved and what conditions need to be met, without worrying about how to implement a routine or algorithm to solve them. [G5] Examples: Prolog, OPS5, Mercury

Machine Language

Sometimes referred to as machine code or object code, machine language is a collection of binary digits or bits that the computer reads and interprets. Machine language is the only language a computer is capable of understanding.
While easily understood by computers, machine languages are almost impossible for humans to use because they consist entirely of numbers. Programmers, therefore, use either a high-level programming language or an assembly language. An assembly language contains the same instructions as a machine language, but the instructions andvariables have names instead of being just numbers. Programs written in high-level languages are translated into assembly language or machine language by acompiler. Assembly language programs are translated into machine language by a program called anassembler. Every CPU has its own unique machine language. Programs must be rewritten or recompiled, therefore, to runon different types of computers.

Assembly Language
An assembly language is a low-level programming language for a computer, or other programmable device, in which there is a very strong (generallyone-to-one) correspondence between the language and the architecture's machine code instructions. Each assembly language is specific to a particular computer architecture, in contrast to most high-level programming languages, which are generally portable across multiple architectures, but require interpreting or compiling. Assembly language is converted into executable machine code by a utility program referred to as an assembler; the conversion process is referred to as assembly, or assembling the code.

Difference between Assembly and Machine

Machine Language:It is in the form of 0's and 1's which can easily be understood by the computer. It is hard to work on it for the human beings. It does not need any language translator. Assembly Lanugage: It consists of of short symbolic phrases called Mnemonic understood by people. These symbols are constructed for all operations by letters and symbols. Such as Add, Mul and Hlt are mnemonics each of these has its own operation code such as 0000101, 000100, 000000 respectively. A translator Assembler is required to convert assembly language into machine codes.

Low-Level
Of all of the categories, its probably easiest to define what it means to be a low-level language. Machine code is low level because it runs directly on the processor. Low-level languages are appropriate for writing operating systems or firmware for micro-controllers. They can do just about anything with a little bit of work, but obviously you wouldnt want to write the next major web framework in one of them (I can see it now, Assembly on Rails).

Characteristics

Direct memory management Little-to-no abstraction from the hardware Register access Statements usually have an obvious correspondence with clock cycles Superb performance

C is actually a very interesting language in this category (more so C++) because of how broad its range happens to be. C allows you direct access to registers and memory locations, but it also has a number of constructs which allow significant abstraction from the hardware itself. Really, C and C++ probably represent the most broad spectrum languages in existence, which makes them quite interesting from a theoretical standpoint. In practice, both C and C++ are too low-level to do anything enterprisy.

Mid-Level

This is where things start getting vague. Most high-level languages are well defined, as are lowlevel languages, but mid-level languages tend to be a bit difficult to box. I really define the category by the size of application I would be willing to write using a given language. I would have no problem writing and maintaining a large desktop application in a mid-level language (such as Java), whereas to do so in a low-level language (like Assembly) would lead to unending pain. This is really the level at which virtual machines start to become common-place. Java, Scala, C# etc all use a virtual machine to provide an execution environment. Thus, many mid-level languages dont compile directly down to the metal (at least, not right away) but represent a blurring between interpreted and compiled languages. Mid-level languages are almost always defined in terms of lowlevel languages (e.g. the Java compiler is bootstrapped from C).

Characteristics

High level abstractions such as objects (or functionals) Static typing Extremely commonplace (mid-level languages are by far the most widely used) Virtual machines Garbage collection Easy to reason about program flow

High-Level
High-level languages are really interesting if you think about it. They are essentially mid-level languages which just take the concepts of abstraction and high-level constructs to the extreme. For example, Java is mostly object-oriented, but it still relies on primitives which are represented directly in memory. Ruby on the other hand iscompletely object-oriented. It has no primitives (outside of the runtime implementation) and everything can be treated as an object. In short, high-level languages are the logical semantic evolution of mid-level languages. It makes a lot of sense when you consider the philosophy of simplification and increase of abstraction. After all, people were n times more productive switching from C to Java with all of its abstractions. If that really was the case, then cant we just add more and more layers of abstraction to increase productivity exponentially? High-level languages tend to be extremely dynamic. Runtime flow is changed on the fly through the use of things like dynamic typing, open classes, etc. This sort of technique provides a tremendous amount of flexibility in algorithm design. However, this sort of mucking about with execution also tends to make the programs harder to reason about. It can be very difficult to follow the flow of an algorithm written in Ruby. This obfuscation of flow is precisely why I dont think high-level languages like Ruby are suitable for large applications. Thats just my opinion though.

Characteristics

Interpreted Dynamic constructs (open classes, message-style methods, etc) Poor performance

Concise code Flexible syntax (good for internal DSLs) Hybrid paradigm (object-oriented and functional) Fanatic community

Oddly enough, high-level language developers seem to be much more passionate about their favorite language than low- or mid-level developers. Im not entirely sure why it has to be this way, but the trend has been far too universal to ignore (Python, Perl, Ruby, etc). Ruby is of course the canonical example of this primarily because of the sky-rocket popularity of Rails, but any high-level language has its fanatic evangelists. Whats really interesting about many high-level languages is the tendency to fall into a hybrid paradigm category. Python for example is extremely object-oriented, but also allows things like closures and first-class functions. Its not as powerful in this respect as a language like Scala (which allows methods within methods within methods), but nevertheless it is capable of representing most elements of a pure-functional language. As an aside, high-level languages usually perform poorly compared with low- or even mid-level languages. This is merely a function of the many layers of abstraction between the code and the machine itself. One instruction in Ruby may translate into literally thousands of machine words. Of course, high-level languages are almost exclusively used in situations where such raw-metal performance is unnecessary, but its still a language trait worth remembering.

Conclusion
Its important to remember that Im absolutely not recommending one language or level over another for the general case. The very reason we have such a gradient variety of language designs is that there is a need for all of them at some point. The Linux kernel could never be written in Ruby, and I would never want to write an incremental backup system in Assembly. All of these languages have their uses, its just a matter of identifying which language matches your current problem most closely.