Hyperlambda, Zen, and the vanishing Liskov substitution principle

Zen is said to be the mental art of “nothing”. A Zen master once said, when you start out with Zen, the Buddha is everything. When you’re a Zen master, the Buddha disappears. The whys of this, eludes explanation, since it according to the Buddha himself is a realisation.

Phosphorus Five and System42 have similar traits. System42 is “the Buddha”, and Phosphorus Five is the goal. Once you’ve become a Zen master in P5, System42 vanishes.

Therefor, in my upcoming release, I have consciously removed System42 out from the P5 core, and created two separate projects out of these two very much different beasts. The reasons for this, will become obvious for you, as you become a Hyperlambda Zen master!

So what does this have to do with LSP?

LSP is arguably the single largest software architecture problem that has ever existed on the planet. Even extremely seasoned software architects seems to struggle with this problem every now and then. It is based upon the idea that unless one class is a perfect substitution to another class, they cannot inherit from each other in any ways. The textbook example of such a violation of the LSP problem, is having a square inherit from a rectangle.

For the above mentioned reasons, most senior architects will repeat the following mantra; “Prefer composition in favour of inheritance”.

In P5 there are no types. Or to be accurate, there is one type, but every single object in the system, is of the same type. This type is of course the “lambda type”. This means that LSP in regards to types is completely obsolete. In addition, it means that any lambda object, is a perfect substitute to any other lambda objects in your system.

My classic example of a violation of the LSP problem, that illustrates how the LSP problem disappears in Hyperlambda, is the System.Web.UI.Page class from ASP.NET. This class happens to inherit indirectly from System.Web.UI.Control. This is a clear violation of the Liskov substitution principle, since clearly a Page is not a perfect substitute to a Control.

When Microsoft originally created the ASP.NET class hierarchy, they had undoubtedly done their best. They also employed some of the best software architects on the planet in the process – .Net Framework is in general a really, really good piece of work! However, the above LSP problem, tells us something important.

If Microsoft couldn’t get this right, who do you think you are to get it right?

Facts are, LSP is very, very, very difficult – Even for senior architects! So completely eliminating all LSP problems, holds an extreme amount of value, for your ability to architect great solutions.

Hyperlambda does not have this problem. Let me illustrate that fact, by creating a “Hyperlambda user control”, which can take any existing [p5.page] object, and use it as a “control”. This proves that in Hyperlambda and P5, a page truly is substitutable with a control, and vice versa. The code below is fetched from “the guide”, and you can find the whole example code and explanation¬†here.

Below is a piece of code that does two things. It creates an Active Event, which serves as a “User Control”, or custom widget. In addition it inserts a [p5.page] object into your p5.data database.

 * This inserts a new page into our database.
    name:A page, that becomes a control
  innerValue:Click me!
      innerValue:I was clicked!"

 * This creates a "user control" Active Event,
 * which can take a [page] argument, that transforms
 * an existing [p5.page] object, into a "user control".

   * Selects the given [page] argument from database, 
   * assuming it is a [p5.page] object type.
    throw:Sorry, couldn't find that page

   * Adding results from above [select-data]
   * into [return] at the end of event.
   * Making sure we transform its Hyperlambda content
   * to a lambda object first.
   * Notice, we also "sanity check" page, making 
   * sure it has only one root node, that actually creates
   * some widget first!
    throw:Sorry, I cannot transform that page to a control

   * Modifying the [create-widget] invocation to either a
   * [literal], [void] or [container] node, according to what
   * type the root node of our page is.

     * Page creates a "root container" widget.


     * Page creates a "root literal" widget.


     * Page creates a "root void" widget.


After you have evaluated the above code, you can consume your newly created custom widget, to load up the page you inserted above, and treat it like a “control”. Do this with something resembling the following. Make sure you create a new “lambda” page in your CMS, and paste in the following code.

      innerValue:A page that consumes a page!

As you can see with your own eyes, in Hyperlambda a “control” can clearly be substituted with a “page”, and vice versa. Hence, the Liskov substitution principle has vanished. Let me repeat that again once more, to make sure it sticks …

The Liskov substitution problem has vanished!

Facts are, every single problem on the planet can be solved by making things vanish. If you don’t believe me, check out how I solved the unified theory of science, by making the universe disappear


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.