We’ve taken unto ourselves to teach Hyperlambda and Aista to a bunch of project managers from Ukraine. The process is quite simple; we spend 10 hours divided into two days with hands on sessions, where the participants are creating software and using Aista themselves, with the idea of giving them a specification at the end of day 2 that they are supposed to implement using Aista. Below you can find the recordings of all session from day 1 in this Hyperlambda course.
The idea of the course is to teach all the basics required to become a Hyperlambda developer to somebody never having seen the language before, and to teach it in 2 days. Day 1 we’re going through the Magic Dashboard, creating a web app by using the CRUD generators, touching upon the SQL endpoint generator, creating our first Hyperlambda endpoint manually, etc. In addition we’re designing a database ourselves from scratch, and generating a CRUD app wrapping our database. We also speak about the philosophy behind Hyperlambda, and how important meta data is to be able to automate software development. Then we give you a tour of our internal closed source code, implying the code that we’re using ourselves to deploy cloudlets, and the entire middleware of our own platform.
I have been given permission to share these sessions publicly, so below you can find all recordings from day 1.
- Session 1 – The Magic Dashboard, the CRUD generator, SQL Studio, and all other UI components in Magic, in addition to some basic Hyperlambda
- Session 2 – Creating the Hello World Hyperlambda endpoint, URL resolving, Hyper IDE, the basic structure of Hyperlambda, meta data from endpoints, working with the Angular code locally
- Session 3 – Creating a task management system with the CRUD generator
- Session 4 – How we built our entire middleware using Hyperlambda
Top comments (2)
There are some very interesting things in this, pretty sure I'm not the ideal audience for it, but I'm fascinated by some of the choices made in the design of the system, the language and the integrations.
I guess my biggest questions are around: where is it wise to use code modification at runtime rather than the areas where I can see the benefit of emitting end points and front ends etc. I guess if I had been designing this I would have used Javascript as the intermediary language.
The course attendees were probably not the right people to see some of the more advanced use cases I guess.
Smart questions. Let me start with the JavaScript parts. We need a meta programming language to pull this through. There haven't existed meta programming languages in main stream usage for some 40+ years. So everything "modern" is out for these reasons. In theory we could have used JSON or YAML, but that would make the thing twice as "verbose". Hence inventing our own (open source) language was the only viable choice, unless we chose Lisp or something too old to get to run in a modern context. Hyperlambda is created on top of C# though, so it's arguably "better" in regards to standards and modern features, such as async, etc.
As to the course attended not being my optimal audience I agree. They were all PMs really, and for such courses I need juniors (empty cups).
As to where to use it? With huge legacy code bases you want to replace, SQL apps, everything CRUD, and/or internal backend admin apps, and/or only using the API parts for customer facing frontends.
However, the really great use case is that it arguably turns a junior dev into a "senior dev" in 2 days, due to being an extremely high level abstraction where it's almost impossible to mess things up ...