Viewing Algorithms As Collection Processing

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.

CategoryProgramming