Janossy/Samuels Taxonomy (CICS/ESA Primer, 1995, pp. 8-9)

4.4.2Collection-Oriented

• 
  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+
  
• 
  AML
  
• 
  APL
  
• 
  Claire
  
• 
  FALCON
  
• 
  FISh
  
• 
  Glee
  
• 
  J
  
• 
  K
  
• 
  NESL
  
• 
  NIAL
  
• 
  Q shell
  
• 
  R
  
• 
  SAC
  
• 
  SETL
  
• 
  SPARCL
  
• 
  {log}
  

4.4.3Functional

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 .
  

4.4.4Imperative

The vast majority of programmers seemingly prefer to use computers this way.

4.4.5Logic

• 
  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:
  

4.4.5.1Constraints

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.
  

• 
  UW Cassowary Constraint Solving Toolkit .
  

4.4.6Object-Oriented

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.

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.
  

4.4.7Relational

• 
  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.