4.2Janossy/Samuels Taxonomy (CICS/ESA Primer, 1995, pp. 8-9)
Although there is no necessary connection between the traditional architecture [see Processing Modes, above] and the nature of programming tools used to build systems, the chronology of software development has caused some de facto associations between architecture and software. Traditional /mainframe/minicomputer/ “production” systems (those strategic applications run on a frequent periodic or continuous basis) tend to be constructed of procedural, third generation languages such as COBOL or PL/I, and are supported by indexed files, hierarchical (IMS), network (IDMS), or relational (DB2) databases. A procedural language forces the user to think through and encode every processing action needed to achieve an end purpose, such as every file access, processing sequence, and action. A nonprocedural language, on the other hand, allows the user to focus on input and output, while the nonprocedural language [programming environment] handles the processing analysis.
Except for DB2/SQL [which, by the way, many authors consider to be nonprocedural], procedural software suffers from significant inflexibilities. The software development lead times of third generation languages can appear excessive when contrasted with programming time requirements of modern nonprocedural languages on microcomputers. …
Programming in a modern nonprocedural language and sharing processing tasks between a host computer and powerful but inexpensive desktop equipment is a natural direction to explore.
4.3Eric Lebherz Taxonomy (“Hypernews Computer Language List”—http://www.hypernews.org/HyperNews/get/computing/lang-list.html) 4.3.1Procedural
which states how to compute the result of a given problem. Each statement in the language tells the computer to do something. A procedural program is “a list of instructions”. Encompasses both imperative and functional languages.
4.3.1.1Imperative
operates by a sequence of commands that change the value of data elements. Typified by assignments and iteration.
4.3.1.1.1Assembly
a symbolic representation of the machine language of a specific computer
4.3.1.2Functional (in the narrow sense)
operates on higher-order functions, building operators that manipulate functions directly without ever appearing to manipulate the data
4.3.2Declarative
operates by making descriptive statements about data and relations between data. The algorithm is hidden in the semantics of the language. This category encompasses both Applicative and Logic languages. Examples of declarative features are set comprehensions and pattern-matching statements.
4.3.2.1Applicative (a functional language in the broad sense)
operates by application of functions to values
4.3.2.1.1Definitional
an applicative language containing assignments interpreted as definitions
4.3.2.1.2Single Assignment
an applicative language using assignments with the convention that the variable may appear on the left side of an assignment only once within the portion of the program in which it is active
4.3.2.1.2.1Dataflow
language suitable for use on a dataflow architecture. Necessary properties include freedom from side effects, and the equivalence of scheduling constraints with data dependencies. Examples: Val, Id, SISAL, Lucid.
4.3.2.2Logic
deals with predicates or relationships. Logic languages try alternatives for each goal in succession, backtracking in a search for a common solution.
4.3.2.2.1Constraint
languages in which a problem is specified and solved by a series of constraining relationships
4.3.3Concurrent
describes programs that may be executed in parallel. This may be either: multiprogramming, sharing one processor, multiprocessing—separate processors sharing one memory distributed.
4.3.4Intermediate
a language used as an intermediate stage of compilation. May be text or binary.
4.3.5Metalanguage
a language used for the formal description of another language
4.3.6Query
an interface to a database
4.3.7Specification
a formalism for expressing a hardware or software design.
4.4http://cliki.tunes.org/Programming%20Languages 4.4.1Actor
The actor paradigm is a term for modelling computation with concurrent (possibly transparently-distributed) entities, the actors, that communicate with asynchronous messages. Actors may update their behaviour depending on the messages they receive.
See the pioneering works by Carl Hewitt, the developments by his successor Gul Agha, or by other fine people like Akinori Yonezawa. Actors have been rediscovered twenty years later by formal-methods people, yielding the join calculus. They have also been rediscovered by the industry, and a nice language that robustly implements the actor model is Erlang.
Actors are the real thing of which object-oriented programming is the caricature. When people say that OOP is based on an "intuitive" modelling of the world as objects in interaction, the intuition they invoke is the Actor model, but the actual model is a less-expressive version where only one object is active at a time, with a linear flow of control.
Pages in this topic: Salsa NetCLOS
4.4.2Collection-Oriented
The term for a paradigm of programming that involves operations on entire collections and avoids loops. Note that programming languages adherents to this paradigm are intrinsically suitable to both sequential and parallel/distributed execution.
-
Jay Sipelstein, Guy E. Blelloch, Collection-Oriented Languages , Proceedings of the IEEE, April 1991 (and CMU-CS-90-127).
-
Sergei Gorlatch, Christoph Wedler, Christian Lengauer Optimization Rules for Programming with Collective Operations , IPPS/SPDP'99, 1999.
-
skeletons archive (Bird-Meertens Formalism, functional data-parallelism) .
-
A book: Arrays, Functional Languages and Parallel Systems Lenore M. Restifo Mullin, Michael Jenkins, Gaetan Hains, Robert Bernecky, Guang R. Gao October 1991, Kluwer, ISBN 0-7923-9213-2, Hardbound.
-
Dr. Clemens Grelck 's Virtual Bookshelf , with a bibliography of papers related to collection-oriented techniques, notably:
-
Array Theory ;
-
Dense Arrays ;
-
Implementation of Arrays .
A list of collection-oriented programming languages:
-
A+
-
AML
-
APL
-
Claire
-
FALCON
-
FISh
-
Glee
-
J
-
K
-
NESL
-
NIAL
-
Q shell
-
R
-
SAC
-
SETL
-
SPARCL
-
{log}
Pages in this topic: SPARCL SETL SAC R Q shell NIAL NESL K J Glee FISh FALCON Claire APL AML A+ {log}
Also linked from: Haskell
4.4.3Functional
Functional Programming is the term for a powerful paradigm for programming that originates in the early works about lambda calculus: computations consist in evaluating/expanding structured expressions, rather than executing instructions, as with imperative programming.
Because functional programming has such simple semantics, it makes proving correctness of programs, to manipulate programs, to parallelize them, etc., relatively easy.
Functional perspectives work when there is a logical perspective that permits encapsulating side effects as results within some context or system; consequently the benefits described here are not trivial to achieve.
-
Why Functional Programming Matters , a famous essay explaining how higher-order functions and lazy evaluation can help in creating modular, well-designed programs, including examples.
-
LtU's functional programming topic .
-
The FAQ for comp.lang.functional
-
Claus Reinke's own little FP link
-
Real-World uses of functional programming languages.
-
The Journal of Functional Programming
-
There are fine functional programming groups at Glasgow , St Andrews, Rocquencourt, etc.
-
the SEL-HPC Functional Programming Archive
-
Purely Functional Data Structures , a great book by [Chris Okasaki]?.
-
John Hughes' collection of tutorials .
Pages in this topic: Sisal Scheme SAC RELFUN Qi Q Pike OCAML O'Haskell Needle NIAL NESL ML Lisp Lemon LIFE Joy JoCaml Hobbit Haskell Functional and Object-Oriented Forth FISh Escher Erlang Eden Curry Coq Clean Clarity Claire Charity Cayenne Category Theory Bla Better Scheme Amiga E Alice Aleph ALF
Also linked from: C++ Concatenative Syntax Continuation Continuation-Passing Style Declarative Dispatch Eugenio Moggi Fortran fxm Lambda Prolog Lambda VM Linear Logic Comments Microkernel Debate Monad PL 101 Python Referential Transparency and State Simon Peyton Jones
4.4.4Imperative
The term for a paradigm of programming that involves (mostly unconstrained) update of the state of a machine through direct instructions.
The vast majority of programmers seemingly prefer to use computers this way.
Pages in this topic: NIAL FISh Claire
Also linked from: Functional Referential Transparency and State
4.4.5Logic
Logic Programming is the term for a paradigm of programming that originates in the Curry-Howard Isomorphism, which relates types and proofs to terms and expressions. In most cases, logical deduction or inference is equated with term evaluation or state update.
-
Logic Programming at The WWW Virtual Library .
-
Formal logic via functional programming : a dissertation.
-
Termination inference , a kind of program analysis for logic programs.
-
Schelog3 [MIA].
-
SPIKE . From its readme:
The SPIKE system is an automatic theorem prover in theories presented by conditional equations. SPIKE was written in Caml Light, a functional language of the ML family.
Pages in this topic: Yarrow TyRuBa SPARCL Prolog NuPrl Mercury Maude Lambda Prolog LIFE Goedel Escher Dynamo Curry Claire CafeOBJ ASF+SDF ALF
Also linked from: Alan Bundy Axiom of Choice BOBJ Constraints Declarative Induction and Co-induction Janus NCL OBJ Family Quotienting Referential Transparency and State Scheme
4.4.5.1Constraints
The term for a paradigm related to logic or declarative programming, where information is specified as a constraint on the result, and the evaluator's task is to use this information to limit the search space that some base set of algorithms would ordinarily have traversed to find the answer.
Constraints-based programming languages are not as common as constraints-solving libraries, since in the general case there is no systematically-reliable approach to this kind of evaluation style.
Generally, constraints are an interesting type of annotation.
-
Constraint Logic Programming a short introductory article from BYTE magazine.
-
Constraints Archive .
-
constraint.org - A Site for Constraint Programming.
-
Guide to Constraint Programming .
-
The Constraint Computation Center (CCC) .
-
The Language List: constraint at Computer Science Department (Centre Universitaire d'Informatique - CUI), University of Geneva, no longer manteined but useful.
Pages in this topic: Screamer SPARCL NCL Morphe LIFE Janus Goedel AKL
Also linked from: Alice Garnet Microkernel Debate Mozart/Oz Type Systems Varieties
4.4.6Object-Oriented
A paradigm of programming.
There's a craze about any new software using the term "Object-Oriented". But if you ask people what it means to be "OO", most won't be able to tell anything, because it's only a buzzword.
The meaningful ideas that have to be isolated and distinguished behind this fad are that of having a unified way to manipulate objects, but few understand it even partially, and even fewer are those fully conscious of what it means.
Another buzzword associated to "OO" is inheritance, often incorrectly presented as the essence of "OO" design, whereas it is only a braindead special-case way of organizing objects, often done with a lot of confusion.
Typical confusion in "OO" approaches are between (constant) values and (variable) state-holders, between (semantical) objects and (meta-semantical) environments, between (specificational) abstraction level and (implementational) dispatch-time (run-time vs compile-time), etc. In a sane design, these concepts would be distinguished and made orthogonal; they would not even intervene at all at the same place in the semantics.
For instance, most "OO" languages (like Java, C++) can't distinguish the notion of a constant, absolute, value, as soon as this value is not "atomic" in the hardware (a curious limitation for alleged "high-level" languages); all objects are then modifiable records, which leads to all kinds of unsafety, bugs, and contortions when manipulating putatively constant recursive structures.
Languages with single-dispatch (among which are C++ and Java again) also confuse the objects being manipulated with the environment in which they are manipulated; they force the programmer to define the semantics of "an integer", or "a polynomial", whereas anyone with a little background in formal mathematics knows that an isolated integer or polynomial has no meaning; only the set of integers, or the set of polynomials, has meaning. More generally, isolated objects mean nothing, only structured sets of objects do; and these language don't allow to manipulate those sets, to describe their properties. Languages with multiple dispatch, such as CLOS or Cecil, do a better job of not associating environments to objects.
Even with multiple dispatch, all the widespread OO languages have a unique global environment to dispatch (multi)methods according to objects' class. This means that there is only one fixed way of looking at objects, whereas mathematicians will also tell you how the interesting properties of structures lie in the infinity of ways to isomorphically reformulate them. The only way round this unicity of view is the explicit wrapping of objects into new classes; but most languages do not allow generic wrappers, and/or impose restrictions in the specification and implementation of wrapped objects.
Kent M. Pitman has written a great essay about object-orientation as a term, What's in a name? Uses and Abuses of Lisp Terminology within his set of articles, Parenthetically-Speaking.
For true OO languages, see CLOS, Beta, Dylan, Self, Smalltalk, Java, OCAML.
For languages with true OO extensions, see Lisp, Perl, Scheme, Forth.
For false OO languages, see Ada, C++, Visual BASIC, Simula.
-
The great Cetus links .
-
Bob Hathaway's OO FAQ .
-
The FOOL workshop proceedings.
-
Copying and Comparing: Problems and Solutions , a paper dealing with the issue of identity and value semantics in the paradigm.
Pages in this topic: kew TOM Slate Simula Self Ruby Python Pike Obliq Objective-C OCAML O'Haskell NetCLOS Needle Mozart/Oz Morphe LIFE LENS Io Hobbit Haskell Goo Functional and Object-Oriented Ellie Eiffel Eidola E Dylan Claire Cecil CLOS Amiga E Agora ABCL
Also linked from: Actor Aldor Benjamin J. Pierce C++ CLIM Combining Languages Dispatch FramerD Hidden Algebra Java Luca Cardelli Object OO OZONE RbCl Scheme Unified Unity Project XOS
4.4.7Relational
The term for a paradigm of programming where relationships between objects are formalized as Relation objects. The few languages in this category generally adhere to relational algebra or some subset of it.
-
The Relational Methods in Computer Science ("RelMiCS") home page .
-
RATH , a Relational Algebra Toolkit in Haskell, which also covers more general things like category theory concepts.
Pages in this topic: RELFUN Libra
Also linked from: Feature-Oriented Programming
Share with your friends: |