I often view algorithms in terms of processing collections (CollectionOrientedProgramming or COP), and TableOrientedProgramming in particular. If the data structures are organized "right", then roughly 50% to 80% of typical processing can be practically viewed as COP. It could even be 100% if you stretch things, but every technique has areas where it doesn't shine so well, and current tools don't support COP to its fullest. COP tends to be more compact and a higher abstraction than "one-node-at-a-time" algorithms found in traditional programming and OOP. Higher abstraction includes meta-techniques that otherwise requires awkward language features like reflection to replicate. This is to document some examples to give ideas of how COP can play a roll. I will tend toward tables as my example collections. -- TopMind ------ '''Example 1: Field selection''' In CRUD apps, often different reports, screens, and forms will use a different subset of entity columns (fields). Rather than mention the column list over and over with different subsets of columns excluded, it can be useful to use something like a DataDictionary, and filter by some criteria to get the subset of columns we want. It is usually easier to change the assignments in such a table than dig around through linear and verbose code and hand edit column lists or bunches of similar-looking function/method calls. ------- '''Example 2: GooglifyDeepMenus''' If we have a data structure holding attributes about most of our app options, then it gives us and/or users more tools to sift, manage, and search through bunches of options. Off-the-shelf CRUD techniques can be used as at least an optional interface to search and study the options. ------ '''Example 3: Dynamic Code Grouping''' With flexible collections, what appears "together" is merely a choice of dynamic presentation. One stops viewing code as linear or tree-shaped files and instead views them as blocks which can be presented as dynamic groups of multiple factors, such as database-related code, security-related code, GUI-related code, etc. '''without having to hard-wire''' our original module or routine grouping to fit any one of these. "Together" becomes a virtual, dynamic, and relativistic concept. See SeparationAndGroupingAreArchaicConceptsDiscussion for more. (Note that this is more of a technique than an "algorithm". Perhaps the topic title should be widened, but it's not different enough to justify.....just yet.) ------ ''More to come...'' ------ ------ At least one person thinks this page should be deleted. Could we have some points on why to delete or not to delete? Proposed Name Change: * ViewingDataProcessingAsCollectionProcessing * ''I'm generally of the philosophy to error on the side of wider topic titles until the point that identifiable confusion or overlap happens. Further, example 3 is not data-processing-specific. Aspects can be found in any domain.'' To Delete: * This is just TopMind's opinion. He can put it on his home page, if he wants. * ''The page title implies a reasonable notion -- that we can describe algorithms in terms of explicit set operations. Of course, this is what we do with, e.g., Z notation. However, except for the unsubstantiated claims in the introduction, the page content references neither algorithms nor collection processing. I would expect to find examples of common algorithms -- e.g., BTree item deletion, Kruskal's Algorithm, matrix multiplication, Fourier transformation, red-black tree insertion, and the like -- described in terms of collection processing. Instead, I merely find some rough summaries of user-interface design strategies. As such, either this should be moved to TopMind's home page, retitled, or rewritten.'' ** I think I see what you mean, in terms of classical algorithms. Some, like red-black tree insertion would not make sense as collection processing; you just wouldn't do it that way; you'd address the business needs at a higher level, using different algorithms. ** Perhaps a different page name, like DataProcessingAsCollectionProcessing would make more sense? (Not implying that classical CPSCI algorithms can or should all be done as collections -- just most business needs being doable with collection processing.) ** ''I have not spent enough time with problem-types of the examples given (BTree changes, matrix multiplication, etc.) to readily supply a collection-processing version of them. I invite others to give it a try. Personally, an algorithm calculating bowling scores would tickle my utility gland more than BTree processing. -t'' To Keep: * It could be valid and helpful to view algorithms as collection processing. TopMind might not be the only person who thinks this. * ''At the very least, it could serve as MentalMasturbation to stretch one's collection-orientation muscles.'' * There is no question that this page is on-topic. If you're going to delete opinion pages by top, start with ObjectivityIsAnIllusion. ------ See Also: PayrollExample, ConvertingImperativeToDeclarative, CollectionOrientedProgramming, LogicProgramming, KayLanguage ---- CategoryProgramming