Stalled

FAFO on GitHub

I’m not out of ideas, but I am out of directions, and my momentum is low. What shall I do?

Hello, friends,

There are certainly things that we could do with this set theory thing going forward:

An Application

We could gin up a language for solving relational or other database problems, and implement it with set theory. My take on that would that there is no real need for such a thing, and it would be tedious to do, without much of the kind of programming that I enjoy.

Performance

We could measure the performance of this thing and then devise clever set-theoretic ways to make it faster. One real possibility, for example, would be to focus it primarily on “relational”, and then implement some really fast byte-thrashing algorithms to speed up large-scale operations. The main issue with that is that with 16GM or memory on my laptop, and a processor that seems to spit out instructions every few nanoseconds, there isn’t a performance issue anywhere in sight.

Hierarchy and Grouping

We have a bit of grouping going on with our group_by and statistics methods. We could explore some serious grouping issues, such as arbitrary company org charts or (may the gods preserve us) parts explosion. That might exercise our non-relational capabilities, some nested sets and the like. I’m not moved at all to do parts explosion and only mildly interested in corporate org charts.

Music Library

I only know enough about this to be dangerous, but we can imagine some audiophile or tune fanatic keeping track of all the information they have about music. It would get hairy. All your thousands of recordings with all the connected information, composer, artist (don’t forget all the musicians on the recording), label, pressing number, date of release, country, hidden tracks, producer, conductor, … and then you get into the weird stuff that your Sirius XM DJ tells you about how this song is really based on a tune that originally came from Ireland but was taken up in the South and became a freedom anthem that was first recorded by The Tin Can Boys on a bootleg recording that was made in a boxcar, one of the first three recordings ever made using soup cans and string. You may not know that Davey Temple of the Tin Can Boys went on to become known as Davey the T, who made a good living as a session musician in New Orleans until he was shot in the bedroom of a competing horn player, Arnold “Horn Wizard” Matthews, while he was trying to poison Matthews’ pet alligator, hoping that Matthews would withdraw from the competition for Second Horn in the up and coming band, Clara Damara and her Five Horny Men.

Any music database worth the name would provide for that sort of thing. Now that I’ve described the surface of the problem, I have lost almost all interest in this one.

Random Requirement

I have often challenged myself, in other series, with a random requirement suddenly imposed on the “team”, requiring a substantial and presumably difficult change, so that we have to see whether our incremental approach to design has left us somehow cornered and unable to meet this next surprise requirement. So far, I’ve generally been able to deal with those things.

The biggest twist I’ve thought of for the set theory thing, so far, would be something that requires us not to move so quickly to the frozen set form of our implementation, instead keeping data in an alternative form longer, resorting to the general case only when we absolutely have to. This might be the sort of thing we’d do if we were given a requirement to deal with huge flat files, so large that most operations cannot possibly be done in memory.

That would almost interest me.

Another random thing would be to relax the restriction that there are no duplicate items in sets. This is enforced, currently, because the frozen set works that way, and we move to frozen sets essentially immediately.

Since, mathematically, { a, a } == { a }, we could implement set operations that allowed the accumulation of duplicates and then provide some way of stripping them out. I do not know a set-theoretical way of expressing that. Maybe we define an “enumeration” that takes a set and provides a vector whose elements are the elements of the set and such that

if x ∈_i V and x ∈_j V, then i == j.

We could even define a sort if we required i < j to imply that the corresponding elements are also less than (or equal). Something like that.

But why might we do that? Well, because it would allow certain set operations to operate at higher speed, because they wouldn’t have to check for duplicates. Would there be a big advantage to that? Honestly, I’m not sure. If we were writing a few powerful streaming operations to be used on high volumes of data, maybe. But I doubt it.

Parallel Processing

For a sufficiently large operation, it might be fun to run it on multiple processors. This one might make the cut, it would almost seem useful. I think we might have to do some of the other items above to make it make sense, so that we could partition an operation across processors.

Nearly interesting … hmm …

Other Languages

I like Python, even more than I expected to. It fits nicely into my mind. I don’t feel the urge to try something new or to retry something old.

Other Topics

I’m far enough away from working with teams, or consulting for companies, that my thoughts are probably out of date. I do have occasional thoughts that I think are of value and of course I blurt them out.

I occasionally write on political or social topics, and there, too, my thoughts are just occasional.

Conclusion

I have none. There are a few things remaining in the XST thing. Let’s just keep pushing on those and see what happens. Maybe something will come up.