What is functional, declarative and imperative programming?

Functional programming is a subtype of declarative programming. So you've really asked the question "what is functional/declarative programming versus imperative programming"?

Functional programming is a subtype of declarative programming. So you've really asked the question "what is functional/declarative programming versus imperative programming"? Imperative Programming is what most professional programmers use in their day-to-day jobs.It's the name given to languages like C, C++, Java, COBOL, etc. In imperative programming, you tell the computer what to do.

"Computer, add x and y," or "Computer, slap a dialog box onto the screen." And (usually) the computer goes and does it. This is where most of us spend our lives, in looping structures and if-then-else statements and the like.

Functional Programming, as far as I understand it, seeks to describe what you want done rather than specify how you want something done.It's probably best understood in contrast to imperative programming. For instance, if you have a list in C and you want to pull out every Nth element, you have to point at the first element, set a counter at one, move to the next element, increment the counter, check to see if you're at the Nth element and so on. The functional equivalent would be to write a function that recognizes when the size of a list is a multiple of N, and then pass that function to the list, possibly with another snippet of code to hand back the head of the list if your N-recognizer evaluates to true and discarding it if it evaluates to false.

The two functions recurse through the list, and finally hand back a list consisting of every Nth element. The latter method might seem like the more confusing way to go about things, and that's because it is. Functional programming can be a mind-bender, which is one reason why Lisp, Scheme, and Haskell have never really surpassed C, C++, Java and COBOL in commercial popularity.

But there are benefits to the functional way. For one, if you can get the logic correct, functional programming requires orders of magnitude less code than imperative programming. That means fewer points of failure, less code to test, and a more productive (and, many would say, happier) programming life.As systems get bigger, this has become more and more important.

Are there more exotic types? Not yet. There are hybrids between the two of them (like Scala), but these merely seek to leverage the strengths of both types.

Then there's Object-oriented programming, which is really just a new way to organize data in an imperative program. And even with strange new technologies like quantum computing, the (planned-for) underlying languages fall somewhere in the declarative/imperative spectrum. And, as others have pointed out, JQuery is a library that sits on top of JavaScript, which is itself a hybrid functional/imperative language.

Without going into too much detail, JavaScript is like the ugly, buck-toothed girl your parents forced you to take to the prom. JQuery is like the fairy godmother who swoops in and, with one sweep of the wand, turns her into a total babe before your eyes.(See Douglas Crockford's JavaScript: the Good Parts to learn more.).

I agree with your answer, but I don't think that you can say that Javascript is bad. What's wrong with it are the implementations of the browsers, the language itself is good and easy to use, yet powerful at the same time. – Georg Schölly Mar 2 '09 at 16:47 1 I'm not saying JavaScript is bad, just ugly.

:) It was pushed out into the world before it was ready, and it can be a pain in the neck to work with because of this. The heart of the language, though, is beautiful, simple, and powerful. – rtperson Mar 2 '09 at 17:07 2 I like the explaination and loved the JavaScript/JQuery analogy!

– AieshaDot May 27 '10 at 21:23 "Are there more exotic types? Not yet. " - I disagree.

Logic Progamming and Term Rewriting are both, different forms of declarative programming, so I can come up with three, different kinds of declarative programming. – daf May 3 at 11:08 @cartoonfox - Good catch. Although term rewriting seems to me to be a close relative of the lambda calculus, and hence of functional programming.

And the only term-rewriting language that I know of is Pure, which considers itself a functional language. Am I missing something? Is there a possible fully term-rewriting yet in-no-way-functional computer language?

I'm genuinely curious. – rtperson May 3 at 16:18.

1) There's not really any non-ambiguous, objective definition for these. Here is how I would define them: imperative - The focus is on what steps the computer should take rather than what the computer will do (ex. C, C++, Java).

Declarative - The focus is on what the computer should do rather than how it should do it (ex. SQL). Functional - a subset of declarative languages that has heavy focus on recursion 2) There are some multiparadigm languages that kind of straddle both sides.

For example, C#, Python, and JavaScript are mainly imperative languages that have some functional or declarative elements. There are also logic programming languages (like prolog) that mainly focus on satisfying constraints. 3) I believe that JQuery falls under the multiparadigm category above (like the language it's implemented in, JavaScript).

1 - very nicely summarized. – duffymo Mar 2 '09 at 14:37 Recursion isn't the only feature of functional languages. They also have ways of dealing with functions other than just compilation, perhaps for example allowing runtime combination of functions to get a new function.

– David Thornley Mar 2 '09 at 15:23 1 Keep a couple of things in mind: 1) the explanation is intended to be simple rather than all-inclusive 2) like I said, there are multiple ways to define these languages. Thus, the answer could very well be wrong to you and right to someone else. – Jason Baker Mar 2 '09 at 17:07 1 @ShelbyMooreIII - I tend to agree with Eric Meijer on this one.

There's not really such thing as a "non-pure functional language". As far as I'm concerned, Ocaml, F#, and the like are imperative languages with functional data structures. But as I said in my answer, I don't believe there's any objective, non-ambiguous answer to this question.

There are multiple ways of defining things. – Jason Baker Dec 9 at 17:10 1 @ShelbyMooreIII - I was making the assumption that the OP wanted his answer in English, not Math Nerd-ese. If that was an invalid assumption, then my apologies.

– Jason Baker Dec 9 at 21:31.

In a nutshell: An imperative language specfies a series of instructions that the computer executes in sequence (do this, then do that). A declarative language declares a set of rules about what outputs should result from which inputs (eg. If you have A, then the result is B).

An engine will apply these rules to inputs, and give an output. A functional language declares a set of mathematical/logical functions which define how input is translated to output. Eg.

F(y) = y * y. It is a type of declarative language. JQuery is a library.It is built in an imperative language (JavaScript, which has absorbed some of the paradigms of functional programming) which makes use of declarative selector rules (based on CSS) to interact with browser objects (the DOM).

Functional programming is not "a type of declarative language". Declarative programming requires the immutability of stored values, impure functional programming does not. See my answer.

See also the explanation for spreadsheet cells. The only reason imperative logic (a.k. A instructions) execute in sequence is that due to the presence of mutable stored values, the result is dependent on the evaluation order.

Using your vocabulary, an "instruction" can (and a "rule" cannot) operate on mutable values. – Shelby Moore III Dec 3 at 7:21.

From Wikipedia In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow. It attempts to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it. This is in contrast from imperative programming, which requires a detailed description of the algorithm to be run.

Declarative programming consider programs as theories of a formal logic, and computations as deductions in that logic space. Declarative programming has become of particular interest recently, as it may greatly simplify writing parallel programs. Common declarative languages include those of regular expressions, logic programming and functional programming.

From Wikipedia: In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. Functional programming has its roots in the lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion.

Many functional programming languages can be viewed as embellishments to the lambda calculus. From Wikipedia: In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way as the imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.

The term is used in opposition to declarative programming, which expresses what needs to be done, without prescribing how to do it in terms of sequences of actions to be taken. Functional and logical programming are examples of a more declarative approach. JQuery is not a programming language, it is a library for the JavaScript programming language.

Tried to blockquote the last two parts from wikipedia, but was getting an unresponsive script error in firefox. – TheTXI Mar 2 '09 at 14:16 7 Those wikipedia articles are almost not understandable if you don't know the terms beforehand. (At least for me.) – Georg Schölly Mar 2 '09 at 14:22 duplicate answer – Don Branson Mar 2 '09 at 14:22 +1: not sure why this answer was downvoted when an identical answer got 2 upvotes.

– Juliet Mar 2 '09 at 14:34 2 This site tends to provide the information in the answer more than just telling the user to google it or to point them elsewhere. When I first checked your post, it did not have the URL's as clickable. – TheTXI Mar 2 '09 at 15:29.

Wikipedia is a good place to start with this type of question Functional Programming Declarative Programming Imperative Programming jQuery is a javascript library, like scriptaculous.

This isn't very far from a 'GIYF' answer. – GEOCHET Mar 2 '09 at 17:49 yes. My intent was to politely communicate to him that he needs to put at least a little effort into finding the answer - 10 or 20 seconds, before posting to SO.

I've seen others out here rudely give the RTM answer, but I think we can be nice about it instead. – Don Branson Mar 2 '09 at 18:25 @Don: He /doesn't/ need to google it first. That is the point of SO.

– GEOCHET Mar 3 '09 at 0:31 @Rich. Huh. Okay.

I've heard just the opposite opinion, too. Guess I'll have to go read the FAQ and find out for myself. – Don Branson Mar 3 '09 at 2:46 @Don: Believing everything you hear is not usually a good thing.

When in doubt, read the FAQ. – GEOCHET Mar 3 '09 at 15:02.

Imperative Programming means any style of programming where your program is structured out of instructions describing how the operations performed by a computer will happen. Declarative Programming means any style of programming where your program is a description either of the problem or the solution - but doesn't explicitly state how the work will be done. Functional Programming is programming by evaluating functions and functions of functions... As (strictly defined) functional programming means programming by defining side-effect free mathematical functions so it is a form of declarative programming but it isn't the only kind of declarative programming.

Logic Programming (for example in Prolog) is another form of declarative programming. It involves computing by deciding whether a logical statement is true (or whether it can be satisfied). The program is typically a series of facts and rules - i.e.

A description rather than a series of instructions. Term Rewriting (for example CASL) is another form of declarative programming. It involves symbolic transformation of algebraic terms.It's completely distinct from logic programming and functional programming.

Functional programming is not "a form of declarative programming". Declarative programming requires the immutability of stored values, impure functional programming does not. See my answer.

See also the explanation for spreadsheet cells. The term "work" in "describe how to do the work" is not defined. The only reason imperative logic (a.k.

A "instructions") execute in sequence is that due to the presence of mutable stored values, the result is dependent on the evaluation order. – Shelby Moore III Dec 3 at 7:33 2 Please take it as read that I was talking about pure functional programming. These paradigms can cross over and I don't want to get bogged down comparing hybrid languages.In theory at least functional programming is about functions rather than describing how a computer will perform each computation - so I maintain it is declarative.

– daf Dec 11 at 0:01 I edited my answer, and under the "Functional programming" section, I added a scenario where we could argue that FP is always pure, and impure FP is really "procedural programming". Apologies for not including that interpretation earlier. – Shelby Moore III Dec 12 at 3:02.

At the time of writing this, the top voted answers on this page are imprecise and muddled on the declarative vs. imperative definition, including the answer that quotes Wikipedia. Some answers are conflating the terms in different ways. Refer also to my explanation of why spreadsheet programming is declarative, regardless that the formulas mutate the cells.

Also, several answers claim that functional programming must be a subset of declarative. On that point it depends if we differentiate "function" from "procedure". Lets handle imperative vs. declarative first.

Definition of declarative expression The only attribute can possibly differentiate a declarative expression from an imperative expression, is the referential transparency (RT) of its sub-expressions. All other possible attributes are either shared with imperative, or derived from the RT. A 100% declarative language (i.e.

Every possible expression is RT) does not (among other RT requirements) allow the mutation of stored values, e.g. HTML and most of Haskell. Definition of RT expression RT is often referred to "no side-effects". The term effects does not have a precise definition, so some people don't agree that "no side-effects" is the same as RT.

RT has a precise definition. Since every sub-expression is conceptually a function call, RT requires that the implementation of a function (i.e. The expression(s) inside the called function) may not access mutable state that is external to the function (accessing mutable local state is allowed).

Precisely the function (implementation) should be pure. Definition of pure function A pure function is often said to have "no side-effects". The term effects does not have a precise definition, so some people don't agree.

Pure functions have the following attributes. The only observable output is the return value. The only output dependency is the arguments.

Arguments are fully determined before any output is generated. Remember that RT applies to expressions (which includes function calls) and purity applies to (implementations of) functions.An obscure example of impure functions that make RT expressions, is concurrency, but this is because the purity is broken at the interrupt abstraction layer. You don't really need to know this.

To make RT expressions, you call pure functions. Derivative attributes of RT Any other attribute cited for declarative programming, e.g. The citation from 1999 used by Wikipedia, either derives from RT, or is shared with imperative programming. Thus proving that my precise definition is correct.

Note, immutability of external values is a subset of the requirements for RT. Declarative languages don't have looping control structures, e.g. For and while, because due to immutability, the loop condition would never change. Declarative languages don't express control-flow other than nested function order (a.k.

A logical dependencies), because due to immutability, other choices of evaluation order do not change the result (see below). Declarative languages express logical "steps" (i.e. The nested RT function call order), but whether each function call is a higher level semantic (i.e.

"what to do") is not a requirement of declarative programming. The distinction from imperative is that due to immutability (i.e. More generally RT), these "steps" cannot depend on mutable state, rather only only the relational order of the expressed logic (i.e.

The order of nesting of the function calls, a.k.a. Sub-expressions). For example, the HTML paragraph cannot be displayed until the sub-expressions (i.e.

Tags) in the paragraph have been evaluated. There is no mutable state, only an order dependency due to the logical relationship of tag hierarchy (nesting of sub-expressions, which are analogously nested function calls). Thus there is the derivative attribute of immutability (more generally RT), that declarative expressions, express only the logical relationships of the constituent parts (i.e.

Of the sub-expression function arguments) and not mutable state relationships. Evaluation order The choice of evaluation order of sub-expressions can only give a varying result when any of the function calls are not RT (i.e. The function is not pure), e.g. Some mutable state external to a function is accessed within the function.

For example, given some nested expressions, e.g. F( g(a, b), h(c, d) ), eager and lazy evaluation of the function arguments will give the same results if the functions f, g, and h are pure. Whereas, if the functions f, g, and h are not pure, then the choice of evaluation order can give a different result. Note, nested expressions are conceptually nested functions, since expression operators are just function calls masquerading as unary prefix, unary postfix, or binary infix notation.

Tangentially, if all identifiers, e.g. A, b, c, d, are immutable everywhere, state external to the program cannot be accessed (i.e. I/O), and there is no abstraction layer breakage, then functions are always pure.By the way, Haskell has a different syntax, f (g a b) (h c d). Evaluation order details A function is a state transition (not a mutable stored value) from the input to the output.

For RT compositions of calls to pure functions, the order-of-execution of these state transitions is independent. The state transition of each function call is independent of the others, due to lack of side-effects and the principle that an RT function may be replaced by its cached value. To correct a popular misconception, pure monadic composition is always declarative and RT, in spite of the fact that Haskell's IO monad is arguably impure and thus imperative w.r.t.

The World state external to the program (but in the sense of the caveat below, the side-effects are isolated). Eager evaluation means the functions arguments are evaluated before the function is called, and lazy evaluation means the arguments are not evaluated until (and if) they are accessed within the function. Definition: function parameters are declared at the function definition site, and function arguments are supplied at the function call site.

Know the difference between parameter and argument. Conceptually, all expressions are (composition of) function calls, e.g. Constants are functions without inputs, unary operators are functions with one input, binary infix operators are functions with two inputs, constructors are functions, and even control statements (e.g. If, for, while) can be modeled with functions. The order that these argument functions (do not confuse with nested function call order) are evaluated is not declared by the syntax, e.g. F( g() ) could eagerly evaluate g then f on g's result or it could evaluate f and only lazily evaluate g when its result is needed within f.

Caveat, no Turing complete language (i.e. That allows unbounded recursion) is perfectly declarative, e.g. Lazy evaluation introduces memory and time indeterminism. But these side-effects due to the choice of evaluation order, are isolated to memory consumption, execution time, latency, non-termination, and external hysteresis e.g. Thus external synchronization.

Functional programming Because declarative programming cannot have loops, then the only way to iterate, is functional recursion. It is in this sense that functional programming is related to declarative programming. But functional programming is not limited to declarative programming.

Functional composition can be contrasted with subtyping, especially with respect to the Expression Problem, where extension can be achieved by either adding subtypes or functional decomposition. Extension can be a mix of both methodologies. Functional programming usually makes the function a first-class object, meaning the function type can appear in the grammar any where any other type may.

The upshot that functions can input and operate on functions, thus providing for separation-of-concerns by emphasizing function composition, i.e. Separating the dependencies among the subcomputations of a deterministic computation. For example, instead of writing a separate function (and employing recursion instead of loops if the function must also be declarative) for each of infinite possible specialized actions that could be applied to each element of a collection, functional programming employs reusable iteration functions, e.g. Map, fold, filter.

These iteration functions input a first-class specialized action function. These iteration functions iterate the collection and call the input specialized action function for each element. These action functions are more concise because they no longer need to contain the looping statements to iterate the collection.

However, note that if a function is not pure, then it is really a procedure. We can perhaps argue that functional programming that uses impure functions, is really procedural programming. Thus if we agree that declarative expressions are RT, then we can say that procedural programming is not declarative programming, and thus we might argue that functional programming is always RT and must be a subset of declarative programming.

Parallelism This functional composition with first-class functions can express the depth in the parallelism by separating out the independent function. Brent’s Principle: computation with work w and depth d can be implemented in a p-processor PRAM in time O(max(w/p, d)). Both concurrency and parallelism also require declarative programming, i.e.

Immutability and RT.So where did this dangerous assumption that Parallelism == Concurrency come from? It’s a natural consequence of languages with side-effects: when your language has side-effects everywhere, then any time you try to do more than one thing at a time you essentially have non-determinism caused by the interleaving of the effects from each operation. So in side-effecty languages, the only way to get parallelism is concurrency; it’s therefore not surprising that we often see the two conflated.

FP evaluation order Note the evaluation order also impacts the termination and performance side-effects of functional composition. Eager (CBV) and lazy (CBN) are categorical duels10, because they have reversed evaluation order, i.e. Whether the outer or inner functions respectively are evaluated first.

Imagine an upside-down tree, then eager evaluates from function tree branch tips up the branch hierarchy to the top-level function trunk; whereas, lazy evaluates from the trunk down to the branch tips. Eager doesn't have conjunctive products ("and", a/k/a categorical "products") and lazy doesn't have disjunctive coproducts ("or", a/k/a categorical "sums")11. Performance Eager As with non-termination, eager is too eager with conjunctive functional composition, i.e.

Compositional control structure does unnecessary work that isn't done with lazy. For example, eager eagerly and unnecessarily maps the entire list to booleans, when it is composed with a fold that terminates on the first true element. This unnecessary work is the cause of the claimed "up to" an extra log n factor in the sequential time complexity of eager versus lazy, both with pure functions.

A solution is to use functors (e.g. Lists) with lazy constructors (i.e. Eager with optional lazy products), because with eager the eagerness incorrectness originates from the inner function. This is because products are constructive types, i.e.

Inductive types with an initial algebra on an initial fixpoint11 Lazy As with non-termination, lazy is too lazy with disjunctive functional composition, i.e. Coinductive finality can occur later than necessary, resulting in both unnecessary work and non-determinism of the lateness, that isn't the case with eager1011. Examples of finality are state, timing, non-termination, and runtime exceptions.

These are imperative side-effects, but even in a pure declarative language (e.g. Haskell), there is state in the imperative IO monad (note: not all monads are imperative!), implicit in space allocation, and timing is state relative to the imperative real world. Using lazy even with optional eager coproducts, leaks "laziness" into inner coproducts, because with lazy the laziness incorrectness originates from the outer function (see the example in the Non-termination section, where == is an outer binary operator function). This is because coproducts are bounded by finality, i.e.

Coinductive types with a final algebra on an final object11. Lazy causes indeterminism in the design and debugging of functions for latency and space, the debugging of which is probably beyond the capabilities of the majority of programmers, because of the dissonance between the declared function hierarchy and the runtime order-of-evaluation. Lazy pure functions evaluated with eager, could potentially introduce previously unseen non-termination at runtime.

Conversely, eager pure functions evaluated with lazy, could potentially introduce previously unseen space and latency indeterminism at runtime. Non-termination At compile-time, due to Halting problem and mutual recursion in a Turing complete language, functions can't generally be guaranteed to terminate. Eager With eager but not lazy, for the conjunction of Head "and" Tail, if either Head or Tail doesn't terminate, then respectively either List( Head(), Tail() ).

Tail == Tail() or List( Head(), Tail() ). Head == Head() is not true because the left-side doesn't, and right-side does, terminate. Whereas, with lazy both sides terminate.

Thus eager is too eager with conjunctive products, and non-terminates (including runtime exceptions) in those cases where it isn't necessary. Lazy With lazy but not eager, for the disjunction of 1 "or" 2, if f doesn't terminate, then List( f? 1 : 2, 3 ).

Tail == (f? List( 1, 3 ) : List( 2, 3 )). Tail is not true because the left-side does, and right-side doesn't, terminate.

Whereas, with eager both sides non-terminate so the equality test is never reached. Thus lazy is too lazy with disjunctive coproducts, and in those cases non-terminates (including runtime exceptions) after doing more work than eager would have. 10 Declarative Continuations and Categorical Duality, Filinski, sections 2.5.4 A comparison of CBV and CBN, and 3.6.1 CBV and CBN in the SCL.

11 Declarative Continuations and Categorical Duality, Filinski, sections 2.2.1 Products and coproducts, 2.2.2 Terminal and initial objects, 2.5.2 CBV with lazy products, and 2.5.3 CBN with eager coproducts. There are more exotic concepts in programming, e.g. Dependently typed, functional reactive, etc.. I don't know enough about jQuery to answer your question about it.

I have clarified the issues more and perhaps I will try to edit and clarify my answer when I have time. – Shelby Moore III Dec 7 at 14:29 Even with declarative constraint programming, the constraints don't mutate while the solver is finding the solution. This is obvious because there is no way to specify a time for them to change.

Even constraints specified w.r.t. Other constraints all are stated before the solver is run to find the solution. This is analogous to the declarative formulas in the spreadsheet.

– Shelby Moore III Dec 7 at 21:52 1 Abbreviation does not mean provide a definition. Where I wrote "RT is often abbreviated 'no side-effects'", that doesn't mean the definition of RT is "no side-effects", because people may have varying definitions for 'effects'. If I instead said "RT is often abbreviated 'xyz'", a meaningless symbol doesn't give any definition to RT.

RT has a precise definition that never changes, no matter what symbol one uses to refer to it. – Shelby Moore III Dec 8 at 13:12 I am unable to find a counter-example to my claim that every kind of DP is RT. For example, the meaning (i.e.

Value) of the terms of a context-sensitive grammar don't mutate at a different time or position within the grammar. See my constraint programming comment above. – Shelby Moore III Dec 8 at 14:16 1 Equating C in ESP style with RT in State monad, is invalid, because each C statement may mutate global state, whereas "inside" the state monad each corresponding statement generates a COPY of the state (so modified).

The latter is RT-- former is not. Monadic composition is always RT. DP == RT is the only meaning for DP that is a disjoint set of attributes (the math proof I'm correct, else DP is meaningless).

– Shelby Moore III Dec 8 at 16:07.

This video from channel9 with Erik Meijer helped me a lot in understanding what functional programming really is. A good point in the video starts around 16 minutes.

I'd add Object-Oriented programming to the list of styles (Wikipedia). Maybe Esoteric languages (Wikipedia) as well, as they focus on how the code looks and not how the program actually runs.

I think that your taxonomy is incorrect. There are two opposite types imperative and declarative. Functional is just a subtype of declarative.

BTW, wikipedia states the same fact. Probably multiparadigm languages that incorporates features from both worlds. So I share opinion of Jason Baker.

Again I share opinion of Jason Baker. JQuery is multiparadigm as its host language is.

1: Yep, the paradigms are apples and oranges. – Nikhil Chelliah Mar 2 '09 at 16:53 FP is not "just a subtype of declarative". FP is orthogonal to the polarity of imperative vs. DP.

DP requires the immutability of stored values, impure FP doesn't. Wikipedia is conflating pure FP with FP, with the absurd claim that the following concepts are "generally foreign to imperative programming": first-class functions, recursion, evaluation order, and static typing. Then Wikipedia admits impure "Functional programming in non-functional languages".

– Shelby Moore III Dec 3 at 8:16.

In a nutshell, the more a programming style emphasizes What (to do) abstracting away the details of How (to do it) the more that style is considered to be declarative. The opposite is true for imperative. Functional programming is associated with the declarative style.

See my comments below the other answers. FP is not always declarative. What vs. how is the wrong taxonomy for IP vs. DP, as both DP and IP have logic that involve the what and how.

– Shelby Moore III Dec 3 at 8:29.

Declarative programming is programming by expressing some timeless logic between the input and the output, for instance, in pseudocode, the following example would be declarative: def factorial(n): if n Other, stricter definitions entail that there may be no side-effects at all, these languages are some times called 'purely declarative'. The same result in an imperative style would be: a = 1 be = argvec0 while(b Declarative languages are often said to specify 'what must be done', as opposed to 'how to do it', I think that is a misnomer, declarative programs still specify how one must get from input to output, but in another way, the relationship you specify must be effectively computable (important term, look it up if you don't know it). Another approach is nondeterministic programming, that really just specifies what conditions a result much meet, before your implementation just goes to exhaust all paths on trial and error until it succeeds.

Purely declarative languages include Haskell and Pure Prolog. A sliding scale from one and to the other would be: Pure Prolog, Haskell, OCaml, Scheme/Lisp, Python, Javascript, C--, Perl, PHP, C++, Pascall, C, Fortran, Assembly.

You did not define functional programming. You incorrectly implied, "some 'purely' declarative languages", that declarative programming can be impure. Declarative programming requires the immutability of stored values, imperative programming does not.

See my answer. Immutability is the "timeless" quality-- see that your declarative factorial doesn't mutate any value. – Shelby Moore III Dec 3 at 7:53.

Imperative and declarative describe two opposing styles of programming. Imperative is the traditional "step by step recipe" approach while declarative is more "this is what I want, now you work out how to do it". These two approaches occur throughout programming - even with the same language and the same program.

Generally the declarative approach is considered preferable, because it frees the programmer from having to specify so many details, while also having less chance for bugs (if you describe the result you want, and some well-tested automatic process can work backwards from that to define the steps then you might hope that things are more reliable than having to specify each step by hand). On the other hand, an imperative approach gives you more low level control - it's the "micromanager approach" to programming. And that can allow the programmer to exploit knowledge about the problem to give a more efficient answer.So it's not unusual for some parts of a program to be written in a more declarative style, but for the speed-critical parts to be more imperative.

As you might imagine, the language you use to write a program affects how declarative you can be - a language that has built-in "smarts" for working out what to do given a description of the result is going to allow a much more declarative approach than one where the programmer needs to first add that kind of intelligence with imperative code before being able to build a more declarative layer on top. So, for example, a language like prolog is considered very declarative because it has, built-in, a process that searches for answers.So far, you'll notice that I haven't mentioned functional programming. That's because it's a term whose meaning isn't immediately related to the other two.

At its most simple, functional programming means that you use functions.In particular, that you use a language that supports functions as "first class values" - that means that not only can you write functions, but you can write functions that write functions (that write functions that...), and pass functions to functions. In short - that functions are as flexible and common as things like strings and numbers. It might seem odd, then, that functional, imperative and declarative are often mentioned together.

The reason for this is a consequence of taking the idea of functional programming "to the extreme". A function, in it's purest sense, is something from maths - a kind of "black box" that takes some input and always gives the same output. And that kind of behaviour doesn't require storing changing variables.So if you design a programming language whose aim is to implement a very pure, mathematically influenced idea of functional programming, you end up rejecting, largely, the idea of values that can change (in a certain, limited, technical sense).

And if you do that - if you limit how variables can change - then almost by accident you end up forcing the programmer to write programs that are more declarative, because a large part of imperative programming is describing how variables change, and you can no longer do that! So it turns out that functional programming - particularly, programming in a functional language - tends to give more declarative code.To summarise, then: imperative and declarative are to opposing styles of programming (the same names are used for programming languages that encourage those styles) functional programming is a style of programming where functions become very important and, as a consequence, changing values become less important. The limited ability to specify changes in values forces a more declarative style.

So "functional programming" is often described as "declarative".

Imperative: how to achieve our goal Take the next customer from a list. If the customer lives in Spain, show their details. If there are more customers in the list, go to the beginning Declarative: what we want to achieve Show customer details of every customer living in Spain.

You are describing functional programming vs. non-FP, not declarative vs. imperative programming. Functional programming is orthogonal to the polarity between imperative and declarative programming. Declarative programming requires the immutability of stored values, impure functional programming does not.

See my answer. – Shelby Moore III Dec 3 at 7:40.

I am being assigned to research F#. AFAIK, it definitely is a multi-paradigm language. It has the the best of both worlds.It could be used by new programmer (easy to learn, easy to understand), commercial programmer (productivity, stable, excellent supported .

NET library), scientist programmer (good performance on manipulate large data, expressive mathematical syntax).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.