Jump to content

Talk:Declarative programming/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

http://phoenix.inria.fr/wiki/doku.php?id=an_overview_on_dsls

A lot of this material was taken from old versions of the Combinatorial_search node. I think I have permission to do this as this and the Combinatorial_search node are actually part of a homework assignment. maxomai

I thought C++ and Java are OOP languages.

Yes, C++ and Java are OOP languages. But OOP languages are imperative languages. So C++ and Java are also imperative languages. -- Derek Ross

Aren't there any object oriented declarative languages? And if so, what's the reason?

Take a look at [Scala].

Wouldn't CSS and XSLT qualify as good examples of declarative languages, too? — Brianiac 18:05, 15 Nov 2004 (UTC)

Yes, XML is also declarative.

If you classify OO as imperative, you will have to classify all programming paradigm that runs in an Imperative architecture as Imperative. --Lssilva 12:50, 3 Jan 2005 (UTC)

Just put a header on the applications section, and added Enterprise Programming as an example application. --harburg 22:04, 6 Jan 2005 (UTC)

It doesn't seem to be entirely clear what Declarative programming is. Why do some consider the distinction Functional vs. Imperative, and not Declarative vs. Imperative (for instance: http://www.haskell.org/complex/why_does_haskell_matter.html and imperative programming comparison)? Is functional programming really a form of declarative programming (I have my doubts, but perhaps the definitions for functional programming, I've come across are also mistaken).

Perhaps it needs to be made clear where exactly the boundaries of imperative and declarative programming are. Makefiles, for instance, seem to be declarative (I stand under correction though), but can easily be extended (or, rather, hooked onto) with any number of approaches. I assume that imperative languages could also be extended with declarative languages too (regular expressions within certain imperative languages, may be a case in point).

See also the discussion on Declarative Programming Languages.

The reason why people don't consider the distiction is that functional languages are not declarative. That is in error on this page. I thought I should post discussion before changing that. In Concepts of Programming Lanuages, Robert Sebesta constrasts declarative programming from procedural, and indicates functional languages are primarily procedural. This article and the procedural article seem to include very little on the two ideas, and give the wrong impression of the concepts because editors have written on things they are more familiar with like OO or what a procedure is. ProLog is probably the best example of a declarative lanuage. It does not use procedures to calculate things, it simply indicates what it expects (there is no details on "how"). -has


declarative program is not Turing-complete

I'm willing to stand corrected, since I don't know most of the languages listed in the examples. But if you do revert my new paragraph, you should explain how SQL (not a programming language but a "data sublanguage", in the words of C. J. Date) and XML (even more specialized -- what I would call a "data storage sublanguage") and XSLT (yet more specialized -- a conversion utility for XML) and Prolog (according to Wikipedia, "In Prolog you supply a database of facts and rules; you can then perform queries on the database") got into the list of examples (well, XML is not in the list in the Article but it is categorized as a declarative language in Talk) without any mention of the fact that they are not UTMs.

TH 01:11, 13 December 2005 (UTC)

First of all, programs or stylistic ambitions are not Turing-complete, computational models can be, and most languages are. Turing-completeness isn't about what's practical, it's about what's possible. As an example, you can turn any C program into an XML representation and apply some XSLT to it to produce the output of the C program, if XSLT is Turing-complete (it probably is). We aren't interested in the ways of IO etc. at all, only computation. Another example, C++ is Turing-complete, but so is the compile-time template language in it!
Now, to give programming languages that are definitely Turing-complete: Lisp, Prolog, Haskell. They are usually regarded as declarative programming languages and it is easy to write programs in them in the declarative style. I tried to rewrite the section to my best knowledge. --TuukkaH 20:53, 17 December 2005 (UTC)

I had to take this whole paragraph out:

" Many of the dialects being created based on the XML format can be described as declarative due largely to the increasing popularity of the declarative programming paradigm. "

because:

1. XML is a language, not a format (and not a programming language).

2. All extensions of XML are no more and no less declarative than XML.

3. I see no evidence that declarative programming is becoming more popular in comparison with imperative languages. Cite. Writing XML files is not programming; it's equivalent to writing DML in SQL. Writing DTDs is not programming; challenging it may be, but it's equivalent to writing DDL in SQL.

4. Popularity would be no reason that XML dialects could be described as declarative.

TH 01:29, 13 December 2005 (UTC)

Makefiles: imperative

Someone asked about makefiles above -- so:

Although the dependency lines of a makefile are declarative, the block of command lines that follow each dependency line are procedural (imperative), because in effect they constitute a shell script.

Just as the data declarations of a Java program, however elaborate, do not make the Java program declarative, the dependency lines of a makefile do not make the makefile declarative.

In short, makefiles are imperative.

TH 03:21, 13 December 2005 (UTC)

I disagree. Makefiles are both declarative (the rules) and imperative (the actions). I don't think it's reasonable to say that anything that is even the slightest bit imperative is therefore imperative without qualification. That would be like saying HTML is imperative because it can embed javascript, or SQL is imperative because the database might have triggers.

Kimbly 19:30, 31 December 2005 (UTC)

Limitations of declarative languages (with citations)

I reverted recent changes to "Disadvantages", pending (a) someone citing a demonstration that some language among the examples given is Turing-complete, and providing a frank discussion of why so many of them are not Turing-complete; or (b) someone providing a frank discussion of the non-Turing-completeness of imperative languages, which restricts them to solving a tiny fraction of the infinity of problems that are solvable by Turing-complete languages. Note Wikipedia policy on Cite. When I say "a tiny fraction", I mean "a tiny fraction, however large in magnitude" -- I do not mean declarative languages are unimpressive or are toys or are useless or not clean or beautiful.

I removed the phrase "how widely applicable" because I don't see that it addresses the issue that imperative languages are highly restricted (not UTMs). That is a big deal, not a minor flaw. Similarly, I saw the phrase "the interpreter" but I didn't see any discussion addressing the point that this interpreter is otherwise known as "the semi-special-purpose program that you buy or download for free" (MySQL, msql, JESS, etc.).

Here's how it works -- correct me if I'm wrong -- cite if you correct me -- I will cite. With a declarative (general-purpose or Turing-complete) language, you buy a compiler (possibly free; Java, Perl, C++, Delphi, assembler, etc.), and write a special-purpose program to solve your special problem. With an imperative language, you buy a sort-of-special-purpose program (possibly free; see list below). Along with the sort-of-special-purpose program, you get a system for feeding your special data to the program; that system is called a "declarative language". Then the sort-of-special-purpose program chews on your special data to solve your special problem. I cite: MySQL FAQ page; msql FAQ page; any book on XML or SQL; JESS FAQ page; any SQL FAQ page; any expert system or AI system FAQ page. I cite C. J. Date's statement that SQL is not really a language but is instead "a data sub-languages". I believe that declarative languages are confined to solving these types of problems: formal logic queries; data storage (XML in all its varieties), data access (SQL, Quel, etc.); optimization; rule systems (given the rules I put in, is X allowed?). I probably missed one or two -- I would appreciate help completing the list of problem types solvable by the current crop of declarative languages. It's market-driven, so the list is ever changing.

Singapore's airport gate and baggage-machine scheduler is run by an optimization engine (I have forgotten the brand) that balances a tremendous number of factors. For all I know, it saves them a billion dollars a year. It's extremely powerful. Singapore would never want to pay anyone to write the equivalent logic in a UTM. But it's not a Turing machine. It can't balance your checkbook.

(Don't you just love how, if you try to arrow down past the last line of your editing and the last line is not blank, Wikipedia appends a blank line and puts your cursor on it -- a nice touch that Microsoft Word for well over ten years now has still not figured out?)

TH 00:44, 19 December 2005 (UTC)

Realistic UTMs (spreadsheets -- not); this page bifurcated at best

Maybe we need to concentrate on the concept of a Realistic Universal Turing Machine (RUTM).

A real UTM (infinite paper tape, bi-directional motor, etc.) is not an RUTM -- too clumsy. Nobody discusses UTML, the language of a real (unrealistic) UTM.

A spreadsheet is a UTM, but not an RUTM, because although it's a UTM, it's too specialized (not general-purpose-realistic enough) for anyone to use it as a general-purpose computing language. Therefore no one write graphics drivers for a spreadsheet, so we can't draw little pictures inside the cells; similarly, no one writes regular expression evaluators for spreadsheets, nor all the other libraries that an RUTM tends to accumulate.

So . . . is Haskell an RUTM?

Yes, it absolutely is. For practice, look at http://www.haskell.org/libraries/. For theory, look into Monads, Concurrent Haskell, Software Transactional Memory, etc. Kimbly 19:39, 31 December 2005 (UTC)

And who outside the ivory tower cares about non-R-UTMs, unless they're going to bust out and change the landscape of real-world programming forever?

I believe it's easy to find examples of non-UTM (declarative) languages: Every XML language is non-UTM. Regular expressions are non-UTM. The language of Windows (or KBE, etc.) is a powerful but awkward and nontextual and non-UTM langauge whose lexicals are click, double-click, drop-down, type "ABC", choose menu item, right-drag, mouse-wheel-down, Page Up, etc. Any data entry system that slaps your hand or corrects you when you type something wrong is probably a non-UTM language. Usually they're so simple that we don't call them languages, but that choice is arbitrary. Your telephone dial has a language -- 55512345 is identical to 5551234 in that language; 555123 is syntactically invalid; years ago, 16795551212 was invalid (when the middle digit of an area code was constrained to 0 or 1). There's no meaningful line to draw between these non-UTM languages and Singapore's expert systems rule "Baggage conveyor type 103B223Q cannot unload Boeing 767s".

At best, I think the Declarative Programming page as it stood last week was seriously bifurcated. Bifurcated between the semi-special-purpose engines that I listed a few inches up and *_possibly_* the near-R-UTM languages that some still claim exist; e.g. perhaps Haskell. The crack should either be repaired seamlessly (smooth continuum from your phone-pad's language (lexicals: [0-9*#], Hangup, etc.) to XML to Haskell), or explicated thoroughly (Declarative Languages type S and Declarative Languages type G?).

TH 03:58, 19 December 2005 (UTC)

O(n**2)? or cite?

I reverted but also clarified my original by giving the time to solution as O(n**2).

Coastalpedia (or anyone else) -- if you feel that the order of the problem is less than n squared, please put your reasoning in and provide a citation. I think Wikipedia needs something more solid than "But that belief is simply wrong" -- the unobvious needs to be substantiated. Has the "belief" been mathematically proven to be wrong? Or is that an empiricaly result, widely confirmed? What exactly is the time to solution? Is it (my guess) that for a lucky client (with a fairly simple problem) the order is slightly over n, and for an unlucky client, the folks who optimized the solution engine haven't gotten it much below n squared.

TH 20:48, 23 December 2005 (UTC)

How can I explain this when you are willing to make assumptions about O(n**2) (or any other order)? No system (other than perhaps naive student projects) does a full search space enumeration to perform constraint satisfaction. Even back in the mid 80s, Prolog systems knew about trimming search spaces. The cite for ALS provides one example of something quite finely tuned well past the point of any "inconvenience". Frankly, it's fundamentally wrong to assume that declarative systems require an interpreter. A constraint satisfaction system? Sure. Interpreter? No.

For that matter, this article contains a number of errors, especially in the conflation of terms, such as the conflation of functional and declarative. This article desperately needs to go back to basics, get the terms defined orthogonally, and build it back up on a solid foundation.

Coastalpedia 07:57, 24 December 2005 (UTC)

Heavy re-org

I thank Coastalpedia for the example of ASL. I agree on the need for a basic rewrite, so I took a stab at it. I hope I have treated ASL fairly in the rewrite.

I leaned toward the term "conditions", which I found in the first paragraph, but I kept the names of the constituents (data, functions, rules, term-rewriting) that I found in the article. In particular, "functional" is now a secondary concept. But I think there is still some article in in Wikipedia that claims that "functional" and "declarative" are opposites.

I leaned toward the term "engine", but I left the synonyms (interpreter, executor, compiler) in for at least one mention each.

I removed the word "pure", which seemed more confusing than helpful (why pure functional? why not pure logic? why not a mix?).

TH 01:37, 30 December 2005 (UTC)

This article is highly controversial, judging by the edit history. References are a good tool to show we have facts and are discussing notable points of view. If you disagree, you don't need to remove references, you can add to them ones that support your view! I don't know many good references but I like the clear albeit strict definitions in FOLDOC even though they only have "declarative language" instead of "declarative programming".

Another concern of mine is the article's wrong relation of the topic to some close ones. I don't understand why we want to make false claims about domain-specific languages, turing completeness, language classification here. If you want to claim no DSL is turing complete, why not say it on the page on DSLs and get reverted? If you want to claim HTML can be used for programming, why not say it on the page on programming languages and get reverted? I hope the sections See also and External links can help give the article a distinguished scope between all the other topics.

Of course everybody disagrees what the scope should be :-) Declarative programming is a way to programming, a programming paradigm? Declarative programming is computer programming? Declarative programming is the opposite of imperative programming in the sense that the first lacks the concentration on the program state of execution? Declarative programming is also the opposite of procedural programming (or sequential programming more generally) in the sense that the first lacks the step-after-step instructions of program execution? This all is what I read from the FOLDOC articles, what about you people? --TuukkaH 21:01, 1 January 2006 (UTC)

Declarative UI

I think it could be relevant to add a section about Declarative UIs (like XUL, XAML, etc..), and maybe add a link to User interface markup language article. - Hervegirod 09:58, 14 May 2006 (UTC)


not Turing-complete = drawback ?

From the article: "One drawback of DSLs is that they are often not Turing-complete." This suggests that Turing-completeness should be mandatory for programming languages. IMHO it is no drawback, if a language is not Turing-complete; unless, you want to use the language to solve problems that require Turing-completeness.

But DSLs a restricted to a certain domain and usually the Turing-completeness is not required. Would you say the drawback of an electric drill is that you cannot cut paper with it? No. Sometimes the it is a drawback if the language IS Turing-complete, because certain things (source code analysis,etc.) are undecidable over Turing-complete languages (Halting problem) while there might be feasible for 'incomplete' DSLs.

--Riedel 09:44, 22 July 2006 (UTC)

"One drawback of DSLs is that they are often not Turing-complete. That is, there are certain things they cannot do. Just as you cannot use a spreadsheet to send e-mail, you cannot use e-mail to calculate your bank balance." You're saying that a spreadsheet could send email if only it were Turing-complete? Ali 2007-03-08


IMO two concerns are being mixed here -- computational power of a model/language (which is what Turing completeness talks about), and the underlying facilities and primitives of an interpreter/compiler/runtime environment (usually related to IO, files, etc). For example: as Turing-complete as pure lambda calculus is, it's just meaningless to ponder whether you can or cannot send email with it. While you might be tempted to say "you can't!", nothing precludes a particular LC interpreter to say that if an expression ultimately reduces to the form "((e <dest>) <text>)" then, as a side effect, an email is sent to the address in <dest> containing the text in <text> (the precise encoding of text in lambda expressions is left as an exercise). -- Ariel "askyle" Birnbaum, 2008-02-06 —Preceding unsigned comment added by 192.114.107.4 (talk) 08:01, 6 February 2008 (UTC)

HTML is not presentational anymore...

The W3C made this pretty clear. Most presentational elements have been deprecated as of HTML 4.01 Strict (Transitional is called Transitional for a reason) and those that are still in are on their way out.

The HTML example is currently as follows:

For example, HTML web pages are declarative because they describe what the page should look like — title, font, text, images — but not how to actually display the page on a computer screen.

This is thus fundamentally wrong. HTML doesn't describe what the page looks like, that's the job of stylesheets (CSS, XSLT, etc), it describes what the page consists of. It structures the content of the website and denotes relations (hence "Hypertext") between the document and other files or entities.

According to the second definition, HTML is definitely not a declarative programming language. Another snippet says:

In a declarative program you write (declare) a data structure that is processed by a standard algorithm (for that language) to produce the desired result. When you write a web page for example, you declare what the page should look like in HTML, and the browser's procedural algorithm translates this into the pixels on the display.

When you write a web page, you declare its structure and content (i.e. semantics) in HTML. CSS describes the styling.

Also, unlike someone stated earlier on this Talk page, XML is not a declarative programming language in any sense, because it is only a syntax. XML dialects can be declarative, but XML itself does not have any semantics beyond the XML headers. In that sense, XML is merely a standardised format for markup languages, not a markup language of that format itself. It's not much more of a language than ASCII or comma-separated values.

Further, the first definition of declarative languages is a bit vague. It could be used to label any data format that is not an imperative programming language a declarative programming language. This clashes with the definition of a "programming language".

Calling semantic HTML (granted, prior to HTML 4.01 it did have a lot of presentation mixed into it) a programming language is misleading at best. To quote the article "programming language":

Non-computational languages, such as markup languages like HTML or formal grammars like BNF, are usually not considered programming languages; however, informal usage sometimes includes them.

As an aside: SGML has "processing instructions", but I wouldn't rate them as anything but a more generic form of the modifier glyphs found in Unicode.

Apparently the first definition in this article rates anything with even a hint of embedded meta-data as a declarative programming language. This use is not only vague, but I would say that it is heavily disputed and non-standard. I've removed the passages about HTML from this article and Declarative programming language (a bit of redundant an article, IMO). Feel free to put them back in, but only if you can find a less authorative wording. — Ashmodai (talk · contribs) 10:45, 27 August 2006 (UTC)

Anyone else think that the link to business rules seems a bit out of place? AliaGemma 04:20, 12 January 2007 (UTC)


HTML is not a programming language

Based on this (rather) simple affirmation, I just don't understand why HTML is cited as an example in that article: an example such this could be misleading for all the non-experts (Oh, then HTML is a declarative programming language? Cool!) —Preceding unsigned comment added by 87.17.195.204 (talk) 10:43, 19 September 2007 (UTC)

Why do you not provide a different example then? Insisting on HTML not being a proper programming language does not help anyone, it is just the usual "I am a true programmer" attitude. The HTML example is very good; you can immediately understand what declarative definitions are about. Anyone in doubt about HTML being a programmin language will be cured by a quick click on the referenced page. 129.187.228.194 (talk) 13:30, 6 May 2008 (UTC)

Another angle on this

This article is written as if declarative programming were strictly a property of languages. In fact, it is also a technique that can be deployed in an imperative language. For example, you can write a C++ function that does some task (or tasks) based on the contents of a (typically static const) array (or other structure) initialized as part of the code. A developer can then effectively accomplish certain programming tasks by changing the content of that array: effectively, declarative programming. I've certainly used this technique, but I am not offhand familiar with a citable reference. If someone has something citable, this probably would merit mention. - Jmabel | Talk 22:00, 1 February 2008 (UTC)

Like table-driven methods in Code Complete? Skilldrick (talk) 10:36, 29 July 2010 (UTC)

Merged and rewritten

I merged declarative programming language into this article, and rewrote huge parts of it. There were some pretty horrible things in both articles. Factually wrong things ("Purely declarative languages don't compute anything") to obnoxious things (parts of the article seemed to be written by someone I can only assume was well-meaning but didn't understand the topic) or just horribly written or irrelevant. Hopefully my replacement is better!

Article still badly in need of references for things, though.

Would someone more enterprising than me consider refactoring this (and the the talk page from Talk:declarative programming language) or archiving them or something? This talk page is excessively long and discussions exist on things that seem to be long dead. Tejoka (talk) 06:58, 5 October 2008 (UTC)

Functional programming is not declarative

To quote the relevant section from the article:

"Functional programming, and in particular purely functional programming, attempts to minimize or eliminate side effects, and is therefore considered declarative. Most functional languages, such as Scheme, Objective Caml and Unlambda, however, do permit side effects in practice.
While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs. This can be used to, for example, make a function compute its result in parallel, or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."

These two paragraphs are completely bogus. Let's take them apart:

  • "Functional programming, [...], attempts to minimize or eliminate side effects, and is therefore considered declarative."
    No, that's neither a sufficient, nor a necessary, condition for declarative programming! For example, a side-effect, like setting a memory location or writing to a file, could be described in a declarative way (e.g. using pre- and post-conditions).
  • "While functional languages typically do appear to specify "how" [...]"
    They don't just appear to specify "how", they actually do! Every valid functional program represents an algorithm, and algorithms describe how to compute a result.
  • "a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs."
    So does a compiler for an imperative programming language; in fact, for basically every language, the compiler is allowed to do that (it's generally called "optimization").
  • "or to perform substantial optimizations (such as deforestation) that a compiler may not be able to safely apply to a language with side effects."
    Most FP languages are not side-effect free, so the same limitations exist for them as for imperative languages.

The main problem with this section is that it tries to demonstrate that FP languages are declarative, which is not the case (although I often read this false claim). If no one objects, I'll remove it completely. – Adrian Willenbücher (talk) 09:39, 22 September 2011 (UTC)

While I personally agree with the view that functional languages (especially the impure/strict variants) are not declarative (nor do I consider Prolog to be), these languages are overwhelmingly described as such in reliable sources. You would need to find some equally reliable sources that support your reasoning. —Ruud 07:31, 27 September 2011 (UTC)
Some arguments that functional languages are declarative would be that in lazy functional languages the programmer does not have to worry in which order the computations are performed, they are automatically executed in an order that "just works". —Ruud 07:37, 27 September 2011 (UTC)
I would like to see this "overwhelming" evidence in reliable sources. Further points:
  • By your reasoning, only pure, non-strict functional programming languages are declarative. That's quite a difference to functional programming languages in general.
  • In what way is Prolog not declarative? That's the archetype of declarative programming languages.
  • "Some arguments that functional languages are declarative would be that in lazy functional languages the programmer does not have to worry in which order the computations are performed, they are automatically executed in an order that 'just works'."
That argument doesn't work:
  • Just because the order of evaluation isn't determined by the programmer, doesn't mean that the programmer doesn't define the "how". Consider the following Haskell code:
fac 0 = 0
fac n = n * fac (n - 1)
This is purely functional code, but it still defines how to compute the factorial, even if it is evaluated in a lazy, out-of-order, way.
  • C doesn't define an order of evaluation either, and yet you wouldn't say that it is declarative, would you?
My point is not that functional programming is completely distinct from declarative programming; rather that FP it is not a subset of DP. Even if some functional programming languages are considered declarative, that doesn't mean that FP in general is declarative; you could design an object-orient language with pure semantics (i.e., no state, only non-destructive update), and yet you don't consider OO to be a subset of declarative programming. – Adrian Willenbücher (talk) 09:24, 27 September 2011 (UTC)
In th factorial example the order of evaluation is very obvious to infer from the definition, this is no longer the case in, for example, the rep-min problem or when working with attribute grammars. And yes, compilers for imperative languages have some room when deciding the order of evaluation for simple expressions, but in the end most side-effect have to happen in the order the programmer dictated. If you have done any substantial programming in Prolog, you'll know that for solving any non-trival problem you'll have to heavily rely on the order in which the backtracking algorithm tries to unify Horn-clauses (the order of which is determined by the order in the source code) and ofcourse the usual reliance on the cut operator. To me Prolog has an even more imperative feel than Haskell. I don't know of any truly declarative language in the ideal sense of the word. Perhaps CPLEX linear programming problem instances come close, but it's a bit of a stretch to call that a programming language. My and your personal opinion aside, pick up a few book listed Programming language#Further reading and they will likely divide the language landscape into imperative and declarative language, with declarative languages being composed of functional and logic programming languages. —Ruud 09:47, 27 September 2011 (UTC)
I agree that our personal opinions don't really matter, but reliable sources do (and I shouldn't push my agenda here). I found at least one source that lists FP alongside declarative programming (Finkel: Advanced Programming Language Design), without any mention of one being a subset of the other. However, I also acknowledge that some sources make this classification. How about we present the complete picture: some authors consider FP to be a subset of DP, some don't? That would be the way to do it in an encyclopedia. – Adrian Willenbücher (talk) 11:31, 27 September 2011 (UTC)
Sure, as a tertiary source Wikipedia articles should simply summarize secondary sources. So any statement about functional languages being or not being declarative languages you can find in reliable source, would be good additions to the article. Simply removing the section on functional languages didn't seem like an improvement though. —Ruud 11:38, 27 September 2011 (UTC)
Also, while I'm not completely sure about the etymology of imperative vs. declarative, I think it's because languages like COBOL and FORTAN programs are lists of imperatives (statements), while LISP and Prolog programs are lists of declarations (definitions, equalities, implications, ...) The part about declarative languages allowing you to state only what the problem is and not explicitly how to solve it, is probably only some (academic) marketing-speak invented later and which doesn't fully hold for any declarative language. —Ruud 11:38, 27 September 2011 (UTC)
Actually, as far as I know, LISP is very imperative for a functional language. Regarding terminology: calling a language "declarative" just because it contains a lot of declarations is not very useful today, since basically all languages (except for those that are strongly based on the lambda calculus or Turing machines) contain a lot of declarations (variables, functions, classes, etc.). Some authors call a language "declarative" iff variables are explicitly declared. As for your last sentence ("...which doesn't fully hold for any declarative language."): the boundary between "how" and "what" is rather fuzzy; for example, does this function state an algorithm ("how"), or a declaration ("what"), assuming that product is a function defined earlier:
fac n = product [1 .. n]

– Adrian Willenbücher (talk) 12:44, 27 September 2011 (UTC)

It even claims that functional is declarative because the compiler might rewrite the functions. Well in that case, C is declarative too! Whoopsie. 2001:470:1F04:3DF:0:0:0:2 (talk) 22:07, 5 July 2013 (UTC)

Hello fellow Wikipedians,

I have just added archive links to one external link on Declarative programming. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 08:30, 17 October 2015 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Declarative_programming/Archive_1&oldid=1093488773"