Hyperlambda, the Fastest Programming Language in the World

Hyperlambda is probably orders of magnitudes slower than most other programming languages in the world such as C#, Java, PHP, and Python - Still, when you're done with your project, I can pretty much guarantee you that your project will be blistering fast - Probably orders of magnitudes faster than anything you could possibly build in any other programming language - In addition to that it would scale hundreds of times better than a solution created with e.g. C#, Java, PHP, or Python. How on earth is this even possible? Well, let's try to understand it with an analogy originally created for children ...

To understand how Hyperlambda can be both the slowest and the fastest programming language in the world, you must realise that it's almost impossible to build a perfect app using "low level" programming languages, such as C# or Java. In addition, some of your favourite C#/Java/PHP/Python/etc "abstractions" are so sub-optimal in low level programming languages, that it's almost impossible to believe in before you've been carefully explained their disadvantages. So let's start with the goto O/RM tool of choice for .Net developers; Entity Framework.

Do you care about code quality? Read through Thomas' perspectives to improve code quality with Hyperlambda.

Entity Framework

As most .Net developers starts out their projects, they will typically immediately add Entity Framework from NuGet. This is the equivalent of "decorating" a Formula 1 car with a parachute, under the arguments of "making things safer."

Entity Framework is in fact so slow that StackOverflow had to remove it from their codebase. EF threatened to destroy SO's ability to serve HTTP requests. I could probably spend hours explaining you why, but I am not going to do that, but you can look it up for yourself if you wish. Entity Framework is at least 7 times slower than the equivalent pure ADO solution using SqlConnection and SqlCommand objects. And this cost is paid by your web server, by multiplying CPU time by 7, in addition to also consuming 7 times more memory. Hence, the added cost you're applying to your web app by adding EF to your solution, is that every single HTTP requests requires almost one order of magnitude more CPU time on your server, in addition to probably an equal amount of additional RAM, to serve basic HTTP requests doing simple CRUD lookups into your database.

Seriously kids, stay FAR away from O/RM libraries!

I don't care what Martin Fowler teaches you in these regards. I am right and Martin is wrong, period! Of course, your app's ability to scale, is reduced again by the square of the amount of CPU time your web server require to serve a single HTTP request, implying you can probably divide your app's ability to scale by some 1,000 or something, simply for having "the convenience" of being able to use an O/RM tool in your C# backend codebase. And no, the problem is only larger if you choose another O/RM such as nHibernate. In fact, EF is probably faster than nHibernate, implying if you use nHibernate, you can probably slash your scalability down by some roughly 10,000 times. In fact, EF is probably the fastest O/RM library for .Net, still it destroys your app's ability to scale by itself. 

O/RM libraries and scalability are two fundamentally incompatible concepts!

Seriously, do not use O/RM libraries! If you have to use a library, then please use Dapper, which is roughly on pair with Hyperlambda. Let me illustrate this with a video, and please realise that if I had built it with EF, each HTTP request would spend some additional 5x as much CPU time on my server. And yes, this is CPU time, implying the fact that EF is async becomes 100% perfectly irrelevant.

Complexity

Typically your web app invokes other 3rd party APIs. If you're anything like me, your goto class in these regards is probably C#'s HttpClient. However, I can guarantee you that roughly 95% of every single .Net app using this class is violating its usage somehow. In fact, it's almost impossible to use the freakin' thing without violating it somehow. Your own codebase is probably violating it to the extent of that your web server will if given enough throughput start returning HTTP status code 503, due to your HttpClient instances having thrown away socket connections as if they were candy. During my professional career of 20+ years as an enterprise software developer, I have still not seen a single codebase using this class correctly!

While I could go on ranting about HttpClient for days, it's not really a problem with HttpClient, but rather a problem of complexity. Unless it's dead simple to use complex logic, you will probably at some point not be able to implement it optimally. Maybe you even know how to implement things optimally, but you're not given enough time by your manager - And C# and other "low level" programming languages simply has too many configuration options, creating too much flexibility, resulting in leaky abstractions, penetrating through your app, resulting in that your app's ability to scale suffers. If the fastest solution is dead simple to implement, such as illustrated below however, it becomes hard to create sub optimal solutions ...

join
   fork
      http.get:"https://servergardens.com"
      log.info:Thread 1 finished
   fork
      http.get:"https://gaiasoul.com"
      log.info:Thread 2 finished
   fork
      http.get:"https://dzone.com"
      log.info:Thread 3 finished
log.info:All threads are done

Creating optimal solutions should be simple, while creating sub-optimal solutions should be hard. In low level programming languages such as C# and Java, this is reversed, such that creating sub-optimal solutions is easy, while creating optimal solutions becomes hard. This becomes the equivalent of purchasing a Formula 1 car with a parachute attached to it due to security reasons, and it requires two weeks at the mechanic to simply remove the freakin' thing ... :/

Choice

Do you want to know a secret? The more choices you have, the larger the probability becomes of that you will choose badly. And in fact the problem becomes worse by the human psyche's need to justify its own investments. In fact, this is more psychology than software development, but still penetrates through into your codebase none the less. Admitting you've invested badly is extremely difficult to do, because it reduces your ego's ability to sustain the belief in that you're "the best person in the world."

This "bad investment syndrome" results in that almost regardless of what problem you're faced with in the .Net world, if you search for an Open Source library implementing it, you'll probably find 24 million libraries to choose from. I can pretty much guarantee you that 23,999,995 of these solutions sux big time! While the 5 remaining ones are roughly what you're looking for, and better than all the alternatives. I suspect the same is true for Java, Python, PHP or "whatever".

In Hyperlambda, I have almost completely eliminated choice for you, through carefully considering all alternatives over a 20+ year long professional career, having taught myself through experiences which libraries are the best, and which ones to stay away from. Then I have wrapped my experience into a collection of Hyperlambda slots, allowing you to sleep at nigh, realising I've chosen for you! And that your choice is probably in the top 2% performing parts of the world.

I used to live in California for 3 years. Every time I went to SafeWay to buy sauce, I would be confronted with 176 choices of different sauces for my dinner. I am no sauce expert though, so the result was more or less always the same; I bought no sauce, and ended up dining at Outback as a consequence, which would only offer me ONE Teriyaki sauce choice to go with my ribeye. Seriously, if you think choice is such a great thing, then choose a grain of sand for me, and tell me it's the best grain of sand in the world - Then prove it! Having choices is a good thing, but being confronted with 25 million different types of HTTP wrapper libraries to create simple freakin' HTTP GET invocations from 3rd party APIs is not a good thing. It results in cognitive overload, stifling your creativity, and sub-optimal solutions for your clients.

All in all, the above things is the reason why the turtle wins, because the turtle always wins! So, now you know why Hyperlambda is the fastest programming language in the world ... ^_^

Hyperlambda WINS! The Turtle prevails!

Did you enjoy my latest content about Hyperlambda? I understand many of you have different opinions about Hyperlambda, but if you are interested to learn more, check my last article to improve code quality with Hyperlambda.