How I created a billion dollar software system in a couple of hours with Hyperlambda

In our last article we looked at how to manually create a Hyperlambda endpoint. In this article we'll take a break from creating code ourselves, and rather look at an example use case, being a support ticket system. Watch the following video for a walk through of the system in general.

There are some pretty bold statements in the above video, and to understand them it's more important to understand what you cannot find in the system.

• There is no Domain Driven Design in the system
• There is no complex orchestration of Design Patterns
• There are no message queues implementations and no enterprise service message bus brokers in the system
• There is no OOP in the system
• SOLID design principles cannot be found anywhere in the system
• There is no Micro Service Saga libraries in the system
• There are no classes in the system, and zero interfaces in it
• We didn't need Kafka, Solace or NServiceBus, so we did what any sane human being does at such a point, which is to simply drop it
• The system doesn't have MongoDB, CouchBase, Scylla, Kassandra, Dynamo or Cosmos
• There is no "server less stuff" in the system, neither Azure Functions nor Lambda Functions
• We didn't need event driven design, long lasting micro service transaction implementations, or ("put in your favourite rubbish software development principle here") - So we simply dropped it
• Etc, etc, etc ...

In fact, from a functional point of view, all Hyperlambda files except one have a one to one relationship towards a "web function", where each Hyperlambda file can be invoked over an HTTP connection, which results in mutating the state of the system somehow internally, resulting in the capacity to store support tickets and associated data, referencing registered users in the backend it runs on. Period!

I implemented 80% of the system's code in 2 seconds!

Functionality

The way the system works, is by allowing registered users to create "support tickets", for then to enter into a dialog with a support technician working for Aista, until the user is satisfied with the support, and chooses to close the support ticket himself or herself. Each support ticket has some traits, most of which are one to many references towards other helper tables in the system, such as follows.

• Department
• Priority
• Status

In addition each support ticket have a title and a description, and a created date, and a support technician can increase or decrease the priority of a ticket according to his or her reasoning, allowing a ticket to enter a "priority state".

The system sends emails to the registered user functioning as his or her receipt as somebody answers the ticket, and in later versions we might implement the ability to associate files with a ticket.

Implementation details

It took me all in all roughly 2 hours of coding to implement it in its entirety, including adding it as an open source "plugin" to our internal plugins section, allowing you to install it in your own cloudlet as you see fit.

Notice - You'll need to configure your SMTP settings to make the system work in your own cloudlet.

Conclusion

I have seen software projects such as this being given half a dozen of software developers, requiring months to implement, and some of these projects never being able to enter production at all in fact. The reasons for this is because if you give the average software developer something that's intrinsically super simple to understand, to the point where it can be understood by a kindergarten child, the default intuition of the software developer is to overcomplicate it, adding layers upon layers with unnecessary complexity, until the architecture and design of the system is so difficult to comprehend, it's impossible to sustain it as a development project anymore.

Hyperlambda doesn't allow for the above to happen!

Because in Hyperlambda it's not even possible in theory to create a complex class hierarchy. In Hyperlambda it's not even possible in theory to violate Liskov Substitution Principle, simply because there are no classes. In Hyperlambda it's almost impossible to violate single responsibility, simply since one function equals one HTTP endpoint. Etc, etc, etc ...

Yet again, I built the thing in 2 hours. If you can reproduce what I did in "your favourite OOP language of choice", I will send you 100 EUROs worth of BTC if you send me your BitCoin wallet address!

Got Magic?

If you want to create something similar you can register for a Magic cloudlet here and start playing around with Hyperlambda. However, I encourage you to read the articles in this series in sequential order, since that will make things easier for you. If you start out with the first article, you'll be back here in probably an hour I assume.

Notice, even though I spent 2 hours creating the system's code, I only spent 2 seconds creating 80% of its code, and we intend to use this system as is, maybe with some additional 2 hours of coding in total as our primary ticket system at Aista!

Explanation

There are only 3 possible explanations to what you've just read here.

1. I'm lying and I really spent 3 months implementing it.
2. I am special, to the point where I as a person are 15 orders of magnitudes more productive than the average software developer, and Microsoft, Amazon and Google should be fighting over me, and pay me $150,000 per hour to work for them.
3. There is "something special about Hyperlambda that allows for these kind of systems to be built much faster than any other programming language allows for."

I'll leave it up to you to figure out which of the above explanations are the actual truth. However, you can follow my GitHub commits, and probably replace what I did for yourself if you create your own cloudlet ...