Yin Yang Versus Singlism

Many strive for a "universal root" (BigIdea) in their pet ideal environment (see EverythingIsa). However, I sometimes speculate that a yin-yang type of relationship between two somewhat orthogonal ideas may be more powerful. It may be more difficult to convert from one to the other when such is needed (DiscontinuitySpike), but the flip side is a bit of specialization whereby each "sex" contributes better to certain kinds of tasks than others, and thus cover a wider ground more smoothly than one could get by force-fitting a single idea into all needs.

This issue came to me when discussing EverythingIsa table (singlism) versus FormulasPlusAttributes (yin-yang). Somebody asked why a single language based on relational has not been created the same way Smalltalk has done with "everything is objects". This begs the question: "why?" (I haven't ruled out the everything-is-a-table viewpoint yet, but am simply trying to scrutinize singlism well for now.)

Are there useful yin-yang paradigms or technologies that you can think of? Besides gender?

-- top

Somebody asked why a single language based on relational has not been created the same way Smalltalk has done with "everything is objects".

It depends what you mean by "based on relational". One could argue that SqlLanguage and TutorialDee are both based on the RelationalModel, or at least incorporate it at a fundamental level. In both cases, tables (or relation-valued variables, aka relvars, in TutorialDee) serve (roughly) the same purpose as container classes and/or collections in, say, Java or Smalltalk.

However, if you're suggesting that the relational model be a fundamental organizing principle, on the same order as Smalltalk's objects or functional programming's lambdas, then I'm not clear what such a language would look like. TheThirdManifesto probably goes further than any other work in driving the relational model down to a fundamental level, but a relation is, by definition, a structured aggregation of more primitive elements - values, types and labels. This implies the need for some lower-order organizing principle than relations. I have seen some experimental efforts that define virtual machine architectures around table structures, but I'm not sure these will ever be anything but curiosities.

RunTimeEngineSchema is perhaps just such a toy.

That said, the simplicity and universality of relations and the composability of the relational algebra make the RelationalModel very potent; it makes an ideal yin for a variety of yangs.

-- DaveVoorhis

Yin and Yang is more a duality than an orthogonality, but dualities also compose well. In the sense that distinct orthogonal features appeal to me, I also have a preference for 'YinYangVersusSinglism' - EverythingIsa is not very interesting and forces your hand to a particular approach whether or not it is ideal for the problems being solved.

Some orthogonalities and dualities I use:

ThereAreExactlyThreeParadigms plus a missing one - a language that supports all three (or four) of them in pure form is YinYangVersusSinglism, whereas one that sort of mixes them all together (allowing functions with side-effects) almost immediately loses all the benefits that come from keeping them distinct (optimizations, safety, ability to predict what the program is doing, etc.)
Data management and DataManipulation: There are two basic types of DataManipulation (open and closed) and two basic types of data (projective and reflective), as discussed in ObjectVsModel. A language that supports all four quadrants will allow both the benefits that come from keeping internal models (object-oriented style, encapsulation, behavior-oriented - projective data) and for keeping external facts (relational style, sensor-oriented, reflective data) and thus avoid the ObjectVsModel issues and in addition support transparent persistence, distribution, caching, compression, indexing, and such (closed data manipulations) independently of the operations for modifying, adding, and deleting data (open data manipulations). Supporting these means the programmers don't need to do it by hand.
CompileTimeResolution + FirstClassFunctions?, FirstClassTypes, etc. - these are orthogonal and combine extremely well since together they obviate any need for code generation while allowing for very high levels of optimization.
'Define' vs. 'Construct' - 'define' is a way of setting a value in one location and communicating it to the rest of your code. 'Construct' is the formation dual, taking bits and pieces of a definition from all over the place and glomming them into one value that can be used. Support for 'construct' values makes LogicProgramming much easier even in languages that don't normally support it since it allows centralization of data. It also helps with unit testing and such.
'Require' vs. 'Export' - modular programming communications duals. A module can require a component or export one. Another module can import an exported component or provide a required one. Providing both directions makes it much easier to handle 'default behavior' with 'overrides'. This makes modules easier to use, and a bit more abstract.