views:

305

answers:

4

Hey all,

I've been reading through previous posts on declarative programming and I think I understand the underlying concepts. Could anyone describe some declarative programming paradigms and what they are useful for, as well as what their major shortcomings are? I'm trying to examine a new application development system that is coming to market in the next few months that seems to be declarative in nature, but I'm not sure if it matches the descriptions I've found on this website. I know this is somewhat open-ended, but please allow a few responses before closing. Many thanks.

+1  A: 

SQL (at least the SELECT portion) is generally considered to be declarative; Prolog is another common case.

e.tadeu's wikipedia links give you the definitions. In terms of the advantages and disadvantages, the primary advantage is that it is highly abstract; the system underneath can do whatever it takes to implement the language. The disadvantage is similar, because the system is determining the algorithm, sometimes it does a bad job and it can be difficult to fix.

In the case of SQL, good database people generally know when a SQL implementation is likely to be slow and have learned to alter the SQL to avoid them. There are times, however, when you need to see how the database system is implementing the query. Most database systems have a way checking the plan it uses to implement the SELECT (about 1 or 2 levels less abstract).

Most people would consider the tradeoff to be worth it for SQL (which is why it is still in use); in particular the query implementation can check runtime information (such as table size) to guide the query; this would be much harder to do manually.

Kathy Van Stone
+3  A: 

I think "Declarative Programming" is an important idea, but it means different things to different people.

Most would agree that it means expressing "what" a program should accomplish, rather than "how". I agree with that, more or less, but I think it's impossibly vague.

Some think that to be declarative a language should have no notion of time-sequence of execution, with assignments. I think that is too restrictive.

Some think that a declarative language should somehow resemble a formal logic, like predicate calculus, as in Prolog or SQL.

I think of declarativity not in terms of specific syntax or semantic features, but rather in terms of the directness with which it expresses requirements, as in a domain-specific-language (DSL).

One effect of such directness is that code is both short and clear.

This is a goal that should not be thought of as being achieved, but rather sought after. I get annoyed whenever I hear that a certain language "is declarative", when the measure of its declarativity is how succinctly it expresses problems and their solutions, and that can only be measured in specific cases.

Just by way of example, Differential Execution is the basis for a DSL that I wrote and use for programming complex user interfaces. It does not satisfy any of the usual definitions of DSL or declarativity, but it does accomplish the real result of making source code short (by an order of magnitude compared to common approaches), clear, and easily modified.

It does not insist on being easily understood by the uninitiated, rather requiring a one-time learning curve as the price of its productivity.

Mike Dunlavey
+1  A: 

IMHO it's more appropriate to speak about more or less declarative and more or less imperative rather than declarative vs imperative (as black or white).

Here's an example:

In .NET, LINQ allows you to express the logic that previously required an (imperative) foreach loop as a (declarative) query instead. However the LINQ query may still have distinct "steps" the calculation goes through, in the form of range variables (let = ....). Your logic therefore is expressed (declared) at a higher level of abstraction, but it still contains suggestions of how to achieve your result, not pure what you want done (which is arguably impossible).

zvolkov
++ I think "declarative" vs. "imperative" is a false and narrow-minded dichotomy. For example, if one is formulating a language for expressing travel directions, it has to have the notion of time-sequence of actions.
Mike Dunlavey