In a very long page, SeparationAndGroupingAreArchaicConceptsDiscussion, an attempt is made as to spell out the Archaic nature of Separation and Grouping. I inspected the page and found the following words used, and I believe all of which can be said to contribute to separation and grouping: names variables hidden visible static dynamic namespaces scopes files sections paragraphs sentences words segments parts contraptions schemes methods threads local global searching sorting grouping summing reporting inspecting interpreting processing measures techniques priorities call-stacks databases sets tags If something is useful, usable and used, as all of the above are, I fail to see in what way the concepts behind them (that of Separation and Grouping) are anything else but fundamental and irreplaceable. If a concept is archaic, at least as I understand the meaning of the word archaic, it is in the process of deprecation and replacement. It seems to me a vital thing to be able to separate (as in wheat from chaff) and to group as to (put apples in a basket). How this is done may change, and the schemes, mechanisms and processes involved may be modernized to take advantage of new hardware and software, but the concepts in themselves are fundamental. --BlueHat ''I suspect what we have here is a vocabulary dispute, not so much a technical dispute. The concept I called "archaic" was "single dimensional" partitioning, which is the norm in the industry right now (but seems to be hitting walls). Multi-dimensional separation is usually NOT called "separation" in my experience, or at least is often not sufficient. But I will agree that perhaps English is not sufficient to describe modern cyberspace, so our 3D-world vocab is tripping us up.'' I have been working on the concept "that perhaps English is not sufficient to describe modern cyberspace" in my quest to establish a scheme for separation and grouping based on what I once called H''''''yperArtifacts. I am only beginning to get a handle on how this might be done, but fundamental to it is the use of single and multi-word combinations as atomic elements in a Hypertextual language. It will handle objects, processes, states and persistance and as many other things as might be required. --DonaldNoyes ''Perhaps a different title should have been used, but until somebody finds a significantly better replacement, wiki tradition is that "good enough" titles stand if they have been there a while. It's not practical to keep flipping titles for incremental improvements. Further, titles should NOT be required to carry all potential scope limiters and disclaimers in my opinion. Other's have disagreed, although their arguments are weak and border on being childish in my opinion. That being said, you are welcome to propose new titles. Hopefully, we can reach a consensus before any change is made.'' [You choose a big title and attack such a small aspect of it. You sow much confusion by doing so, and you create confrontations regarding the title that are not beneficial towards your purpose. Even responding to pages such as this one consumes your time, your energy, to no purpose other than once again explaining that your title is bigger than your claims. It would be wise to narrow the scope of the title to reflect the narrow scope of your claims (if you need help, terminology that describes what you so despise includes "DominantConcern" and "Tyranny of the Dominant Concern"). Since you don't like flipping titles, you would have been wise to apply greater thought when choosing the initial title. As far as "Multi-dimensional separation" being not called separation, you'll be disappointed to know that MDSOC (multi-dimensional SeparationOfConcerns) is a well known term among those who follow progress in ProgrammingLanguageTheory and have read about HyperSpace''''''s.] * Some are okay with the "organic" nature of this wiki, while others are rather meticulous about titles. These two styles seem to be conflicting. Ward's original vision leaned toward the organic side. I agree with Ward more or less, but I promise I'll try to be more careful about titles in the future to avoid conflicts with the meticulous side. -top * [If successful, your efforts will be unnoticed... but only because absence of conflict isn't very noisy. I appreciate your promise.] * I do believe those who I've angered by "attacking their holy cow" are biased against me in a vengeful kind of way such that they will scrutinize what I do more heavily. -t * ''I don't believe I've seen you successfully attack any "holy cows" here. If you are scrutinized heavily, it is for (among other things) making bold assertions without sound defence -- especially those that demonstrate a clear lack of understanding of ComputerScience and SoftwareEngineering.'' * People with vague or missing evidence often accuse the other of ignorance. It's their only escape. In other words, inarticulate cowards. People who truly know how to ''apply'' their superior knowledge to make things objectively better are not afraid of SelfStandingEvidence. They know where it makes things better, they know why it makes things better, and they know how to objectively measure it and show the measurements to disagreeing parties. If you rely on ''substitutes'' for science such as ArgumentByElegance, then you cannot perform such steps and have to imply "trust me, I'm just smarter". -t * ''The majority of us happily discuss technology and theory but almost never promote it or engage in advocacy, or only do so in terms of addressing specific programming problems. You are notable in '''generally''' promoting quite specific approaches -- TableOrientedProgramming or HtmlStack replacements, for example -- or engaging in advocacy against use of higher-order programming techniques like HOFs. Are you aware that this is classic ArgumentByElegance, where "elegance" is your particular brand of table-oriented procedural programming? I've never seen you offer any research citations or empirical evidence to support your approaches, or to provide evidence against those you deprecate. As such, the only regular participant here who seems to imply "trust me, I'm just smarter" is... You.'' * Unfortunately, SoftwareEngineering depends largely on WetWare, and so most of my arguments are based on WetWare assumptions which I do try to state even if I cannot prove them in an absolute sense because the human mind is not yet subject to the kind of science we really need. In other words, I do my best to describe the WetWare models I use for my reasoning even though not every assumption or observation has been "certified". Your problem is that you refuse to see that ProgrammingIsInTheMind, and instead invent fake or fuzzy metrics to make your case. There is no SoftwareScience so far. The field is fucked up. I'm just the messenger. Science served us well on the ''hardware'' side, but left town when software rolled in. * ''Could you show me where I "invent fake or fuzzy metrics to make [my] case?"'' * ''If it's true that there is no science in SoftwareEngineering, then could you stop promoting your table-oriented procedural hobby horses and stop deprecating programming techniques such as higher-order functions? If "software [is] mostly about the human mind", then obviously no rational argument can be sustained in favour of table-oriented procedural programming or HtmlStack revisionism, or against higher-order functions.'' * The default is not that they are "good". Every tool and technique should be scrutinized and not accepted by default. If only OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy''''''s are allowed on this wiki, then we'd have to delete like 95% of the software stuff other than specific product info. * ''Your arguments appear to suggest that the default for table-oriented procedural programming is that it is "good", and that the HtmlStack and higher-order functions are not "good".'' * I advocate for my fav tools and you do the same. Nothing wrong with that. As far as the HOF debate, that's more about what the "industry" wants than it is about my favorite techniques. Like I've said before, even some of my own fav techniques are frowned upon in a typical workplace such that I have to cut down on them. Those topics are more about the sociology of the workplace. * ''Could you show me where I "advocate for my fav tools"? I don't recall ever even mentioning my "fav tools".'' * I meant "tools or techniques". You do appear to promote certain techniques, but I don't want to get into a LaynesLaw debate over "advocate". * ''What techniques do I promote?'' * Gratuitous use of HOF's. * ''Could you point to a use of HOFs that is gratuitous, and provide evidence that it is gratuitous (as opposed to being a reasonable and effective solution) by demonstrating a superior alternative?'' * Gee, a brilliant idea for a brand new debate! Why didn't we think of that debate before? ''And I do indeed agree that *some* kind of "partitioning" is needed, and thus "some kind" of partitioning is "fundamental". It is absolute or single-dimensioned partition that is "archaic". The main point of the original topic was that '''we need relative partitioning and the current tools do not provide it''' well. If there's a better way to say it, that's good. {I added the blue-hat moniker. I hope you don't mind. Lack of handles can cause difficulties.} --top'' '''Reference Pointers Versus Block Markers''' Strangely enough I am wearing a navy-blue hat right now from Juneau Alaska. I don't mind at all. I have long been an advocate for PositiveDialogue. It is far more productive and satisfying than confrontation and dispute. About partioning and dimensioning - What I see as needed is something that points rather than something that counts, and inserts in slots, positions or spaces. A sort of connection of concerns that is associative, so to speak. Thus when connecting something as complicated as a sentence or paragraph (made up of words and complex-words, the pointer(s) may be multiple from the same or several points in the sentence or paragraph. Not the simple single, dual or triple type found in linked lists and the like. --DonaldNoyes [Not archaic yet, at least not as most English speakers understand the term. Wait until WarAgainstDominantConcern is finished before you declare victory.] {misplaced/drifted context?} That is an interesting open question: references versus "tagged chunks". It almost reminds me of closures-versus-start-stops in other debates. Or how to represent text formatting (nesting versus starters/stoppers). Chunks just seems cleaner for this use, partly because the scope of the category markers is cleaner and partly because functions, modules, and blocks already exist as possible pre-made frames of reference. If we have scope starters and enders, they may drift apart or get deleted out of sync. But it's likely a case of WaterbedTheory at play. Perhaps a tool could support both, at the price of added complexity. --top -------- Open Questions: * Are references used, or "labeled blocks"? LabeledBlocks would simply attach markers to existing blocks, such as functions or curly-brace blocks. ** If references are used, should they require a "closing" marker? (Or, perhaps required if indicated.) * Are the actual categories to be stored in the source code, or in a separate structure/database that links via a marker-ID? Similar questions apply to meta-data. A minimal-code approach would simply have an ID number, and then rest of the info kept in separate a database or system. * Would markers be hand-keyed or machine-generated? * Would the "live" code be stored in a database or files? (Files eventually have to be generated as existing most existing compilers/interpreters only support files. But, that is only during the "build" stage.) ---- AprilThirteen