Every time you create software, you have a separation between code and data. Data is dynamic in nature, can be queried, modified, aggregated, and used to create new data. Code on the other hand is static in nature, often compiled, and unchangeable once finished. How would you react if I told you that the separation between code and data is just plain wrong?
E=mc2
The above was the greatest discovery in physics in the 20th Century. At its most fundamental level it implies there's no difference between energy and matter. 40 years after Einstein phrased the above equation, we were able to split the atom and prove him right.
As we split the atom, we unleashed unfathomable amounts of energy. A couple of grams of Uranium could release more energy than a thousand tons of TNT. The process was entirely based upon Einstein's ideas that energy and matter are two different states of the same thing.
I believe similar gains can be acquired by realising code is just "a special state of data."
Meta programming
Meta programming is different from traditional programming. It implies you create code that creates and modifies code. Instead of assembling your algorithms and data structures statically during development, you have algorithms and data structures whose responsibility it is to generate new algorithms and data structures. AKA ...
Where the Machine Creates the Code
To achieve this, we need the means to dynamically assemble code. To dynamically assemble code, we need to imagine code as data. To imagine code as data we need to eliminate the separation between variables, keywords, function invocations, and data segments.
We need to merge these two distinct ideas into one idea!
Hyperlambda
Hyperlambda is my invention. It's probably one of the least popular programming languages in existence. As far as I know, there's one software developer actively using it, and that's me.
I've used Hyperlambda almost exclusively now for almost a decade. Personally I don't care how many other developers are using it. I've built a 5 digits MRR company entirely based upon it, where I can deliver sometimes in some few hours what other companies need hundreds of hours to deliver. This allows me to bill 10x as much per hour as other software developers, because I spend 1% of the time to deliver the end result. So yes, I'm about to become very, very rich, with my own company, where I'm the sole software developer in that same company - Because my clients pays 10% of what other developers would have to charge them, because of Hyperlambda's productivity gains for me personally ...
Initially when I invented it, I was super enthused about my discovery, and I tried to explain my ideas to other software developers. They all thought I was crazy, so I simply stopped sharing, closed its source code, and started using it myself.
Structure of Hyperlambda
Hyperlambda is ridiculously easy to understand. It's a text representation of a graph object mirroring the following pseudo code.
class Node
{
string Name;
object Value;
List<Node> Children;
}
It separates between the name and value with a : and it declares children on a new line with 3 SP characters. Below is an example.
name1:value1
name2:value2
child_of_2_name:child_of_2_value
In the above example there are 3 nodes. One node is a child node of another node. Basically what we've got in the above example, is a textual representation of a graph object, allowing us to declare nodes similarly to how JSON allows us to declare graph objects.
JSON doesn't work
There are two key differences between the above code and JSON, and that's the fact that Hyperlambda's children collection is not a dictionary, but a list of nodes. This distinction allows us to declare multiple nodes with the same name at the same level. To illustrate why that's important, imagine something as follows.
if
// Blah, blah, blah
else
// Blah, blah, blah
do-stuff
if
// Blah, blah
With JSON the above is impossible to describe without adding an additional level of indirection. This is because the fields in a JSON object belongs to the same dictionary, so the second if statement will "overwrite" the first. Describing the above Hyperlambda using JSON would resemble the following.
[
{
"name": "if",
"children": [
{
"comment": "// Blah, blah, blah"
}
]
},
{
"name": "else",
"children": [
{
"comment": "// Blah, blah, blah"
}
]
},
{
"name": "do-stuff"
},
{
"name": "if",
"children": [
{
"comment": "// Blah, blah"
}
]
}
]
The above JSON is 29 lines of code, the above Hyperlambda is 7 lines of code.
YAML doesn't work
YAML doesn't help us either, because it's just a different representation of JSON, so it suffers from the same problems as JSON in that fields cannot have the same names.
- name: if
children:
- comment: "// Blah, blah, blah"
- name: else
children:
- comment: "// Blah, blah, blah"
- name: do-stuff
- name: if
children:
- comment: "// Blah, blah"
Sure, syntactically its YAML version is less verbose, with only 10 lines of code - But it's still almost completely unreadable. This is because in JSON which is beneath YAML you have an object who's a key/value entity, where the value can be a list of other objects. The "key" parts becomes your problem.
In addition, there's a fundamental lack of typing in JSON making it impossible for us to declare native types. In Hyperlambda you've got the option of declaring a native type by adding a type declaration between its name and value as follows.
some_date_value:date:"2024-01-01T01:01:01"
This trait of JSON is inherited by YAML so both JSON and YAML have the same problems.
Lambda Expressions
After having Hyperlambda, or some other means to describe a graph object, all that's remaining is to create the ability to uniquely referencing individual nodes and node-sets. This is accomplished with lambda expressions. Lambda expressions are similar to XPath expressions, allowing you to "walk" the graph object declaratively, and reference nodes you for some reason need to access - Either to read their values or change their values (or names).
Once you've got the ability to change names, values and children collections, you've got the ability to dynamically assemble "code". The "code" isn't code in its traditional meaning, it's something completely different in fact - But it is something that allows you to exchange with your existing code to allow for it to execute functionality similarly to how a function in JavaScript executes functionality.
An Example of Hyperlambda
Below is an example snippet in Hyperlambda. It is the declaration of an HTTP endpoint that takes some arguments, makes sure the user is authenticated, opens a database connection, creates a new record in a table, for then to return success to the caller.
/*
* Create endpoint inserting one record into your Album table
* in your chinook database taking AlbumId, Title, ArtistId
* with authentication and authorisation for root, admin
* roles.
*/
.arguments
// AlbumId column value
AlbumId:long
// Title column value
Title:string
// ArtistId column value
ArtistId:long
// Verifying user is authorized to access endpoint.
auth.ticket.verify:root,admin
// Opening up database connection.
data.connect:[generic|chinook]
// Parametrising our create invocation.
add:x:./*/data.create/*/values
get-nodes:x:@.arguments/*
// Creating our record.
data.create
table:Album
values
// Returning the correct status code.
response.status.set:201
// Returning result of above invocation to caller.
return
result:success
I have seen software developers spending weeks on creating something resembling the above because of over engineering, wanting to "throw every design pattern in existence" at the problem, creating abstract factories, repository classes, multiple models with one DTO model, another database model, etc - While adding AutoMapper to it, and configuring it to correctly transform between a handful of different types, etc, etc, etc. For then to spend weeks debugging some obscure bug that happens because the developer forgot to configure his IoC container for one of his services.
Most C# solutions I've seen trying to accomplish the same as the above Hyperlambda have easily somewhere between 10 and 50 files for a simple CRUD POST endpoint creating a record in your database with authorisation.
The above code was created by the machine. Look at the following screenshot, and realise that when I click that button, it generates CRUD endpoints for every single table in my database. The above code is one file, and the process can generate thousands of files in seconds.
I could also create similar snippets of Hyperlambda based upon anything that exposes meta information, such as OpenAPI and Swagger, the file system, etc, etc, etc. As long as Hyperlambda can somehow get access to meta information, it can use that meta information to generate code.
What's the big deal?
Sure, you can do the same in C# and Java. You can create processes that reads meta data and generates code automatically for you. However, there's one crucial difference; In Hyperlambda meta data is not lost.
When you generate C# or Java code, you end up with CLI code or ByteCode. At this point all meta information has been lost, and traversing a CLI object to figure out what it does is practically impossible.
When you preserve meta data during the process, you can keep on iterating the process - Building one process on top of another, that enumerates your code, understands what it does, and continues the process in layers. To understand the importance of that simple fact, look at the following screenshot.
The above description is dynamically fetched from the Hyperlambda file itself, and based upon its description, input arguments, and what it does.
What it does is to create a training snippet for a RAG-based AI chatbot based upon OpenAI. When the training snippet is created and the embeddings have been created for the model, I can provide instructions to my chatbot such as the following;
- "I want to create a new Album"
At which point the chatbot will respond with "What data do you want to insert. Please give me the album name, the artist, and I will proceed." To understand the value proposition you'll need to watch the following video.
This becomes real value, allowing me to "generate" AI chatbots that works like AI Agents to an extent difficult to imagine for those not having experienced it. To understand the time savings, consider this screenshot.
The above takes every single Hyperlambda file from within one folder, read its meta data, and generates AI functions for every single one of them. This allows me to create a backend API, click a button, and have the whole thing embedded into an AI Agent chatbot.
One button click and I've saved thousands of hours. Another button click and I've saved thousands of more hours.
Why do I care?
I've tried to explain Hyperlambda's advantages to the software development community for a decade now, and nobody wants to listen. So why do I care? Well, I'm not sure I do.
I suspect it's just stupid of me these days to continue advocating Hyperlambda. After all, I've got my own evolutionary optimum, currently allowing me to make 10x as much money as everybody else. And since I closed its source code 6 months ago, I'm the only one in my position. If I was smart, I'd just shut up, stop talking about it, make my money - And laugh all the way to the bank. However, maybe deep within me somewhere there's some part of me that still wants recognition for my work, making me periodically write articles such as this. Maybe I only want to mock the idiots at Reddit who mocked me previously? I don't know, but I suspect there's some part of me deep down that simply wants to look at their faces when they realise just how much better Hyperlambda actually is than they originally thought!
However, fundamentally I don't care if you think I'm crazy. I can outperform you as a software developer on productivity and deliveries by at least one order of magnitude. I don't care who you are, I'm more productive than you - Period!
And clients are noticing, implying I get a lot of work, where I can make 10x as much money as you do per hour, even though the client is paying 10% of the price.
But hey, by all means, please go back to your abstract factories, repository patterns, AutoMapper configurations, and 37 layers of structured micro services - Because after all, I'm crazy, and you shouldn't listen to me - Right ...? 😏
After all, OOP is a beautiful thing. Your professor told you, and he must be right, right? And design patterns are necessary, and SOLID and clean architecture increases maintainability, right?
Nothing to see here, just a crazy man, advocating a crazy way of creating software, right ... 😁
But one day in a not too distant future your client and your employer is going to discover AINIRO and realise that I can do in 1 day what you need 200 days to do - At which point he'll be willing to pay me to do your job. So far I've had about 50 to 100 stakeholders understanding that simple fact. I get one new stakeholder roughly each week. Extrapolating the growth curve implies 100% of every single software project people are willing to actually pay for, will be Hyperlambda somewhere down the line, maybe 5 to 10 years from now. But then it's too late for you. At that point the train has left the station. And I really don't care ...
... for the rest of you guys reading this, there's always:
Thx for reading 😊
Top comments (2)
Its a shame Hyperlambda didn't take off, but I think there is still on opportunity for you to talk and share Meta Programming in general, I love the idea and suspect you are right it will be ubiquitous as OOP one day, would be a shame if someone else took the credit.
Thx :)