Below 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''' *** http://en.wikipedia.org/wiki/Lattice_%28order%29 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: '''', 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 , therefore 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): * its output text and images * its paragraph and list layout (i.e. which paragraphs or list elements are before/after others are not declarative) * coloration schemes and other high-level 'policy' (though support for integrated features like CascadingStyleSheets can help here) * form and user-input processing, and user session management * meta-level operations (refresh) * linking ''How are these not "declarative"? How is having output non-declarative?'' 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?'' Second paragraph. First 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: ... ... ... ... ... ... topic,ID ''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. * ''That seems a rather arbitrary attribute to assign to "declarative". Again, I think of "indirection" there, and not "more declarative". But language is often shaped by how we as individuals think. Past a certain point, a collective consensus may begin to fall apart. I suspect you are slicing and dicing past that threshold by squeezing it too hard. -t'' * Sigh. Here's an analogous rewording of what you said from my perspective: ''"Again, I think of 'walls' there, not 'red'."'' Riiiight, that made sense. If you learned the word "red" only as it applies to coffee cups, and therefore nothing but coffee cups can be red in your thoughts, perhaps that position makes sense to you. Somehow, clearly, ''"Again, I think of 'indirection' there, not 'declarative'"'' strikes you as an intelligent position. '''In practice''' the word "red" is used to modify more than coffee cups - one may also have red walls and red hair, for example. '''In practice''', the word "declarative" is used in the context of SoftwareDevelopment to modify more than "language" and "programming" - one may also have declarative concurrency and declarative layout, for example. In my thoughts, you're that guy who only learned about red coffee cups, and who is now chastising me for calling a wall 'red'. * ''Let me restate it. The difference between A and B is indirection, not declarativeness. If indirection is somehow closely allied with declarativeness, then please describe the relationship per your def.'' * Since you seem blinded by one irrelevant distinction and yet ''blind'' to ''other'' irrelevant distinctions, perhaps I can help clarify: The '''many''' differences between A and B include declarativeness AND attribute names AND structure primitives AND SeparationOfConcerns AND indirect reference of attributes AND spacing AND potentially quite a few other things. Most of those differences are irrelevant. Indirection is included among the irrelevant things. That is something I already told you (though you apparently failed to grok) when I earlier stated that indirection is an 'orthogonal' concern. * ''You went off on an unsubstantiated silly analogy. It may indeed involve lots of factors, but the primary difference between the two examples was indirection. -t'' * You claim that to be the "primary difference". Now '''please justify that claim.''' * ''It's the ONLY difference. SofC is in your head only because code has no "concerns". It can't think.'' * The 'separation' of the code describing paragraph layout and the code describing the paragraphs is not 'in my head only'. * ''If we use a wide definition like that, then all indirection is separation, and we are back to the same argument again. Vuja De.'' * The '''separation''' is one of two "primary differences" between the examples. Not all separation involves indirection; the indirection above (naming of attributes) was merely a convenient technique to achieve separation. Regarding your 'vuja de' comment (clever phrase): it is ''illogical'' to assert, simultaneously, that 'indirection is the only difference' and 'indirection implies separation' unless you also assert that 'no '''new''' separation was achieved by the indirection'. Did you intend to take that irrational position? * ''Unless we have a clear way to isolate, test existence of, and study what you mean by "separation", it's not likely this conversation will be fruitful. I want to study code, not your head.'' * Then study the code rather than doing your usual ritual of song and dance and HandWaving to claim that "indirection is the ONLY difference" and summarily deny the relevance of an example. (Yeah, you hypocrite, please give me a clear way to isolate, test existence of, and study what you mean by "indirection" so your comment will be fruitful.) Take your irrational double-standards and shove them up your fucking arse, TopMind. * ''What you fail to grasp is that ProgrammingIsInTheMind. Your classification model is shaped by how you think, not a universal external concept, at least not the only possible universal external concept. I cannot objectively "prove" that indirection is the only difference because you can make up your own (convoluted) model where it *isn't* the only difference. I believe that indirection is the only objective difference because we can make the given transformation without any reason other than to increase indirection, and it would still take place. We can do it without any plan or intent to separate "concepts". We can write a mechanical "indirection-A-matic" that sticks in indirection for the sake of indirection. Separation may perhaps be a side-effect of indirection, but it's still merely a side-effect. Indirection almost by definition creates more separation. What's missing is "concerns". That's in the reader's or maintainer's head. -t'' * Your logic is flawed. I say: ''"Heat transforms water to steam. Therefore, the only objective difference between my water and your steam is heat."'' Would I be right? Or how about ''"Adding 9 turns 4 into 13. Therefore, the only objective difference between 4 and 13 is the addition of 9."'' Okay, so that means they're both ''even'' and ''composite'' numbers, correct? Note that adding 9 doesn't even '''imply''' getting a prime-number (or an odd number), but there you are. What you fail to grasp is that "transformation" is not something you can trivially dismiss. Transformations are important, and concrete. ** ''So it may change your classification if one doesn't have information about the transformation itself, only the before and after? -t'' ** Classification can change '''whether or not''' one has information about the transformation. ** ''In general, I agree. However, we are talking about "transformation" only.'' * Further, "code" is not in-the-mind. And while "concerns" may be in the mind, they are expressed in concrete "code". SeparationOfConcerns refers to separating "in the mind" concerns into different chunks of code. For example, one might separate the expression of paragraph-order into a separate chunk of code than the expression of paragraph-descriptors. Here's a few more you should agree with: ''"The code doesn't have any paragraphs. The 'paragraphs' in the above examples are in the reader's or maintainer's head. The code has no order. The order you read the code is in your head. The code has no attributes called 'order'. The concept of attributes and 'calling' is in the reader's or maintainer's head. The code has no '''indirection'''. The concept of indirection is entirely. in. the. reader's. head."'' * ''Well, it's all relative. If you classify the base (givens) different, you get different conclusions. Welcome to relativity land. -t'' * Your 'relativity land' requires '''inconsistent premises''' - an inconsistent set of "base (givens)" - where you choose at one moment to say that classifications are 'in-the-reader's-head', yet inconsistently choose to apply meta-classifications like 'objective', 'subjective', and 'relative' as though the classifications are not 'in-the-reader's-head'. I don't condone that sort of equivocation, fallacy, ''sophistry'' if you do it intentionally. You think I was taking a few steps into your 'relativity land' with the set of statements "you should agree with", but in truth I was calling you on your inconsistency. * ''But you are forcing a model in order to achieve local rigor. AddingEpicycles. Ideally we want a simple model that matches people's impressions of the concept. But simple models are not your strength.'' * Logically consistent models are apparently not ''your'' strength. If your goal is to argue that most people use 'relative' and 'objective' and 'subjective' inconsistently, then you should gather evidence for that position and support it explicitly rather than assuming then HandWaving on their behalf. Perhaps you should also gather some information about whether the 'people' you claim to represent on a technical forum such as WikiWiki actually ''appreciate'' your attempts to represent them as illogical and inconsistent hand-wavers. * ''I did not claim I had a logically-consistent model of "declarative". If your claim is that we have to accept your convoluted epicycle model because we don't have a simple one yet, then I'll LetTheReaderDecide if they want to accept your contraption. -t'' * Since you're changing subjects from 'relativity land' back to 'declarative', I'll reiterate my explanation from def 3: '''your definition of "declarative" isn't even consistent with how people, in practice, use the word: it fails to account for "declarative layout" and similar uses.''' Now, please explain how proposed definition 1 is a "convoluted epicycle model". * ''How is my def inconsistent with actual usage?'' * Because "it fails to account for 'declarative layout' and similar uses". Was that somehow unclear? * There ''is'', however, a strong relationship between SeparationOfConcerns and declarativeness. In particular, declarativeness '''implies''' a SeparationOfConcerns. Via modus tollens, SOC is a required precondition, albeit an ''insufficient'' condition, for declarativeness. Definition 3 implies separation of concerns of processing-order from the main code, thus leaving it to the implementation and annotated suggestions (for optimization and such). Definition 1 implies, ''more generally,'' a separation of the strategy/plan concerns for ''arbitrary feature F'' from the mainline code. The paragraph layout in the order-by example is 'declarative' because it is stated in terms of requirements rather than ''embedded as a specific plan/strategy'' by a programmer who describes the paragraphs in the source code. That is what "declarative layout" means - specification of layout in terms of declared requirements (aka policy) as opposed a specific layout embedded in other code. And if it is unclear to you that a language with ''declarative layout'' is '''more declarative''' than an otherwise feature-equivalent language without ''declarative layout'', well, I can't help stupid. * ''StepwiseRefinement is a common form of SeparationOfConcerns, but is not ordinarily considered to make procedural processes "more declarative". Thus, SofC by itself does not increase declarativeness. -t'' * It seems you're confused by the formal terminology, but "SOC is an ''insufficient'' condition for declarativeness" '''literally means''' that SeparationOfConcerns does not, by itself, imply declarativeness. I never said that SeparationOfConcerns makes things more declarative. What I said is that declarative requires (among other things) SeparationOfConcerns. Please remember what ''"insufficient condition"'' means so you won't make such elementary mistakes in the future. * ''You are playing games by dancing in fuzzland. If you have an exact formula (ex: "Ingredient_A and (B or C)"), then code the damn thing out.'' * What I wrote was straightforward for anyone with a modicum of technical literacy: "declatativeness '''implies''' a SeparationOfConcerns". A->B, equivalent to ((~A) or B). That's fucking elementary. If you're one of those 'magical' thinkers who doesn't grok that ''implication is unidirectional'', then no wonder you're always flapping your arms and complaining about everything being 'fuzzy'. Just as everything one sees is fuzzy when one has bad eyes, everything one learns is fuzzy when one has bad mental tools for understanding it. The 'fuzz' is in your brain, TopMind. * ''You only '''make up''' specific coded rules when you want to knock down my arguments. Explicitness only flows to heal the wounds of the creature, for it's not otherwise capable of producing a complete model. You hint that SofC is *somehow* related to declarativeness, but fail to offer any '''testable''' specifics.'' * I said, explicitly, that declarativeness '''implies''' a separation. That was explicit from the start. Heck, it was even '''bold''' from the start, to make it that much more explicit. Adding to that the mention of 'modus tollens' - which you could look up easily - and it should have been blazingly obvious that I was explicitly using the logical meaning of 'implies'. I further clarified, above, the separations implied by both def 1 and def 3. I've been reasonable here. But I'm talking to an illiterate, illogical fuck who blames his own intellectual and educational inadequacies upon others. I'm done with this. If it helps, consider that time and space are tightly coupled domains. That HTML implicitly encodes spatial ordering corresponds very closely to imperative implicitly encoding temporal ordering. Ask yourself: how much less 'imperative' would a programming-language be if you had to include the line-number to the left of each logical line, and it simply allowed you to put the lines in the source-code in any order? ;;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.''