1Taxonomies, Paradigms, and the Untangling of Terminology


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



Download 210.5 Kb.
Page7/8
Date31.07.2017
Size210.5 Kb.
#25081
1   2   3   4   5   6   7   8

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  

Download 210.5 Kb.

Share with your friends:
1   2   3   4   5   6   7   8




The database is protected by copyright ©ininet.org 2024
send message

    Main page