The Pragmatic Developer would have used Hyperlambda
The last couple of days I've been comparing Hyperlambda implementations towards its C#, Rust, GoLang, and Python equivalent. The examples I've picked are the most popular tasks we do as enterprise software developers, and includes examples such as;
- Reading items from a database in an HTTP endpoint
- HTTP endpoint allowing the client to send emails
- HTTP endpoints integrating with 3rd party APIs
And the results have been consistent. Hyperlambda on average allows you to get away with 5 to 10 percent of your codebase. To illustrate what that means, please consider this image. This image contains the code required to integrate with an HTTP 3rd party endpoint in both C# and Hyperlambda. The Hyperlambda example is 6 lines of code in one file. The C# example is 61 lines of code in 5 files.
This implies it'll be 10 times as expensive to maintain and fix bugs in the C# solution, since resource requirements to maintain a solution grows proportionally to its lines of code.
Declarative Programming
Declarative programming is the art of describing what you want and ignoring the how parts. SQL is an example of a declarative programming language, but most concepts in programming lends themselves to a declarative design. This happens to be how the rest of the world works for all practical concerns, and is therefore by the very definition of the term a "better" way of dealing with logical problems than imperative programming.
If you're to undergo surgery for instance, I doubt that you'd tell your doctor how to do his job. Instead you tell him about your problem, the doctor diagnoses you, and suggests a treatment. Once you've decided upon a treatment, most people allows the doctor to do the actually surgery without interference from you.
In addition, if you want your wife to bring you a cup of coffee you ask her "Can you bring me coffee dear?" The "imperative equivalent" would be to describe to her how to move her feet, point these towards the kitchen, walk into the kitchen, put water in the kettle, etc, etc, etc. I assume you can see the advantages here ...
I just described the advantages of declarative programming!
With declarative programming languages such as Hyperlambda, incredibly smart people have spent insane amounts of energy to implement the actual logic. This allows you to "declare your intent", ignore the "how" parts, and "annotate" your code with your intentions. To understand the advantages, consider this Hyperlambda code from the above screenshot.
.arguments
http.get:"https://api.chucknorris.io/jokes/random"
convert:true
yield
joke:x:@http.get/*/content/*/value
The equivalent C# solution is 60 lines of code. The above is 5 LOC. In addition, the declarative underlying implementation have been battle tested in thousands of different codebases, and optimised to an extent you can never afford to optimise your code. To believe you get advantages from an imperative solution to the above problem that the declarative solution doesn't give you, is delusional at best, and corruption at worst. And the problem is not specific to C#. GoLang is in no ways any better here ...
Hyperlambda's History
I invented Hyperlambda in 2012. My reason was that I realised I was constantly repeating myself in code, and that 90% of my code was just unnecessary overhead originating from our industry's "best practices". Well ...
It's not "best practices" if you have to do it every time you code. At that point it's literally OCD! As in Obsessive Compulsive Disorder ...
However, as I shared my programming language with the world, I was mocked and ridiculed. Other developers was critisising its syntax, performance, scalability, and flexibility. Neither of these arguments makes any sense, since Hyperlambda literally outperforms most other languages on all of these axioms - But anyways, this was the only result I got from "the community".
For instance, Hyperlambda is literally 7 times faster than Python, and also easily deploys into K8S, making it literally a "bajillion" times more scalable and fast than Python. Still I keep on meeting this same arguments, over and over again - Which is why I feel compelled to creating these articles and videos.
Wrapping Up
We've gone through code examples illustrating how you're basically wasting between 90 and 96 percent of your software development department's velocity, while in the process reducing the end quality of the products you deliver, because of that you are "stuck" in a local optimum of false assumptions.
Instead of regurgitating what others are saying about Hyperlambda, may I suggest you investigate it yourself? Everything is open sauce and can be freely downloaded to your own machine. I suggest you do that, and try it, instead of making a fool out of yourselves by repeating arguments I literally debunked 10 years ago!
