I used to use SyntaxFollowsSemantics for this concept, but realized that it is beyond just programming syntax. It comes up in user interface issues also (such as WimpIsBroken), for example. Thus, I am creating a wider topic. I don't yet have a good written description of the concept. Volunteers? --top Related topics: * SyntaxFollowsSemantics * AdvantagesOfExposingRunTimeEngine * CodeAvoidance * HiddenDatabaseSyndrome * InterfaceFactoring * SeparationAndGroupingAreArchaicConcepts * SeparateDomainFromPresentation * ModelViewController? * SeparationOfConcerns Maybe it is not so much about "separating", since physical location has little or no meaning in the virtual world, but more about accessing the "atoms" of information without parsing or hacking. I strongly suggest to click on the LikePages button and have a look at the left column. In OoBestFeaturePoll, Top suggests SeparateMeaningFromPresentation is a not yet existent ideal when he says "separation is a bit idealistic". There are many DomainSpecificLanguage''''''s out there, surely there is one which demonstrates SeparateMeaningFromPresentation. -- PeterLynch Perhaps you mean SeparateDomainFromPresentation? -------- Top uses 'SeparateMeaningFromPresentation' in a manner inconsistent with its normal usage. SeparateMeaningFromPresentation is violated when presentation features (such as bold, font, font size) are combined in representation with semantic features (e.g. structure: paragaphs, tables, chapters, titles). A DomainSpecificLanguage that demonstrates better SeparateMeaningFromPresentation includes the use of CascadingStyleSheets to attach presentation features to XML or HyperTextMarkupLanguage. Top uses 'SeparateMeaningFromPresentation' with intention that might better be described by 'SeparateDataFromRepresentation'. This concept is violated by languages such as C++ that encapsulate attributes inside objects in a manner that automatically implies conditions on the physical representation of that data. It can be repaired by allowing access to and storage of attributes of an object to be specified independently of the procedures that describe that object's behavior. Doing so would allow objects to essentially be 'views' (potentially updateable views) of a database, whilst still allowing local data storage where it is appropriate for optimizations (e.g. caches). This sort of separation has been used to good effect for such things as arbitrary mixin support and concept-oriented programming. A few OO languages, including Ruby and Smalltalk, seem to support SeparateDataFromRepresentation by treating attributes as a pair of getter/setter procedures that may be overridden at any time. One thing to note about SeparateDataFromRepresentation is that it forbids 'pointers' as they are usually utilized, because you cannot 'point to the representation' of any particular data item. Everything (including pointers and references) must be stored as values (which must be first class), and if one needs a 'pointer' the one gets what is essentially a FirstClass 'getter' (for dereference), a FirstClass 'setter' (for assignment), or a pair of the two. While parsing or serialization or database queries or whatnot might be part of executing these mechanisms, those tasks become encapsulated within the 'view' mechanism (getter/setter) functions. A 'pointer to another object' really is a getter procedure that returns another view of data with its own getters and setters and associated procedures. Personally, I am in agreement with both SeparateMeaningFromPresentation (its normal use) and SeparateDataFromRepresentation, and fully believe that languages should automatically support them. But I feel TopMind often overstates the benefits of following SeparateDataFromRepresentation more extremely... he seems to believe one could get a major benefit out of putting ''everything'' into a database, and on such pages as 'AdvantagesOfExposingRunTimeEngine' he points out the benefits for debugging, but he completely ignores issues of security, of modularity, of CouplingAndCohesion, and even of SeparateMechanismFromPolicy (which is his goal in the first place!). You can't really specify ''which'' database the object accesses to get/set attribute data if you are to SeparateDataFromRepresentation: a single runtime could have objects with components stored in over a dozen distributed databases. ----------- You'd need to be more specific about the alleged downsides of TableOrientedProgramming with regard to security, modularity, etc. * AdvantagesOfExposingRunTimeEngine is not at all the same as TableOrientedProgramming (which ''was not'' mentioned above). When exposing the runtime engine, modularity gets violated whenever any programmer writes a module that peeks at the runtime engine and 'expects' certain features to be there that were really just 'implementation details' of another module (and thus creates a dependency on implementation details). And security is violated if details are exposed (even to the debugger) for which a user of the module/debugger was not authorized. * ''So knowledge is dangerous? This discussion is not really about AdvantagesOfExposingRunTimeEngine anyhow.'' * This discussion was ''never'' about TableOrientedProgramming, yet it was brought it up as though I had listed some "alleged downsides" of it. AdvantagesOfExposingRunTimeEngine was at least brought up to help explain what TopMind means by "SeparateMeaningFromPresentation." And while knowledge can be dangerous if used, that conclusion cannot be reached by logical means using the statements in the above paragraph. Note the I find some forms of "modularity" to be hard-chunking of concepts that should be relative. In other words, '''view-based modularity''' instead of a hard separation is a better goal. * "Modularity" requires that one can tear out a chunk of code (a module) and inject a new one (a different module). Modularity is intended to achieve both separation of policy and mechanism and a means to divide code ownership and construction issues. Thus it will necessarily be based on sharing a common interface and providing independence from implementation details (usually by hiding them). How does "view-based modularity" achieve this? ** I suppose we need to clear up or fix our working definition of "modularity". Modularity is more than just component swappability in my book. For example, is also relates to a "work unit" for the purpose of MentalIndexability regardless of swappability. *** Modules are often used as "work units", but they still need to be swappable. In particular, they need to be "modular" work units such that one can implement the details of that work unit without leaking the implementation details into other modules. TopMind has this "book" full of HumptyDumpty definitions; I no longer need to wonder why he can't communicate with anyone. *** ''There is no formal tech definition body that defines things such as "module". It has always been a fuzzy concept. If I make a working definition, it is no more Humptying than your alternative definition. You can't just elect yourself Definition God on a whim. Thus, you are chomping on my ass without reason. --top'' *** There is no formal and universally accepted definition of 'module'. But everything you just said is untrue, including your first sentence (because there ARE formal definitions of "module" - as you'll find in ML and Mozart and other languages - just not universally applicable ones). If you don't make a serious effort to remain consistent with the usage of the word "module" as it has been used in the past, then you very much are playing "HumptyDumpty" more than me. And it also doesn't speak well for you that you'd prefer to immediately start LaynesLaw arguments about what "modularity" means "in your book" than attempting to communicate or understand what other people are saying. *** ''It is hard to remain consistent with past usage when there is no consistent past usage. I honestly have not seen any. Swappability certainly isn't a major theme I've seen. And, I've seen others have arguments over its meaning even without me intervening. -top'' *** There is consistent past usage. But I believe you when you say: "I honestly have not seen any." Because you're an idiot who thumbs his nose at established academia and who writes down deviant definitions "in his book" without ever looking for such commonalities. *** ''So academic land is a more "valid" source of definitions than practitioner-land? By what scripture to you obtain this rule? Anyhow, if you spent this time defining CLEAR working definitions instead of insulting me, it wouldn't be an issue, and more civilized. --top'' *** If you didn't start by diving into a LaynesLaw argument about what "modularity" means "in your book", this wouldn't have been an issue. *** If modularity is composed of different features/attributes, such as swapability, grouping for MentalIndexability, division of labor, etc., then it may make modularity-related discussions clear, or at least more specific. If we can atomize concepts, let's do it. In fact I'll start one: WhatIsModularity.--top ** I also tend to believe that a hard separation of "implementation details" from interface is often problematic and will result in a LaynesLaw mess. In other words, implementation-versus-interface is also subject to EverythingIsRelative. This is because our software models are merely models, and which part of the model are more "modely" than the other can be difficult to objectively measure. For example, see FuzzyDistinctionBetweenInterfaceAndImplementation. (Yes, Toppie did indeed play the 'ol relativity card yet again.) --top *** The EverythingIsRelative card, which requires one have inconsistent logic with only one truth value, only loses you points "in my book". And "modules" are fairly easy to measure regardless of all this other mumbo-jumbo your argument is resting upon. Interface vs. implementation is fairly easy: a module receives inputs and produces outputs via its "interfaces" (interfaces are points of communication) and has ''control'' over the mechanism to produce outputs after receiving inputs (implementation implies control). A module cannot control how outputs will be used or which inputs it is going to receive. --AnonymousDonor *** Everything has inputs and outputs. It's just that some are harder to detect or keep track of than others. And please, don't take us back into the "for the purpose of" hand-waving clause. --top *** Then don't lay down that 'EverythingIsRelative' hand-waving clause. And since you're again making ridiculous claims: what inputs and outputs does an HTML document (one already saved to file or serialized to wire) have? *** You are the hand-waver, not me, because you pretend rigor exists where it doesn't. Anyhow, the "output" of HTML is usually the screen image. --top **** I've never seen HTML "output" a screen image. Don't get me wrong: I've seen a '''web browser''' process HTML to produce a screen image. But I've never seen HTML do such a thing. You need to learn to make some distinctions. **** And C cannot produce output either without the assistance of compilers and chips. Your "stand-alone" criteria is unrealistic. -top **** Unrealistic? Not at all. That is why I don't say that "C" produces output, but rather that "a function" or "a procedure" or "a compiler/interpreter" does something, and why I refer to "type descriptors" as distinct from "types", and "procedures" as distinct from "procedure descriptions". CeeLanguage has procedure descriptions and they only become "procedures" when properly interpreted. I make distinctions. Your unwillingness to do so leaves you mentally crippled. **** Distinction between vague and fuzzy? You are talking riddled nonsense and trying to deflect your problem back to me. Come back when you WANT to be clear and WANT to clean your verbal diarrhea. If all you want to do is insult, then I want no part of your grumpy ass. --top **** Distinctions between map and territory, between representation and the real thing, between the message and the interpretation, between HTML and its application. You admit to an appalling lack of education and unwillingness to self-educate. You shouldn't blame that on others. And since you seem to be in the mood to give "come back when" orders you can't enforce, I'll return one of my own: go throw your tantrum somewhere else. **** Your education claim is likely a bluff for one too lazy to present a solid textual argument. And, there is no "real territory" in software. It's all a fake model. --top **** And this coming from someone who claims HTML displays itself to a screen without any external motivating force. Sigh. Believe what you want - useless, pitiable, and illogical as it may be. **** Not any more or less than a C "print()" statement needs assistance. This could have been an interesting philosophical discussion. Instead, you turned it into a bash-the-practitioner-and-hug-ivory-towers session. -t **** This could have been an interesting philosophical discussion. Then TopMind decided to toss logic and reason (and distinctions) out the window and call himself a "practitioner" as though nobody else can claim the title. **** Logic, my ass. If you had real logic, you'd present it in a geometry-proof-like style with givens etc. and it would be clear to all that Toppie is wrong. You can't because you are an empty biased windbag. --top **** I can't make it clear to all that Toppie is wrong because 'Toppie' is in the set described as 'all' and he does not pay attention to logic. And he'd rather wave his hands and enter LaynesLaw rabbit holes than ever return to the original arguments. You said: '''everything''' has inputs and outputs. As stated, that includes things that are not processes, such as static files, views, comments, types, and half-formed ideas. I mentioned, specifically, static HTML files and asked what the output is. You gave an answer that is obviously wrong to everyone... everyone but the irrational ignoramus that gave the answer. **** "obviously wrong to everybody" is ArgumentFromAuthority. That is not good enough around here, even if true (you presented no decent surveys). If there is a "hard" distinction between HTML and a print statement that fits into a nice rule(s), lets see them. I doubt there is a hard distinction (unless you arbitrarily make one up). Clarify your thoughts instead of using feelings and notions. --top **** Neither HTML in a static file nor a print statement sitting in a static C file produces an output. That you even brought it up as an attempted counter-argument just proved the point: you utterly fail to make relevant distinctions, and you aren't interested in learning any different. Tell me the next time a print() statement that is sitting in a static C file has an output. **** ''Please clarify. Why am I obligated to make distinctions? Does somebody else want to give it a whirl? I don't know what he/she/it is talking about.'' **** "Why should I make relevant distinctions?" Maybe because they are relevant. "Why are they relevant?" Distinctions are relevant because properties of distinguished things often follow predictable, but distinct, patterns. "Why does that matter?" Because identifying these patterns and applying them towards prediction is the very basis for reason, logic, models, and even communication itself. "But why am '''I''' obligated to make distinctions?" Because, on any intellectual forum, including WikiWiki, you are obligated to apply that brain of yours towards logic and reason '''before''' you speak. If you refuse to make distinctions, you also give up your right to speak on this forum. See also: SeldomAffirmNeverDenyAlwaysDistinguish. **** You are meandering. I cannot identify any "key" differences between an HTML "HR" tag and a C "print()" statement with text or printer codes. I can identify tendencies, but those are not good enough. If your argument depends on a definite distinction, then YOU are obligated to establish that distinction. Why is that so hard? I'm NOT claiming they are the same. I am only pointing out nobody has proven a hard difference exists. Thus SeldomAffirmNeverDenyAlwaysDistinguish does not apply to me. I'm just saying, "Hey, there's no real evidence Santa exists". That is NOT the same as claiming Santa doesn't exist. --top **** There are useful and powerful distinctions between static files, the interpreter for those files, and the interpretation of those files. I've made these distinctions and doing so isn't hard at all. Communicating them to you, who refuses to be educated, who refuses to self-educate, and who refuses to make distinctions because they undermine his whole fallacious way of thinking, is what one might describe as "so hard". And your "everything has inputs and outputs" argument is NOT analogous to "Hey, there's no real evidence that Santa exists." No, it's much more analogous to "Everything is Santa!". Your argument doesn't make much sense until you close your eyes, wave your hands, say "EverythingIsRelative" in a repeated and slow mantra, and start refusing to make distinctions. (And an HTML document is not any more or less Santa than a 'print()' statement in C. Can you deny this?) **** Your reply is incoherent. * Is it possible you are thinking of something other than "modularity"? I did mention views above (''"Doing so would allow objects to essentially be 'views' (potentially updateable views) of a database [...]"''). ** How about a code-based demonstration. *** How does one give a code-based demonstration of: "I did mention views above" or "Is it possible you are thinking of something other than 'modularity'?" *** ''Of objects being views of a database.'' *** I'll consider doing so if someone towards whom I have at least one ounce of good will is interested. *** ''I expect you to consider me sinister and/or stupid forever and ever, thus it doesn't look like we'll ever get an example. '' *** Someone else could always ask. Or you could earn an ounce of good will - you manage it on occasion. *** '''Probably some bastard who shares your convoluted pet tech.'' *** Actually, everyone starts with good will from me. But you've abused yours with your snide comments, trolling, childish tantrums, arrogant "in my book" injections, and repeated fallacy on an intellectual forum that implicitly demands careful thinking and professional decorum. *** ''You are projecting. I don't insult first and I KeepCriticismNarrow (at least before all hell breaks loose). I am a good boy overall. --top'' *** You tell untruths to yourself and everyone else about what you do. You might think you are a good boy, but that's because you are quite biased. You may think you don't insult first, but that's because you have an immature concept of 'insult' and fail to recognize how insulting and rude you actually are. *** ''Some/one of you are overly sensitive to behaviors that wouldn't upset normal humans; an unpredictable, and frankly weird, moral system.'' *** And you may think you KeepCriticismNarrow, but I've '''never''' seen it from you: your usual 'criticism' amounts to "Naive, my ass" or "Logic, my ass", something along those lines. Not that anyone can change your hyper-inflated opinion of yourself, what with your 'everyone's against me, I'm just like Galileo' complex. Ignorance truly is bliss for you, isn't it? *** ''I only use those names only if somebody else shoots first. If they insult me, I have a right to insult back. Do I need to hilite the insults in the future so that its clear that I didn't shoot first???? The Galileo thing was just having some fun. Stop blowing it out of proportion. You can be Napoleon for a day if you want, okay? --top'' *** I saw you use "Naive, my ass" as a response to the first line of a topic just the other day, and '''nobody was insulting you'''. If you weren't such an ignoramus who actually believes the untruths he says, I'd really think you a liar right now. *** Somebody has been using "fear" repeatedly as a reason why others don't accept their pet techniques. Plus, "naive". I find that insultive and that's what I was retaliating for. Doing X out of "fear" implies irrational motivations. Granted, I may have over-reacted, launching a 50 megaton insult to counter a 10 megaton insult, but technically it's still a response to an insult. I will admit I overreacted, but I didn't violate my rule. --top *** So you admit, clearly, in the above paragraph, that people violating your sense of what constitutes good argument ethics is (by your almost-a-word) '''"insultive"''' (insulting). And you call people who feel the same way (in your words): ''"overly sensitive to behaviors that wouldn't upset normal humans; an unpredictable, and frankly weird, moral system"''. Well, how's that for frakkin' hypocrisy? *** ''EverythingIsRelative, including morals. But I believe my rules to be more mainstream. I try to adopt WhenInRome. Further, I will admit if I overreact. You instead try to justify your error through convoluted logic.'' *** I don't attempt to justify my insults, but I won't apologize for them... because I don't think I'm overreacting. Overreacting would be to hunt you down and slash your tires. Reacting properly for much of your behavior would be a HardBan. One can use a separate table(s) or attribute to provide a virtual grouping without changing the original info; and have multiple orthogonal groupings that don't conflict with each other. Attribute-handling math is generally easier than behavioral math. --top ---- I wish I had not asked -- PeterLynch In response to the bar conversation above, I can resolve your differences. I sentence you to collaboration in development for more than six months. Eventually you will see the basics upon which you agree. All peer reviews will be filmed to provide enlightenment and entertainment to many of us. (Not to exclude those of us who need no enlightenment) ''Make sure you take out good insurance on such an office building.'' ---- OctoberZeroEight CategoryInfoPackaging