Declarative Definition Discussion One
Declarative Definition Discussion OneBelow is older contents for DeclarativeDefinition. None of the proposed definitions survive at the moment.
Proposed Def 1: A feature F of a program-fragment P is 'declarative' insofar as P describes the requirement(s) for F whilst eschewing description of the plan, strategy, mechanism, or machinery for achieving F. [since recanted by original author; this is really GoalBasedProgramming, which is a subset of declarative systems.]
example, contrast, and clarifications under proposed def 1:
Note that 'feature' F may be a result (such as output from a function), or some other feature (like a request for real-time computation), and that under this definition any given program-fragment P may be declarative in some features but not in others.
'Program fragment' may include whole programs, statements, expressions, definitions, procedures, modules, etc. - any chunk of code that you can usefully delimit from the rest of the program. (Originally called 'sub-program', but clarified here to reduce confusion with the imperative concept of subroutines.)
Note that 'requirements' include 'do's as well as 'do not's. The latter is commonly called 'constraints'.
Note that between two programs under this definition, one could reasonably be claimed 'more' declarative by achieving 'more features' declaratively. This puts "declarative"-as-a-whole not on a continuous scale, but rather in a lattice; i.e. for features A, B, C one could say {A,B,C} declaratively is "strictly more declarative" than {A,B} declaratively, but cannot directly compare {A,C} declaratively vs {A,B} declaratively. Nonetheless, the proposed definition is in terms of individual features for program fragments, not feature-sets for whole-programs, and one would be better sticking to the definition when precision is needed.
DeclarativeProgramming - as a discipline or paradigm - is programming where declarative feature 'F' in the above definition is the output of a computation. Composition in DeclarativeProgramming is composition of output requirements, not composition of approach. TermRewriteSystem?s, LogicProgramming, ConstraintProgramming, and especially ConstraintLogicProgramming, are by far the most 'declarative' paradigms - at least of what has been invented thus far - under the above definition.
DeclarativeMetaprogramming is DeclarativeProgramming where the output is itself a program (may be any sort of program: declarative, procedural, functional, OOP, a compiler, an OperatingSystem, another declarative metaprogram, etc.). DeclarativeMetaprogramming has the potential to be more-declarative than declarative, in the sense that every feature of the resulting program - the result of the result-program, its energy cost, its space cost and footprint, its time cost, its execution timing, its safety, which external systems it is free to hook, etc. - can potentially be 'declared' as requirements and constraints rather than mechanism. OTOH, while DeclarativeMetaprogramming as a technique has seen some powerful proofs-of-concept in compiler and optimizer development, it as of yet lacks any implementation suitable for general SystemsSoftware and application development.
Under proposed def 1, a program fragment P might be called declarative for feature F even if the program fragment describes a strategy, but it must be the case that the strategy/plan/sketched-list-of-subgoals is there merely as a suggestion as in "this is how I'd achieve F, but you're free to try something else". By 'mere suggestion' I mean that the SufficientlySmartCompiler/Interpreter must be allowed to completely drop and ignore 'suggestions' ('completely' meaning as if they aren't even part of the source-code) in favor of building from original requirements and/or favoring its learned and built-in strategies.
In practice, DeclarativeProgramming typically involves detailing these suggested strategies along with the requirements, because in practice there is no such thing as a SufficientlySmartCompiler. However, unlike procedural/OOP/etc. there is a clear linguistic barrier between 'requirement' vs. 'strategy', thereby allowing a moderately smart interpreter to replace naive strategies with better ones.
By comparison to DeclarativeProgramming, Procedural and Functional programs lay out the law: thou shalt perform operation Y. There is no claim like 'perform operation Y in order to achieve result F'. It's just 'do Y'. Interpreters of procedural and functional code are forced to assume that the goal/requirement - that which the programmer is attempting to achieve - is exactly to perform the operation requested. Under definition 1, this isn't declarative at all, since it doesn't "describe requirements whilst eschewing the plan/strategy/etc." Realistically, of course, the programmers are generally eminently aware of a vast distance between their goal and the expression of it via selecting a particular strategy in functional or procedural. They call this strategy the 'implementation'.
Still, functional is said to be "more declarative" than procedural in terms of other features. For example, programmer in a functional language needn't concern himself as much with 'memory layout' and (for pure functional) 'order of operation'.
Similarly, StaticTyping, DynamicTyping, and Contracts are not the same as DeclarativeProgramming. Contracts tell the compiler/interpreter when to reject a strategy (or when to halt a program fragment at runtime because it isn't working), but the strategy/implementation code itself is still the ultimate arbiter of what the program should be doing. That is, the compiler/interpreter is not free to ignore the strategy as a mere suggestion, and find its own way to achieve the contracts. This is in part because the contracts themselves are incomplete. With DeclarativeProgramming, strategy can be ignored; the requirements are the program, and the strategy is 'just' expert advice to a compiler.
Ultimately, one can still greenspun DeclarativeProgramming via an API or Framework, even in functional and procedural languages. ApiIsLanguage and FrameworkIsLanguage still applies, after all, and one may with sufficient MetaProgramming effort crawl oneself out of a TuringTarpit. But since Proposed Def 1 applies to program fragments, one could easily delimit the extent of where DeclarativeProgramming is occuring and draw lines where program composition happens to be procedural or functional instead of declarative.
SoftwareTransactionalMemory is declarative with respect to the atomicity feature because the programmer says that a program fragment is to be atomic, but does not say how to achieve it.
Is that the sort of definition you were looking for?
I believe there to be overlap between "what" to do and "how" to do it.
How is that belief relevant? (A) A belief presented without justification is meaningless as a point of discussion even if there are gross flaws in the above definition. (B) The above proposed definition is not defined in terms of "what to do" or "how to do it", so even if your belief is justifiable, it is unclear how it is relevant.
Consider FuzzyDistinctionBetweenInterfaceAndImplementation, for one.
How is doing so useful? TopMind fails to make a convincing argument on that page, but, even if you're convinced that Top's examples defensibly support his conclusion, it remains utterly unclear how that discussion is logically relevant as a point for or against proposed definition 1. Where does proposed def 1 depend upon a distinction between interface and implementation? Where does it involve the concept of 'interface' at all?
Let me re-approach this by asking questions. First, how would one use your definition to determine if HTML was "declarative" or not?
MuAnswer. HTML (as a programming language) is not a feature of a subprogram, therefore proposed definition 1 does not apply. Let me ask you a question in turn: Was there something unclear about: "the proposed definition is in terms of individual features for program fragments, not feature-sets for whole-programs"? Or are you objecting to the definition without even having read it and its clarification?
Valid questions would include: "is the text printed by an HTML subprogram declarative?" or "is the paragraph layout of HTML declarative?" or "is the bold emphasis property for HTML output text declarative?" to which the answers are no, no, and yes respectively. As noted in the explanation below the proposed one-sentence definition, one could reasonably discuss whether HTML is 'more' or 'less' declarative than some comparable language on a feature-lattice. E.g. HTML could probably be argued 'more' declarative than PostScript on the basis of having a strict superset of declarative features. But 'declarative' itself is in terms of specific features.
If you wish to ask whether HTML supports DeclarativeProgramming paradigm (described above as achieving the output features in terms of requirements), I'd say NO because HTML doesn't allow describing the text content, linkage, paragraph layouts, etc. - the vast bulk of the output features - in terms of requirements.
Let's focus on "declarative language" instead of "declarative programming".
Why do that? Unless you mean "declarative programming language", I think the generic question of "declarative language" falls outside the scope of WikiWiki - WikiIsNotaDictionary. If you do mean "declarative programming language", then focusing on the 'language' aspect only complicates issues, since you must now decide the unrelated question of what qualifies the language: a language that supports DeclarativeProgramming vs. a language that enforces DeclarativeProgramming. Anyway, until you can make a convincing argument that doing so is fruitful, I'm considering the change in focus a RedHerring.
It seems your definition cannot answer, "Is HTML a declarative language" in an absolute because it focuses narrowly on a specific portion of an app (sub-program). While a relative definition may be useful for some purposes, it's not useful enough. Most would expect more than a MuAnswer. -t
You claim that the ability to compare two languages in terms of supporting declarative properties on a lattice is "not useful enough". I ask that you justify that claim. What are your requirements for "useful enough", and how do you justify those requirements? Can you make a convincing argument that properties one might ascribe to languages - "declarative" or "expressive" or "secure" or "safe", for example - can and should be something other than relative to other languages?
It's possible for something to participate in "why" and "how" at the same time. -t
Where, precisely, does proposed definition 1 mention "why" or "how" or require that the two be mutually exclusive?
To make sure we're both interpreting Def 1 the same, here's a programming-like re-statement of Def 1 as I interpret it:
[withdrawn for rework]Is this a satisfactory re-statement?
Further, "sub-program" is a little dicey. Declarativeness is not about "sub-programs" as most people think of them. That's too narrow. Why does it have to be worded in the context of a sub-program?
On what basis do you claim "declarativeness is not about sub-programs"? And what is it that you believe "most people think of" sub-programs? I'm willing to clarify the use of that word above. But avoiding focus on 'language' has considerable advantage when considering MultiParadigmProgrammingLanguage and greenspunning, since it allows one to determine 'declarative' independently of language (i.e. one could do declarative programming atop a framework or API, possibly a few macros). This also better matches use of 'functional programming' and 'OOP' and such, since it is often noted one can (with SelfDiscipline) do functional programming or OOP in languages that aren't designed to support it. Using "sub-program" allows determining this feature for individual program-fragments - which all programs contain by necessity - and simultaneously avoids concerns about the 'edges' of 'whole-programs'. Your claim of "too narrow" seems illogical and backwards to me. What would you replace "sub-program" with that would have broader application?
Sub-program is an imperative concept so it's basically saying that declarativeness can only be determined in the context of an imperative part, which doesn't fit usual usage.
In general, sub-program is not an imperative concept. (From WikiPedia: "In computer science, a subroutine or subprogram (also called procedure, method, function, or routine) is a portion of code within a larger program, which performs a specific task and is relatively independent of the remaining code.") But I'm willing to clarify it above as meaning 'program fragment' if you find it confusing as is.
Yes, "program fragment" is better. There's no need to tie it to "task".
Changed.
Now back to the original issue. One can only test your definition's application to HTML (and other tings) as it's used within a particular program-fragment. Is this your intent? If so, is it consistent with usage?
Yes, and yes. That is my intent, and it is consistent with usage. With a definition in terms of program fragments, one would analyze 'declarative' properties of languages, SoftwareDesignPatterns, frameworks, APIs, etc. in relative terms of how well they 'support' or 'enforce' or 'hinder' achieving declarative properties for program fragments (FourLevelsOfFeature), and in how many (and which) features can be simultaneously achieved in a declarative manner. The ability to analyze languages and programming styles in relative terms is consistent with common usage; for example, it is commonly accepted that (with regards to how 'declarative' programming designs are for the 'output' features), ConstraintLogicProgramming > {ConstraintProgramming | LogicProgramming} > TermRewriteSystem? > FunctionalProgramming > ProceduralProgramming.
When discussing language, relative support/hindrance/enforcement is also consistent with discussion of other programming styles... e.g. one can discuss the properties of OOP or FunctionalProgramming or ProceduralProgramming styles, then may intelligently discuss language support for these styles, separately. Proposed definition 1 achieves the same for declarative programming.
Finally, the definition is consistent with 'declarative features' as a whole rather than with DeclarativeProgramming in particular. That is, more than just output can be declarative. One can also have: declarative concurrency, declarative workflow and synchronization, declarative laziness, declarative persistence, declarative security requirements, declarative DependencyInjection, declarative PolicyInjection, declarative ProcessAccounting, etc. It is commonly stated in LanguageDesign circles (like LambdaTheUltimate) that FunctionalReactiveProgramming and DataflowProgramming styles are "more declarative" than FunctionalProgramming because they achieve more declarative features - in particular, declarative binding of input rather than output. (That doesn't mean one can't do FRP inside an 'FP language' with sufficient SelfDiscipline, of course, but one may still compare FP language to FRP language in terms of support for declarative properties.)
So yes, this is consistent with usage. It is consistent with usage that "declarative-ness" be relative - and not just relative, but on a lattice
It is consistent with usage that specific properties of a program or program-fragment be described as declarative. It is consistent with usage that 'declarative' be used to describe relative properties of APIs, protocols, and frameworks rather than associated with a particular syntax.It is inconsistent with usage to ask: "is HTML declarative" without following it with something like "relative to PostScript". If one does follow it with "relative to PostScript", then in practice the question translates to "to what degree does HTML support (or enforce) construction of program fragments with more declarative features than fragments of PostScript written to achieve the same end... eliding non-standard frameworks".
I have to disagree. Asking, "Is HTML declarative" is common-place, and so is saying, "HTML is a declarative language". No, I cannot cite references at this time.
Right. I'll just take your word for it, then. The relevant question, though, is what does the question "Is HTML declarative" or the answer "HTML is a declarative language" mean? I.e. there is an implied context in which this question is asked. I assert that the implied context is: <relative to its competitors>, as in "Is HTML declarative relative to its competitors?" and "Yes, HTML is a declarative language relative to its competitors". The question is not asking for an absolute answer, and the answer itself is not absolute (except in the sense of "HTML is absolutely more declarative than its competitors"). Its competitors, at this time, are PostScript, Flash, and a few others (LogoLanguage, anyone? And even OpenGl or PovRay could be compared).
Do you, TopMind, believe people would be confused upon receiving "More so than some, less so than others" as answer to "Is HTML declarative?" Do you honestly believe that the people asking that question are expecting an absolute answer?
Regarding restriction to "programming":
I have to disagree. Asking, "Is HTML declarative" is common-place, and so is saying, "HTML is a declarative language". No, I cannot cite references at this time.
[A pointless question and a pointless answer. HTML is a markup language, not a programming language, so its declarativeness isn't relevant, let alone interesting or meaningful.]
This topic is about "declarative", not DeclarativeProgrammingLanguage?. Let me restate the question: "Is HTML a declarative language"? I'm happy to narrow the scope to "language" to avoid getting way off topic, but "programming language" is too narrow (or at least introduces other elements that may be distracting to the original purpose of the topic).
This topic is on WikiWiki. The topic being about "declarative" in the context of "programming" is implied (though I accept that DeclarativeProgramming is a rather specific subset of 'declarative' properties in-context-of programming). That said, I'd argue that HTML and markup-languages intended for processing by CPUs are programming languages... just not of the GeneralPurposeProgrammingLanguage variety. One could also make cases for HTML+PHP, HtmlDomJsCss, HTML + Flapjax, and other toolkit combinations as 'languages' (after all, ApiIsLanguage and FrameworkIsLanguage).
[It - "Is HTML a declarative language?" - is still a pointless question. What is gained by any possible answer?]
Why is it pointless? Is it because it doesn't fit YOUR definition? That may be a problem with the def, not the question.
[Again, what is gained by any possible answer?]
Any possible answer? Even MuAnswer can be enlightening in the absence of other information. "Are triangles angry?" "Is HTML declarative?" "Does dog have Buddha nature?" MuAnswer.
Most people consider it a property of a given item. You seem to define it as only a relationship. This is not how most people think of it. Definitions are generally shaped by usage. You created a very narrow definition that seems to ignore common usage. It's true that common usage is somethings poorly thought-out or only approximate or "notion-esque", but creating a WalledGarden definition only serves as a local working definition at best if it does not connect well with actual usage. -t
[That is a non-sequitur answer. Back to the issue at hand: What is gained by any possible answer to "Is HTML a declarative language?". Or, assume the answer is 'yes'. What do we know that we didn't know before? Assume the answer is 'no'. What do we know that we didn't know before?]
Well, to be circular, that depends on the definition of "declarative".
RE: "most people consider"
I think you presume far too much about what "most people consider" 'declarative' to mean, or how they use it. I suspect "most people" are intelligent enough to recognize "does HTML have declarative paragraph layout?" to be a valid question. I suspect "most people" are intelligent enough to follow and understand: "if markup-language A has declarative layout, and markup language B has layout that is encoded by position in text, and they are otherwise the same, then markup language A is (overall) more declarative than B". I suspect that you're not even an exception to this - rather, you simply think too little of layman intellect. People who use 'declarative' in the informal sense are perfectly happy to, when pressed on what they mean by 'is HTML declarative', say: "well, what I meant was declarative relative to XYZ" or perhaps "what I meant by saying 'HTML is declarative' is that particular features F,G,H are encoded in HTML in a declarative manner".
Methinks your attempt to play DevilsAdvocate for "most people" succeeds primarily in misrepresenting and insulting most people. If you have a failed understanding, claim it for yourself. Do not hide behind this false persona of the common man.
We don't have surveys either way, so we can simply make observations and guesses based on experience. If the other party questions it, then so be it. No need to accuse them of dastardly deeds. We can simply create a definition under both paths and LetTheReaderDecide which path to apply.
And I don't believe most would want to compare. Instead, they'll say something like, "It does not describe specific steps to carry it out, instead only provides an abstract concept. Therefore, it's declarative."
That'd meet my definition. But one should note that "carry it out" and "it's declarative" are coupled. That is, one might say: "I don't need to describe specific steps to <MAKE MY TEXT BOLD>, therefore <MAKING MY TEXT BOLD> is declarative". One should not conclude that paragraph-layout is declarative on the basis that text-bold-emphasis is declarative. One should not conclude that HTML-as-a-whole is declarative on the basis that text-bold-emphasis is declarative. Even if 'most' don't bother clarifying it, what they actually mean when they say "declarative" is still specific to given features of given program fragments.
The idea of "steps" seems key, which takes us to Def 3. -t
A set or list of "steps" is one way of describing a plan. That relates to proposed def 1. Def 3 is far more narrow; as written, 'steps' aren't even included at all (only ordering constraints on steps are problematic).
What are some examples of HTML clearly not being "declarative"? -t
Non-declarative aspects of an HTML application include (but are not limited to):
The text and images themselves are not declarative. For example, I can't say: "the text here should describe elephants" (albeit in some formal description of requirements for what it means to describe elephants). Instead, I must lay out (step by step, word by word) specific text. Merely 'having' output isn't sufficient criterion to claim something non-declarative.
I could combine HTML with some other language, like flapjax, to achieve somewhat declarative text - i.e. the ability to specify text as being the average stock price of tea in China for the last ten days. As is, of course, there aren't any good fully declarative text generators in this world (such a tool would be a major boon for video-game dialogue generation).
With regard to paragraph ordering, would the following be more declarative, and if so, why?
<paragraph order="124">
Second paragraph.
</paragraph>
<paragraph order="123">
First paragraph.
</paragraph>
Not so much, no. You could reasonably argue that the order of paragraphs is no longer bound to the order of program description, so it'd be slightly more declarative in that sense. But declarative layout really means the ability to declare layout properties independently from the elements being laid out. This would be more declarative:
<paragraph ID="1" topic="elephant"> ... </paragraph> <paragraph ID="1" topic="giraffe"> ... </paragraph> <paragraph ID="2" topic="elephant"> ... </paragraph> <paragraph ID="3" topic="giraffe"> ... </paragraph> <paragraph ID="3" topic="elephant"> ... </paragraph> <paragraph ID="2" topic="giraffe"> ... </paragraph> <paragraph-order-by>topic,ID</paragraph-order-by>I'd call that "indirection", not necessarily "declarative".
That's hardly relevant. "Indirect" and "declarative" are orthogonal, not contradictory. In any case, the above example is one way - among many - of making paragraph layout more declarative. But if you must weave a specific 'plan' for paragraph layout directly into the 'paragraph description code', then that is not particularly declarative. As HTML is right now, you can't even specify paragraph layout independently from the code layout.
;;Hello Name! 3 V = getline 5 print V 2 print "What is your name?" 6 end 1 begin 4 print "Hello, "That's about equivalent to adding an "order" property to paragraphs.
Reminds me of the old days when we'd drop a stack of punched cards and plead with all known deities that we kept the card sequence numbers up-to-date. "Bob, watch while I make your card deck more declarative."
Proposed Definition 2: Certain code is identifiably "declarative" to precisely the same degree that certain art is "beautiful". I.e., the quality is intuitively obvious, but identifying why it is so is utterly elusive.
(Tongue firmly in cheek.)
Proposed Definition 3: Free of time-related constraints or assumptions.
This is only an experimental definition. The usual "what" versus "how" approach seems problematic because they can and do overlap or are difficult to clearly classify. Even an English statement ties the requirements to English, which alters or limits expression.
Time seems to be a common property separating "imperative" from "declarative". Whether it's the defining property or a secondary property with close ties to the undefined "real" property is still worthy of exploration. -top
Declarative programs can declare time-related constraints and assumptions. I.e. "thou shalt beep beginning no later than 0.05 ms after event E, and thou shalt halt beeping no earlier than 2.00 ms after E and no later than 2.05 ms after E." Declarative workflow, DataflowProgramming, and rule-based programming (which combines EventDrivenProgramming with LogicProgramming) tend to use such time-related constraints quite often. Multi-media programming, e.g. of animation, video, and sound/music, use time-related constraints as part and parcel to the system. I suspect that "proposed definition 3" needs severe modification for cases where 'time' itself is an integral part of the domain being modeled.
Good point. I'll work on it. It may need a modifier along the lines of "...that are not directly part of the domain." -t
"Programming without explicit control over program flow" may be closer to what you are aiming. Some people mean that by 'declarative programming', though it fails to encompass other declarative properties.
But then we'd have to define "flow".
That'd be unnecessary. You need to define "explicit control over program flow". In English, a word-phrase can have a meaning narrower or distinct from the intersection of the meaning of the individual words... and, therefore, you may define word-phrases. If you were feeling adventurous, you could define "program flow" and "explicit control" separately, but there'd be no logical requirement to do so. Attempting to define "flow" overall would almost certainly be a waste of effort: a reference to a dictionary would serve you better.
That said, one could choose other words. One could reasonably say: "declarative often refers to atemporal semantics - that is, where the order in which program statements are processed is not controlled by the programmer and does not determine the behavior of the program." This describes a common notion of 'declarative programming' in the sense that includes (pure) FunctionalProgramming.
Regardless, I believe a definition is too narrow if it doesn't apply to other things called 'declarative' in software development, such as declarative layout. I further believe it important to account for the fact that, in practice, 'declarative' really, truly, isn't absolute. It has been my observation that practitioners who have used both really do consider FunctionalReactiveProgramming (with its declarative data binding) to be 'more' declarative than FunctionalProgramming. Same for LogicProgramming vs. FunctionalProgramming (FunctionalProgramming is considered less declarative because it binds computation strategy). Proposed definition 3 fails me in both these properties.
By the way, perhaps we could answer "are triangles angry" if we settle on WhatIsIntent.
I doubt it.
EditText of this page
(last edited September 14, 2014)
or FindPage with title or text search