What Isa Paradigm
What Isa ParadigmWikipedia (http://en.wikipedia.org/wiki/Paradigm) essentially says:
We nonetheless have someone here with the firm opinion that they are synonymous, who has made many comments which created much heat but little light, starting with:
This matches the three classical paradigms as well as the multitude of more specific ones.
Survey of 30 paradigms and how to make many paradigms work together in a language (from the esteemed author of ConceptsTechniquesAndModelsOfComputerProgramming, PeterVanRoy): http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
Peter describes: a language provides a set of paradigms, and a paradigm composes a set of concepts. Concepts are primitive forms like named state or expression of concurrency.
From ProgrammingParadigm:
This table [of paradigms] is a horrible mixup of completely different concepts. There are only three classic programming paradigms:
That's it! Everything else is built on one of these three paradigms (Functional, Imperative and Logic), sometimes incorporating elements of others. The word "paradigm" has lost all meaning in computer science because everybody and his dog wants to invent an new paradigm. The collection on ProgrammingParadigm should be called something else (I vote for "crap").
No, ThereAreExactlyThreeParadigms. However, these days so called programmers abound, who have never actually seen a functional or logic programming language. It's these less-than-well-educated guys who cannot decide how many paradigms there are. Of course, sales people who feel a need to sell yet another IDE as "supporting $PARADIGM" are not entirely without guilt, either.
Can you supply a definitive reference that defends these three, and only these three, as being programming paradigms while the others are not? Can you supply rigorous definitions for the three paradigms ("where the value of an expression is computed???" - not many languages or paradigms don't do this) and can you provide the rules which determine that the above three are paradigms whereas (say) GenerativeProgramming or ConstraintProgramming is not?
Definite reference? How about ''every single introductory programming course ever held after about 1972?!''
I agree there probably isn't a single (useful) language that isn't based on one or more of these principles (though I question "logic programming"), but what part of the definition of "programming paradigm" precludes including other principles? Does it say somewhere that only the root of the guiding-principle tree can be a paradigm?
Typical introductory programming courses are hardly semantically rigorous. It's generally not until final year or grad school that the meanings of programming paradigms are tackled in any depth (if at all), and then it's observed that the boundaries between them are amorphous, and their conventional meanings ambiguous and lacking in rigour. One can try to impose some rigour; you can say that pure functional programming is lambda calculus with implicit sequence and no side-effects or dynamic state, or that imperative programming is explicit sequential instructions with dynamic state, or that declarative programming is a non-sequential description of the desired solution. Or something. But once you do this, you quickly find that almost no useful languages (except some pedagogical tools) belong to any one paradigm. Furthermore, once you try to classify notions like ConstraintProgramming, you find that "programming paradigm" lacks a firm definition, let alone a rigorous formalism, by which we can distinguish paradigm from non-paradigm. Again, what in the definition of the term "programming paradigm" - other than what appears to be historical convention - allows us to declare that implementing lambda calculus is a paradigm but implementing relational algebra is not?
"Ah hah," you say, "lambda calculus is a computational model like Turing machines, but relational algebra is not!" Okay, but is logic programming or declarative programming a computational model? No? Then why lump these together with functional and imperative approaches? And are visual programming languages (like ProGraph? or LabView) a paradigm unto themselves, or are they not? If so, why? If not, why? And so on.
MARK
I'm not saying it's impossible to come up with a rigorous, characterising definition of "programming paradigm" - or even that there aren't essential intuitive differences between so-called paradigms - but attempts to do so usually turn into LaynesLaw debates like this one. One person will declare that use of relational algebra is not paradigmatic because it is implemented in a functional or declarative style. Another will claim that it is paradigmatic because programming paradigms are based on mathematical formalisms, and relational algebra is a mathematical formalism. Another will claim that a programming paradigm is any identifiable concept a programming language can be based on, thus making (say) "object oriented" a paradigm. Someone else will claim that the only paradigms are those based on computational models. Another will claim that "programming paradigm" is meaningless, because useful languages are a mix of paradigms. Some will say "paradigm" is based on syntax, others will say syntax is immaterial because it's the underlying model that matters. Do you see the problem here? The debate lies not in your (or anyone's) choice of fundamental paradigms, but with the definition of "programming paradigm" itself, which is subject to interpretation.
(I'd bring a proof myself, but for obvious reasons I cannot supply an exhaustive list. Here's a start: C, C++, C#, Java, Pascal, Basic, Algol, Ada, Smalltalk, Forth, Perl, Python, Ruby, Tcl - all imperative (use variables and assignments; yes, even Smalltalk does). Haskell, Ocaml, ML, Scheme, Unlambda, Lisp - all functional (reduce expressions). Prolog, Mercury - all logical (satisfy expressions using backtracking). You may claim that the distinction is nor entirely clear, and I'd admit especially Forth as a weird imperative/functional hybrid, and still all programming languages have a primary paradigm and it is always one of these three.)
A list of examples is not a proof, and I'd argue that Forth is clearly imperative while LISP is a weird imperative/functional hybrid (e.g., is progn functional or imperative?) But that just hilights my point. My problem is not with the presumed existence of these so-called paradigms, or even that two of your three may be foundational approaches - though I'd argue that "logic programming" is a mere subset of the declarative approach. My problem is that they only have limited descriptive power at an abstract level, or in terms of identifying certain features of a given language, but are not meaningful in terms of whole languages. As such, I'd challenge you to identify a single language, aside from pedagogical tools, that do not contain elements of at least two, and usually all three approaches. For example, JavaScript supports first-class functions, anonymous functions, imperative instructions, and even declarative elements. A static "class" definition, for example, is arguably a passive declarative construct. Another example, LISP, is sufficiently flexible to be simultaneously declarative, functional, and imperative. How much does a language have to embody a given approach before we say it belongs to a given paradigm? 75%? 50%? How do we measure it in the first place? Many languages contain other approaches (e.g., relational, deductive, etc.) as well. On what basis do we exclude them from, or include them in, paradigm-hood? Again, the problem is that the term "programming paradigm" has no firm definition, let alone a rigorous formalism, by which we can distinguish paradigm from non-paradigm.
Oh my... quite a lot.
Now when has the definition of ProgrammingParadigm become unclear? Personally, I've never heard any other definition than "these three (unless something else can be found)". As far as I can see, the waters became muddy, when some dimwit declared ObjectOrientedProgramming to be the fourth paradigm, which it clearly is not. It's ImperativeProgramming with some conventions (and it's very obviously not FunctionalProgramming plus something and also not ConstraintProgramming plus something). As soon as you admit OO, you have to admit all the other conventions. Suddenly, StructuredProgramming, ModularProgramming, GenerativeProgramming, TableOrientedProgramming, ... all become paradigms, which ends with the list over at ProgrammingParadigm. (Anyway, I blame Booch and Rumbaugh for the confusion. The got rich by promoting OO to the "Paradigm For The 21th Century".)
Regarding hybrids: practical languages usually have a primary paradigm, which influences the programming style a lot, and borrow from the other two paradigms as needed. But they never borrow from somewhere else... because there is nothing else. So I'd call C++ an imperative language, because assignment is the primary computational mechanism. That isn't changed by the fact that STL is mostly functional and Boost::Lambda pretends to be really functional. I'd also call Haskell a functional language, because term reduction is the primary mechanism. That also isn't changed by the fact that Haskell has mutable variables, should you absolutely want them. And so on... Yes, Lisp is clearly a functional/imperative hybrid (give it mandatory optimization of tail recursion and it becomes "functional with imperative features, should you need them"). Forth is a "weird hybrid", because operations on the stack "feel" quite a bit functional. Whatever, call it imperative, that's precise enough.
But no matter how the three classic paradigms are combined, no fourth has ever been found. Each entry in the list over at ProgrammingParadigm is either reducible to one of these three (and quite trivially so), orthogonal to them, or plain nonsense.
The definition of ProgrammingParadigm has been unclear as long as I've been aware of it, which is close to three decades. What you are doing is advocating the 'ProgrammingParadigm = computational model' viewpoint, which I've just highlighted - in order to show its relationship with other, equally valid viewpoints - above in my paragraph about the various interpretations of the meaning of ProgrammingParadigm. Someone else has courteously prefixed that paragraph with 'MARK' (see why, below.) As I stated in the paragraph above, and as someone agrees, below, this is clearly a LaynesLaw debate, and typical of my experience any time the issue of ProgrammingParadigm comes up. Hence, I advocate that ThereAreNoParadigms even if there are paradigms, as it's impossible to agree on what they are. Far, far better we speak in terms of computational models (and, indeed, the three you've mentioned are fundamental) and/or language features, neither of which result in anywhere near as much debate over ambiguity, and yet cover exactly the same ground.
Three decades? How come that in the three decades before everyone agreed on the classical definition? Hm... three decades. That's about the time when SmallTalk was invented. Maybe Nygaard destroyed the meaning of paradigm and Booch and Rumbaugh just reaped the benefits...
"where the value of an expression is computed???"
Functional languages are term rewriting systems. A program is a complicated term, evaluating it (calling it "executing" would not be quite right) amounts to repeatedly finding "redexes" and replacing them according to a suitable rule. LambdaCalculus is such a system, and so is CombinatorialLogics?. It's also true of RelationalAlgebra, but lacking a fixpoint combinator, RA cannot be used for general purpose programming.
The upshot is, in FunctionalProgramming you start with an expression and reduce it until it is in normal form. In ImperativeProgramming you start with a list of instruction and some memory, then modify the memory according to the instructions. "Where the value of an expression is computed" captures that quite well, I think. (Putting "where repeated reduction of redexes until a normal form is reached" into the short list is counter productive, because it doesn't explain anything unless you already knew it.)
I presume you mean "implements lambda calculus" or some such
The rub is in the "or some such". There is at least CombinatorialLogics?, which is not quite the same. "Implements an Algebra" would be correct, but that again explains exactly nothing. "Has denotational semantics" would also be correct... wait a minute, this one could actually be a good catch phrase. (* wanders off to think about it *)
which would be clearer, as functional programming is more often characterised by the fact that computation itself is conceived as functional evaluation without state or explicit sequential commands - though even that last is debatable, as functional execution is sequential from the inside out, as opposed to top-to-bottom. However, the second bullet points (added later to the definitions of the three paradigms above) are much better.
HaskellLanguage evaluates outside-in. Actually it doesn't even specify evaluation order, since it is unobservable anyway. The same goes for CleanLanguage, I believe.
I stand corrected. /me wanders off to read up on Haskell...
Maybe there are only two paradigms:
I have, at least a little. I do have to admit that I used the word imperative inappropriately. Maybe I should have called them "descriptive" and "proscriptive".
On further reflection, functional seems to fit partially, but not entirely, into both of my categories. Meaning, at least to me, that there is something wrong with my suggestion.
Feel free to delete this suggestion, or refactor any usable bits, as you see fit.
Indeed. Depending on who you ask, "declarative" may well include "functional". Most often it just means "not as cumbersome as C"...
How can two obvious experts talk at cross purposes so long? Seems you are in ViolentAgreement somehow, as you both know clearly enough about these topics (to avoid the word "paradigm"). You seem to know: The paragraph marked with "MARK" says it all. Its LaynesLaw at work.
Anyway to muddy the waters a bit too: From a computing point of view there may be indeed only three paradigms (or two or one). But from a paradigm point of view (using the definition from wikipedia above), at least OO is indeed orthogonal to the other three as it adds a new layer of meaning. The code is no longer only used to implement function, but also to express meaning. Or isn't one of main ideas of OO, that objects are modeled after real world entities? That the code should structurally reflect the model? The paradigm is about the process that forms the implementation, not only the implementation itself. -- GunnarZarncke
Actually, there were at least 3 contributors on this page. My personal contributions have been small, and limited to this section.
[Well, Gunnar, if the three classics are paradigms, and OO is orthogonal, then OO is very obviously NOT a paradigm. At the very least you have to call OO a "paradigm modifier", for it combines with a classic paradigm to form a new one. Which would already give us 6 distinct paradigms (three classics plus imperative OO, functional OO and logical OO), and from there it rapidly gets nonsensical. Indeed, this confusion started exactly when some bright light promoted OO from merely a good practice to The Fourth Paradigm. Before that, we had a perfectly good word with perfectly well understood meaning. Now we have more pseudo paradigms than you can shake a stick at. Remember what Dijkstra said about the use of langugage: "You cannot sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes." Margin note: paradigms are very much not about modelling, they are about what primitives there are to build programs of.]
Ahem, as long as you don't try to understand us, we will follow LaynesLaw. I can very well see your three paradigms. But I get the impression, that you narrowed your view of what is a paradigm is, to make the three classical paradigms the only ones, that match it. I beg you to go the other way around and look what reading of "paradigm" would make our arguments sound. E.g. take the Wikipedia entry above as guide. Please don't assume, that we are too stupid to 'get it'.
As for "orthogonal". I didn't mean it in the sense that there are multiple dimensions of paradigms (like implementation paradigms and process paradigms; though the idea to classify paradigms is interesting). I meant that the paradigm describes something new (exploration of idea space into a now - orthogonal - direction, so to say). -- .gz
Actually I didn't narrow anything, but you (not you personally, just "you all") widened a perfectly good definition until it included your favorite toy. First was OO (please have a look at NygaardClassification, it obviously doesn't fit with the threee others), then came AspectOrientedProgramming and then came all the others with their annoying Me-Too-Paradigms. Now the word has no meaning at all. When the works of Alan Turing, Alonzo Church, Gottlob Frege and Top Mind (*cough*) can be lumped together, all meaning is lost. It really is.
Btw, why should a WikiPedia article, especially one without a single reference or citation, very probably written by the same fellow who created ProgrammingParadigms?, be any guide at all, let alone a good one?
Are we talking about the same Wikipedia article? Anyway. What is your definition of the word "paradigm" as it is used in "The three programming paradigms are functional, imperative and dclarative programming"? -- .gz
The one title "Programming Paradigm"? That's the one without references.
Anyway: Paradigm == way of thinking, opinion about fundamental building blocks. We'll probably agree on that anyway. What I'm driving at is that these fundamental building blocks are still
I wouldn't touch this definition topic with a ten-foot-pole if I can stay rational. It invites LaynesLaw at every turn. --top
So... what was this comment? touching the topic with an eleven-foot-pole? Are you sure you're staying rational?
Maybe there is only one paradigm:
But doesn't that make the more common description of transformations from input to error messages a new paradigm?
Only if the error messages aren't output anywhere, which I suspect is all too common. New paradigm it is. (Tongue now sprained...)
EditText of this page
(last edited December 26, 2013)
or FindPage with title or text search