Hyper IDE, using No-Code and Low-Code to Generate Software

Hyper IDE, using No-Code and Low-Code to Generate Software

Declarative programming is based upon the "what" instead of the "how". It's probably easier to explain by using a real world example of something you might want to achieve using programming.

Imagine you want to create an API endpoint that allows users to register in your backend, while simultaneously making a payment towards Stripe. This could be for something that's a subscription-based service, where you charge people for access to something.

In a "how" world this requires understanding of the HTTP standard to be able to invoke Stripe's API. It requires knowledge of security concepts such as blowfish hashing passwords and connecting to your database. In addition to obviously knowledge about how Stripe's API is tied together.

The amount of knowledge you need to do this simple task requires years, and sometimes decades of training. In a "what" programming language, implying a declarative programming language, it only requires you understand how to decorate an invocation towards Stripe's API, using a modal dialog such as the following.

Declarative programming with Hyper IDE to create a Stripe payment

10 years of training reduced to a simple modal dialog you can probably understand in some few minutes if you try. The cost savings should be obvious at this point

With declarative programming any human being can in theory create fairly complex applications without prior knowledge about software development

Hyper IDE

Hyper IDE allows you to create workflows. A workflow is a chained sequence of actions, similar to functions, where each action might produce a set of output, and the output of one action can become the input to the next action.

This allows you in theory to create anything you can create using any other programming language, except 10,000 times easier, because there's no "how" in an action. The above action for instance will internally read settings from your configuration object. Then it will decorate and create an HTTP POST invocation towards Stripe. Once Stripe returns, it will sanity check the result to make sure the invocation was a success, before allow control to "flow" to the next action. If an error occurs, it will abort the execution of your workflow by throwing an exception.

The above action does not require you to understand HTTP, how to read from your configuration settings, how to decorate a Stripe API invocation, or any of the other "how constructs" - It simply cares about "the what" which is.

  • Who is paying?
  • What payment method is the person paying with?
  • And what's the price reference?

As an optional question, it asks the software developer if he or she wants to have Stripe automatically collect tax or not. Everything else is "hidden" behind its implementation, making it 100% perfectly "encapsulated". In fact, the software developer using the above dialog doesn't even need to know that it's creating an HTTP POST invocation towards Stripe. From the software developer's perspective, the fact that the action is using HTTP is completely hidden, and have "vanished into Magic" ...

40+ years of software development experience reduced to a simple dialog

There is no difference in the quality of the above modal dialog and the best possible solution a senior software developer could in theory create - Quite the opposite in fact, since the above modal dialog typically will be reused in thousands of apps, resulting in much more stable and secure code in the end due to being "debugged by the world".

Hyperlambda and Meta Programming

Declarative constructs such as the above is typically facilitated for by meta programming. Meta programming implies code that creates code. Meta programming needs to be highly dynamic, it's therefor typically created using XML or JSON.

However, Hyperlambda is simply superior as a mechanism to describe workflows, because even though the intention is to use declarative programming constructs, you still can actually read the code it creates, contrary to what you end up with if you're using JSON, YAML, or XML. If you ever tried to "debug an XML file" you'll understand what I mean here.

To illustrate that point let me show you the end result of clicking the above "OK" button, and what the modal dialog creates for you.

 * Creates a new Stripe payment for the given [customer_id], using the
 * specified [payment_method_id], for the given [amount], in the given [currency].
 * Will use your Stripe API token found from your settings as it's interacting
 * with the Stripe API.
      description:Payment from Magic

Now imagine how the above would end up looking like if we used XML or JSON. It would basically be impossible to read.

In addition, since it's actually humanly readable, you can edit the code using a code editor. Below is a screenshot of me editing Hyperlambda using the autocomplete feature from Hyper IDE, automatically suggesting code for me.

Autocomplete in Hyper IDE suggesting code for me

Hyperlambda, Hyper IDE, and Workflows, basically provides a superior development experience, requiring close to zero knowledge about coding, making me 1,000 times more productive. Or to rephrase ...

Where the Machine Creates the Code


Declarative programming through Low-Code, No-Code, Hyperlambda, Hyper IDE, and Workflows, allows me to work 1,000 times faster than a traditional programming language. In addition it results in higher quality code, and more secure solutions, since it becomes impossible to overlook anything.

In the video below I go through how to create an HTTP POST endpoint that allows users to register in your backend, for then to make a purchase using Stripe. If you asked the average senior software developer how much time he or she would need to achieve the same, the answer would be at least one day - Possibly a week. I create it in 20 minutes, while explaining on YouTube what I do, and how everything works.

When I'm done, I connect my API to a custom GPT, using natural language, and I invoke my API with ChatGPT and OpenAI's models, using nothing but natural language as my "user interface".

Software development today is in its infancy. To some extent, the way we're creating software today can be compared to the way monkeys created tools 2 million years ago. My bet is that 50 years from now, the way we produce code today with OOP, files, keywords, variables, and function invocation - While focusing on "the how" - Will be the laughing joke for future generations.

Alan Kay said in 1998 that "The computer revolution hasn't even started". 25 years later I still agree with him. We've moved some few inches beyond the equivalent of the steam engines from 1865, but we've barely tapped into 0.1% of the potential we have for a true "computer revolution". And to truly embrace the computer revolution we need to make software development available for the masses. Today 0.3% of the world population can create software to some extent. At AINIRO.IO our goal is to increase that number to 100% ...

Our means to accomplish the above is Magic.

Thomas Hansen

Thomas Hansen I am the CTO of AINIRO.IO AS. I am a software developer with more than 25 years of experience. I write about Machine Learning, AI, and how to help organizations adopt said technologies. You can follow me on LinkedIn if you want to read more of what I write.

Published 16. Jan 2024