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 an 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, 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 to understand how to decorate an invocation towards Stripe's API using a modal dialog such as the following.

Ten years of training reduced to a simple modal dialog you can probably understand in a 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 outputs, 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 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 allowing 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 has "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 are typically facilitated 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've 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.
 */
execute:magic.workflows.actions.execute
   name:stripe-payment-create
   filename:/modules/stripe/workflows/actions/stripe-payment-create.hl
   arguments
      customer_id:x:--/execute/=stripe-customer-create/*/customer_id
      payment_method_id:x:--/execute/=stripe-payment-method-create/*/payment_method_id
      amount:x:@.arguments/*/amount
      currency:usd
      description:Payment from Magic
      metadata
         username:x:@.arguments/*/username

Now, imagine how the above would look 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, which automatically suggests code for me.

HyperLambda, Hyper IDE, and Workflows basically provide 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

Conclusion

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 and 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 created 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." Twenty-five years later, I still agree with him. We've moved a 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 to the masses. Today, 0.3% of the world population can create software to some extent. 

Our means to accomplish the above is Magic.