Generative Objects (GO), introducing the Meta Low Code approach

[walter.almeida]

Hello everyone !

I present in this post, the new “meta low code” approach I am proposing, and implemented in the coming version of the Generative Objects platform.

I just copy here an article that is about to be published in CIO Application

I am looking forward for your feedback, suggestions, questions !

Generative Objects (GO), introducing the Meta Low Code approach

The low code approach is the new trend in developing software, bringing the promise of more agile and faster development of software while empowering non-technical users and bridging the gap between end users and technology.

However, the first generation of low code platforms that exists today comes with a double edge limitation, barrier to adoption:

• The applications that can be built are limited to the kind of applications a given low code platform was designed for, mainly data driven web applications.
• The applications are limited to follow the built-in architecture and design. You have little or no control over the technological stack and architecture.

This can be very restrictive for users who have specific functional needs that go beyond simple data management applications. On the technical side, the IT department usually does not like to have no control over the target technological stack, especially if the low code platform is relying on a black-box runtime.

Generative Objects (GO) goes much beyond, pioneering a new generation of low code platforms. With the introduction of our “Meta low code” approach, the versality and power of the original low code approach is rocketed to a whole new level.

The GO platform functions though a code generation paradigm, and a GO instance is composed of :

• A Functional meta-model. The meta-model is the non-tech, functional language used by business users to define and describe target applications. This model is de-coupled from the technological target stack. The core GO meta-model is for modeling data-driven applications.
• A pipeline of generation templates, and other tasks, used to transform the meta-model instance to a working application, on a given technical architecture. The core GO pipeline is targeting a centralized architecture, on top of .NET technologies.

The “meta” part of “meta low code” means that the low code platform is self-reflective: it is abstracted as a meta-model and a set of code generation templates and is, itself, a generated application. The GO platform is literally modelled and generated by itself :

The GO platform can therefore be used to extend or adapt the GO platform itself, or even to create fully specific low code platforms, empowering users with full control both at a functional and a technical level.

GO can be used out of the box as a ready-to-use low code platform to create data-driven applications, as a classical low code platform :

But to go further, the IT department can use GO to craft the exact low code platform that suits their organization’s functional and technical needs :

The business users can then use this new, specific low code platform to build their applications:

If the objective is to merely create data-driven applications, the IT department can keep the core GO functional meta-model, and optionally adapt or rewrite the generation templates to fit their technical requirements and target architecture.

In case of specific functional needs, the IT department can also literally craft a full-fledged specific low code platform by creating with GO a full, new application meta-model and associated generation templates pipeline.

As an example of a specific meta-model, we could use GO to create a low code platform for designing and deploying surveys with a functional language specific to surveys.

As an example of a specific generation templates pipeline, we could use GO to create a pipeline targeting a decentralized architecture, on top of decentralized technologies like Holochain (http://holochain.org) or others.

The GO platform is about to be fully open sourced (public opening before end 2021), with the intention to democratize access to meta low code technology and ensure wide adoption. We will lead a community of developers in growing the GO platform itself and the code generation pipelines, and of business users in growing a catalog of functional meta-models.

Alongside the open sourcing of GO, we will propose a cloud offering, to get immediate working access to GO platform private instances.

Generative Objects has been used in production over the last 12 years, on many enterprise applications for corporate companies, mainly in France.

[dponyatov]

Good day

Text looks having too much marketing and too low technical details: at least approaches are not described, if not code samples.

How did you solve the problem with tooling code complexity rising much faster than target (generated) code?

When I experimented with automated code generation by scripting, this problem stopped me a lot: generative tooling rises in an exponential-like manner while generated code stays at a level of HelloWorld and student works.

https://github.com/ponyatov/metaLgen/blob/dev/metaL.py (reduced as much as possible)

My first attempt was using Python scripts which should generate code for a set of target languages, but tactically it looks to me now impossible – nothing stops the expanding, and generative code itself fastly becomes unreadable with a huge amount of details.

[walter.almeida]

Hello @dponyatov , the intent of this post is not to dive into technical details but to introduce the “Meta low code” I am proposing. This meta approach applied to low code platform is for me something unique, and I wanted to share it here to get feedback, and actually focusing on this meta side, re-entrancy / self-reflectiveness of the low code platform, as this is the key to versality and power.

I will dive deeper in the technical presentation, probably during a Strumenta presentation (how about that @ftomassetti ?)

As a matter of fact Generative Objects is used on several large corporate projects (up to 300+ entities / database tables) and the complexity is handled well, in a linear way. This is actually done through the meta low code approach.

However, this meta approach was not externally exposed until now, just used internally. But is now a usable feature of the platform.

[meinte.boersma]

I think it would be interesting to implement a small part of an existing no/low-code platform using GO, next to creating entirely new platforms.

[walter.almeida]

Thank you for suggestion @meinte.boersma
And it is indeed what I want to do as a demo.

In fact, the idea is to see GO as a platform for designing meta models and associated code generation templates. So it is in fact an advanced code generator that support the abstraction level of a meta model and includes all that is needed to seamlessly link both abstraction and code generation with built in automation and orchestration, include the user interface to actually instantiate the model, include the API for programmatically instantiating a meta-model etc… So the meta-model can be very simple, and the code generation templates too. And it is by enriching the meta-model and templates that we can create full fledged low code platforms.

Then, to give a bit more information, next thing in the roadmap is to store the meta-model part as no-sql in GIT (it is at the moment stored in database), so that we can combine sub-models, manage versions of models, branch models, collaborate on models etc. To make GO a full professional environment using all the common tools at our disposal.

Saving the meta-model to GIT will be done by adding a GIT provider to the existing GO Core generation templates and adding to the GO Core meta-model the possibility to configure a GIT data provider. Entities in the GO Core meta-model are persisted through a data provider, various are already included, the GIT as no-sql is in progress. Then it will be only a matter of regenerating GO, switching the data provider of the GO Core meta-model entities to “GIT as no-sql”. This is an example of what can be done to extend GO with GO.

@rafael , this is the generic code generator you were wanting for when we first connected

[ftomassetti]

@walter.almeida

I will dive deeper in the technical presentation, probably during a Strumenta presentation (how about that @ftomassetti ?)

I think that would be interesting. We could discuss that at our next editorial board meeting with @Niko and @PaulSpencer

[kevinjmackey]

Interesting, with the potential to be very powerful.

So, I had time last year–because last year was 2020 and there was time, right?–and I came up with the below:

It puts into practice some of the Generative Objects ideas, without I’m certain the full tooling around GO. But the idea of a meta model, expressed in a straightforward, but flexible, DSL matched by a generalized code generation tool to a set of templates is there. As it is in Telosys.

I have used this Oscar generation system to produce REST-based APIs for data-driven CRUD code. The template implementation is pyratemp (a Python templating language) because that’s what the team knows best.

Oscar doesn’t mean anything (not an acronym.) I just have a bust of Oscar Wilde on my desk! (I’m Irish, can’t help it.)

I look forward to learning more about Generative Objects as I am certain the volume of code required by modern systems exceeds what is possible to produce in the timeframes needed.

[walter.almeida]

Hello @kevinjmackey

Nice, Oscar indeed is following a similar approach like Generative Objects (GO). It feels so natural and a properly engineered solution to have a metamodel approach. I find it stunning that most of the market low code platforms are not doing this !

The other aspect of GO that makes it unique and powerful is the self reflection of the whole platform, following the principle of compilers (a compiler is supposed to compile itself). The full platform, modeler and code generator, is modeled by itself and generated.

Also, the core metamodel is pretty advanced, so that the full UI is also modeled and generated, making it a platform that is end-users friendly.

What is you interest in GO ? Potentially be a user of the platform ? Or/and join the project and being a contributor ?

I am finalizing a few things and will come back pretty soon with a fully packaged product, so that I can make demos and offer test instances for whoever wants to try

[kevinjmackey]

Hello @walter.almeida

GO seems a good deal more advanced than what I cam up with for Oscar. I’d certainly like to take a look at it as a user. As to being a contributor, I doubt I can commit to that. I don’t have as much free time as I once had.

But I’m looking forward to seeing what GO can do, and how it goes about it.

[walter.almeida]

Ok @kevinjmackey , I will let you informed when GO version meta low code is finally ready to use, and I will share a demo. You can also register to the newsletter on https://www.generativeobjects.com to keep updated

[walter.almeida]

@kevinjmackey I am sure you experience on Oscar can bring very useful insight and ideas to GO. I am very happy to share with around this. I would love to do a session as part of Strumenta to present it deeper so that we can see if there is alignment with other members of the community

[walter.almeida]

Here is an interview of me with Holochain, talking more about Meta low code, and what I envision, especially in the decentralized world : Ecosystem Sessions – Generative Objects - YouTube

[digital-ember]

Hi Walter,

I’m not sure I understand yet how this approach is different from existing workbenches, or more generally speaking, how this is fundamentally different from meta-modelling?
Without having seen an example, it is hard for me to understand how your approach is novel over, let’s say MetaEdit+ or JetBrains MPS other than that it seems to be targeting the creation of “low-code platforms”, which I am not sure if there is a formal definition of what qualifies as low-code platform and what doesn’t.

Maybe you can elaborate on that a bit?
Thanks,
Robert

[walter.almeida]

Thank you for your question.

I would say one difference is that it is targeted at creating low/no code platforms for end users, non-developers or citizen developers. I believe platforms like MetaEdit+ or JetBrains MPS are targeting technical / developers users.

It is new for in the low code platforms spaces, platforms like Mendix, Outsystems and others, which have not embraced the meta-modelling approach fully but propose a rather inflexible way to model applications, and mainly data driven applications.

Also I don’t know to which extend MetaEdit+ or JetBrains are reflective and built with themselves. For instance : is JetBrains created with JetBrains ? Can you somehow open the model of JetBrains with JetBrains, evolve it and regenerated JetBrains ? Because this is what GO Meta low code does, and this is where the magic and infinite potential happens.

Let’s say GO Meta low code is bringing together the concepts or low code platforms and workbenches, along with self-reflectiveness.

I hope that’s a bit more clear. I struggle myself to find my words to describe GO as it is pretty hard to describe this inception stuff that is self-reflectiveness. Please don’t hesitate to ask me more questions as I would love to myself be more clear and find ways to express !!

I will do an online presentation of GO Meta lowcode with Strumenta in April. This will be also an opportunity to talk.

[digital-ember]

Thanks Walter,

I believe platforms like MetaEdit+ or JetBrains MPS are targeting technical / developers users.

I think the people at JetBrains and Metacase would strongly disagree with that. While it is true that you can build any sort of language with MPS, for example, it is not limited to people with technical backgrounds. See their introduction video for reference.

It is new for in the low code platforms spaces, platforms like Mendix, Outsystems and others, which have not embraced the meta-modelling approach fully but propose a rather inflexible way to model applications, and mainly data driven applications.

I agree with that, but maybe this is why they are so successful compared to existing solutions that do have a meta-modelling aspect to them? I am not a marketing person, so I can only guess, but I wonder why low-code has been so successful in recent years, and why more open, generic, meta-modelling platforms who can do pretty much very similar things, were not. Just as food for thought.

Also I don’t know to which extend MetaEdit+ or JetBrains are reflective and built with themselves.

I also don’t know this specifically, but I understand that many of the language-definition languages that come with MPS are build with MPS. I guess I just don’t understand yet what exactly the practical benefit is if a platform is completely “reflective” like you describe it, compared to being partly reflective or not reflective at all.

Good luck with the presentation, I will try to make it.

[walter.almeida]

Thank you @digital-ember for your reflections. It is very useful to me as it helps see what is the added value of GO over other solutions, which is not so easy for me to figure out. I intuitively know that I have something different, but it is not so easy to put into words !

@digital-ember

I think the people at JetBrains and Metacase would strongly disagree with that. While it is true that you can build any sort of language with MPS, for example, it is not limited to people with technical backgrounds

I can’t say too much as I haven’t checked where there are at for quite some time. However, looking at the video, MPS is still a tool for writing DSL. While people with no developer skills can write languages, it is still DSL/languages, not full fledge applications.

@digital-ember

I agree with that, but maybe this is why they are so successful compared to existing solutions that do have a meta-modelling aspect to them? I am not a marketing person, so I can only guess, but I wonder why low-code has been so successful in recent years, and why more open, generic, meta-modelling platforms who can do pretty much very similar things, were not. Just as food for thought.

This is where GO Meta low code brings the two together !! It is a full fledge low code platform, and can be used out of the box to create data driven applications the same way Mendix or Outsystem does, no difference here, same added value for end users. And at the same time it is at its core a full reflective meta-modelling platform, allowing meta developers to use GO Meta low code to improve the platform itself or build full fledge low code platforms to target other kind of applications or other target technologies ! So it gives all power to developers to create their own low code platform, that then non-tech guys can use.

@digital-ember

I also don’t know this specifically, but I understand that many of the language-definition languages that come with MPS are build with MPS. I guess I just don’t understand yet what exactly the practical benefit is if a platform is completely “reflective” like you describe it, compared to being partly reflective or not reflective at all.

Yes I understand that in MPS some part must be reflective as they have a language to create languages. So that languages could be self defining.
However for GO Meta Low code, the core languages encompasses all the aspects of a software application, from data mode to user interfaces, and this language is fully self-reflective.
The practical benefits are:

• It is faster to improve and evolve the GO platform itself, because it is fully modelled and built with itself, in a low code way. So the more we improve GO, the more rich it gets and therefore the faster it is to keep evolving it.
• It gives an easy way for users of the platform to improve / adapt the platform to meet there specific needs. Maybe a part of the generated code does not fully meet what they want for their generated applications, a developer can tweak the generation models to generate exactly what they want. Maybe there is an extra aspect they need to model, so they can tweak the meta-model to include it, and update the generation templates to take it into account.
• It gives the power to developers to create their own low code platform. What it means is that a customer who would want to embrace meta low code would first have a developer team to use GO Meta low code to build the exact low code platform they need for the kind of applications they want to build and on the target technical stack they want. Of course they can start from existing meta models (and we could have a catalog of several of them). And then business users can then use the specific low code platform. It means embracing low code as a whole in a company.

Does this make sense ? can you see the benefits or it is still unclear ? I guess I would need to find a few concrete examples to explain.