Grand Paradigm Unification

Just like physicists seeking out a "grand unification theory" of physics, we software weenies often think about a similar principle for software engineering. Can a single EverythingIsa be created that can be everything to everybody, or at least most things to most bodies?

I suspect that this is not possible because constraints are part of the alleged power of some paradigms. Paradigms can be viewed more or less as contracts: You live by rule/restriction set X and then I can deliver benefits and technique set Y. (And provide a somewhat consistent way to package things.)

For example, FunctionalProgramming has the "no side-effects" rule that allegedly makes it easier to reason about the combined affects of bunches of FP atoms (emergent behavior). And, relational has rules such as a primary key (uniqueness to tuples) that navigational lacks. In that sense, are we really fighting over "un-features" instead of features?

If so, is it possible to at least make those constraints easier to add and remove as needed so that the portions we do agree on do not have to change? It could resemble the FeatureBuffetModel. For example, there may be a menu of constraints, and OOP fans will turn on different constraints than what relational fans or functional fans do. Static typing/strong fans may also turn on a different set of constraints than dynamic/loose-typing fans. (Perhaps the type system can double as the OO class system. There are lots of similarities.)

It is essentially the subtractive approach to tool design instead of the current additive approach. The advantages of the the subtractive approach are twofold. First, you don't have to reinvent from scratch features you may later want to add (switch on). Second, the features/constraints that are common to two or more paradigm groups are the same. This reduces the communications, learning curves, and tool/add-on construction costs.


I don't think your generalization unreasonable. The combats between various paradigms and programming disciplines really are about constraints in expression and semantics (e.g. to allow better optimizations, to guarantee security, to avoid crashing, to aide in proving correctness, to avoid or support hierarchy, etc.). Fundamentally, any 'property' you can say is true of a discipline or paradigm will be true of that paradigm because of constraint on expression or features - it wouldn't really be a property of the paradigm if the paradigm didn't force it to hold true! Whether or not a given property is 'good' is, of course, an entirely different question.

But I would not call constraints "un-features". If anything, features (at least in languages, including programming languages) ARE constraints. Consider phrases, for example: if a phrase is unconstrained in its meaning, it would essentially be meaningless and lack definition. When you give a phrase a particular meaning, you've constrained the meaning of said phrase... and you've also added utility and value to it. Consider that any blank page is unconstrained, having the potential to be filled with anything at all; that potential disappears only when you start inking words upon it and thus creating something with discernible features, which are properties.

I second this. It's the DifferenceThatMakesaDifference. By introducing a difference, a constraint, we partition our solution space into the part where it holds and into the part where it doesn't. Each part may have its own further distinctions, its own optimizations (like easier proofs for the functional side). On the other hand the very moment we introduce specializations on one part that have no matchings on the other we lose uniformity. -- GunnarZarncke

Is it possible to make constraints easier to manipulate? Maybe. Language itself can be manipulated from within another language quite easily, so long as the initial semantics exist for said operation (and I've done a great deal of research on that subject in particular). WaterbedTheory would have you watching out for what this might make more difficult... which, among other things, seems to include writing a parser for the contortionist language. But I think that's the lesser of problems. It's very important to keep in mind that many of the most valuable properties enforced by constraints are emergent in nature - you mentioned it yourself when discussing the emergent behavior of FP atoms. TypeSafety, Authority, Trust, HardRealTime constraints, etc. are among the set of emergent properties... and introducing one little loophole, even one, can break the property: you'll no longer be able to prove, reasonably assume, or even (if you are a rational being) claim that the property continues to hold. Thus, while you might be able to add constraints to allow some proof over various sub-components in your language, you cannot readily remove them.

Of course, you can't add just any set of properties like spices to some great stew. Some properties are contradictory. Often even 'good' properties are contradictory. You cannot have, for example, both HardRealTime constraints AND communications/networking protocols that will survive disruption and arbitrary delay - at least not at the same time and in the same communication environment.

It wouldn't be impossible to start without any constraints and always add them as needed to each subcomponent, and make this easier... but doing so doesn't leave us in much better condition than we are today (where you start without a goal, then gain a goal, then choose a language and computing platform, then do some design work, then write some code - each step on the way constraining the implementation of the component upon which you're laboring). Then you start choosing standards for communication between components - codecs, protocols, etc. Since your initial environment contained no constraints that the communications be well typed and such (and won't crash or root-hack your system), you'll need to run appropriate checks.

What would make this easier overall?

The approach described above would allow you to design computation-spaces that internally utilize your paradigm-of-choice without breaking them in the other computation-spaces. The spaces themselves are necessary because you can't remove most constraints without breaking them entirely... so, instead, you need to choose your constraints on a per-space basis and start with as few as possible. If it is all done in a single language (possibly one that can be reshaped into any other language... e.g. supporting query languages at one point and high-level process-pipelines at another), then one would never need to leave their toolbox to do the jobs and could be confident of the integration and of the various code-proofs that are performed.

This differs from the BigIdea topic in that the idea is not to force one best paradigm on everyone, but rather unite them all without taking away significantly what people like about each one.

Of course. EverythingIsa a constraint - or at least every feature.

See: LiberatingConstraint, BigIdea


EditText of this page (last edited January 14, 2011) or FindPage with title or text search