Differences between version 27 and predecessor to the previous major change of ProgrammingLanguage.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 27 | Last edited on Sunday, August 15, 2004 11:30:01 pm | by AristotlePagaltzis | Revert |
| Older page: | version 22 | Last edited on Wednesday, November 19, 2003 6:19:41 pm | by AristotlePagaltzis | Revert |
@@ -1,33 +1,49 @@
-;:
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
+
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.
!!! Very high level general purpose languages
+
+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.
<?plugin BackLinks page=CategoryVeryHighLevelProgrammingLanguages noheader=1 ?>
!!! Machine oriented general purpose languages
+
+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 | JohnVonNeumann] 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.
<?plugin BackLinks page=CategoryMachineOrientedProgrammingLanguages noheader=1 ?>
+
+[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.
!!! Systems programming languages
-These languages are designed for low-level software: drivers, OperatingSystems
, game engines, any code that has to go really fast. They tend to be simplistic
languages that closely follow the [VonNeumann | JohnVonNeumann] architecture [CPU]s are based on which allows skilled programmers to predict
and control exactly how their code will be executed
.
+These languages are designed for low-level software: drivers, [OperatingSystem]s
, 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
.
<?plugin BackLinks page=CategorySystemsProgrammingLanguages noheader=1 ?>
-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 everthing
up from time to time -- not something you want your OperatingSystem to do. [Modula2] is the exception to this rule.
+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.
!!! Imperative programming languages
+
+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.
<?plugin BackLinks page=CategoryImperativeProgrammingLanguages noheader=1 ?>
!!! Functional programming languages
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. Therefor
, 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 shortcircuiting
their execution by looking
up the return value of a previous call to a computationally expensive function for the same set of arguments in a cache
. It
also allows the computer to execute all parts of the program in arbitrary order to arrive and
the desired result.
+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
.
<?plugin BackLinks page=CategoryFunctionalProgrammingLanguages noheader=1 ?>
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.
@@ -35,23 +51,27 @@
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.
!!! Object oriented programming languages
-As that page, 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. The following languages are ones which do support this style directly:
+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:
<?plugin BackLinks page=CategoryObjectOrientedProgrammingLanguages noheader=1 ?>
!!! Obfuscated languages
-These languages are not intended to be used for serious work, but to stretch the brain.
+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
.
<?plugin BackLinks page=CategoryObfuscatedProgrammingLanguages noheader=1 ?>
You might also be interested in PolyGlot.
!!! Special purpose languages
+
+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.
<?plugin BackLinks page=CategorySpecialPurposeProgrammingLanguages noheader=1 ?>
!!! Deprecated languages
+
+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 that were implementation languages of choice in certain areas in the past have left behind a large legacy of code written in them that needs to be maintained. (Some programmers would still consider selling their body sooner than working in these languages.)
<?plugin BackLinks page=CategoryDeprecatedProgrammingLanguages noheader=1 ?>
