FROG: Building the future of open graphical programming

What if the next great engineering language was visual, open, and built for the modern world?

What if software could be designed the way real systems actually behave?

What if, instead of hiding logic behind thousands of lines of syntax, we could see computation as flows, dependencies, interactions, signals, and decisions?

What if programming complex systems could become more intuitive, more ergonomic, more accessible, without sacrificing rigor, determinism, or industrial reliability?

This question has been on our minds for a long time at Graiphic.

And after a great deal of reflection, we have decided to act on it.

Today, we are announcing the launch of FROG 🐸 Free Open Graphical Language https://github.com/Graiphic/FROG

This is not a small side project. It is not a marketing exercise. It is not an experiment without direction.

It is one of the most ambitious technical challenges we have ever chosen to undertake.

First, a word of respect for LabVIEW

It would make no sense to talk about FROG without first acknowledging what came before it.

For decades, LabVIEW proved something that many traditional software communities underestimated: graphical programming is not a gimmick. It is not a toy. It is not a simplified version of “real programming”.

On the contrary, it demonstrated that a graphical dataflow paradigm can be incredibly powerful for engineering, instrumentation, automation, testing, control, monitoring, and rapid prototyping.

It allowed generations of engineers, scientists, technicians, and researchers to build software by reasoning visually about systems, signals, data movement, execution order, and interaction. In many contexts, that way of thinking is not only more intuitive, it is closer to the real structure of the problem itself.

LabVIEW showed that programming could be visual and serious. Accessible and powerful. Fast to prototype, yet capable of driving real industrial systems.

That deserves respect.

And in many ways, it also deserves continuity.

But respect does not mean ignoring the limits

As powerful as this paradigm is, the broader ecosystem around it has clear limitations.

Over time, the world of software moved toward open standards, open tooling, open compiler infrastructures, cross-platform runtimes, collaborative ecosystems, and community-driven innovation.

Meanwhile, graphical dataflow development largely remained associated with closed environments, closed ecosystems, and toolchains that were often tightly coupled to specific vendor strategies, hardware priorities, licensing models, or historical architectural decisions.

That creates friction.

Not because the core idea is obsolete. Quite the opposite.

The core idea is still brilliant.

The limitation is that such a powerful paradigm should not remain locked inside ecosystems that are difficult to extend, difficult to open, and difficult for a wider generation of developers to adopt, evolve, or reinvent.

That is one of the reasons why FROG exists.

Why now?

Because the context is no longer the same. This kind of project would have been dramatically harder decades ago. Today, the landscape is different.

We now live in a world where compiler infrastructures are mature, documentation is abundant, UI frameworks are powerful, hardware abstraction is better understood, open-source collaboration is normal, and modern engineering teams can move faster than ever.

Languages are better. Frameworks are better. Toolchains are better. Build systems are better. Rendering technologies are better. Cross-platform development is better. And the availability of advanced coding assistants and technical knowledge acceleration tools changes the speed at which teams can learn, design, prototype, and iterate.

This does not make a project like FROG easy. But it does make it realistically possible. And that changes everything.

Our ambition with FROG

Our ambition is to build a graphical language that is truly designed for the modern world.

We want FROG to be accessible, ergonomic, and easy to approach. That is precisely why we believe in the graphical paradigm. When done correctly, graphical programming can lower the entry barrier while remaining extremely expressive.

But we do not want accessibility at the expense of seriousness.

FROG is being imagined as a language that can serve rapid prototyping, monitoring, orchestration, and control, while also aiming for stronger properties such as determinism, reliability, traceability, and industrial criticality.

The long-term vision is ambitious.

We want FROG to be hardware agnostic. We want it to be open by design. We want it to be usable across very different classes of systems. We want it to support both clarity of design and rigor of execution.

In other words, we are not trying to build a visual toy.

We are trying to explore what a modern, open, industrial-grade graphical dataflow language could become.

The hardest part is not the runtime

One of the most important realizations in our reflection is this:

the biggest challenge is not the runtime. The biggest challenge is the IDE.

This is a crucial point, because many people instinctively assume that the runtime engine is where most of the complexity lives.

In reality, for a graphical language, the IDE is where an enormous amount of the true difficulty resides.

Why?

Because a serious graphical IDE is not just a drawing application. It is not just a canvas with boxes and wires.

A real graphical IDE must provide an experience where the user can think, design, refactor, connect, inspect, debug, understand, and trust what they are building.

That means handling a huge number of problems at once:

The diagram editor must feel fluid. The interactions must feel natural. Wiring must be intuitive. The representation must stay readable. Types must propagate properly. Errors must be visible and understandable. The structure of execution must remain coherent as the graph evolves. The user experience must help rather than fight the engineer.

That is where the mountain really is.

In a project like this, the runtime can actually be relatively lean compared to the full weight of the IDE. The runtime must still be robust, deterministic, efficient, and well designed, but the IDE is where much of the intellectual, ergonomic, and architectural complexity is concentrated.

That is also one of the reasons why this challenge is so exciting.

Because building a graphical language is not only about execution. It is about giving form to thought.

A demanding specification from day one

We are deliberately setting ourselves a demanding brief.

We want FROG to support a clean architectural separation between expression, intermediate representation, compilation strategy, and execution model.

We want an approach that is not trapped by one hardware vendor, one operating system, one industrial niche, or one historical implementation style.

We want something that can grow.

Something that can support prototyping, but not stop there. Something that can support orchestration, but not stop there. Something that can support monitoring, but not stop there. Something that can eventually become suitable for serious industrial applications where predictability and robustness matter.

That is a very high bar.

And that is exactly why it is worth doing.

Why open source?

Because a project like this should not be born inside a closed box.

We do not want to create yet another isolated system with a closed ecosystem, closed innovation paths, and limited room for external builders to participate.

If graphical programming is to evolve meaningfully, it needs an ecosystem where creators, researchers, developers, educators, and industrial actors can contribute, experiment, challenge assumptions, build tools around the language, and innovate freely.

That is why we chose the open-source path.

Not because it is easy. Not because it is fashionable. But because it is coherent with the very nature of the ambition.

We want people to be able to inspect, understand, discuss, improve, and extend the foundations.

We want the ecosystem itself to become a place of innovation.

A language grows stronger when people can build around it.

Graiphic’s ambition

At Graiphic, we do not hide our ambition.

We want to become a company that matters.

Not by repeating what already exists. Not by staying confined to comfortable projects. But by taking on difficult, foundational challenges that can create long-term impact.

FROG is one of those challenges.

In many ways, it is our ultimate challenge.

Because it sits at the intersection of so many things we care about deeply: software architecture, developer tooling, industrial systems, ergonomics, accessibility, performance, openness, and long-term technological independence.

This is the kind of project that forces you to think bigger, deeper, and more honestly about what you want to build and why.

It is also the kind of project that cannot be carried by convenience alone. It requires vision. It requires consistency. It requires endurance.

And that is exactly why we are committed to it.

Looking far ahead

Right now, FROG is at the beginning.

There is a vast amount of work ahead.

There will be architectural decisions to refine, specifications to formalize, prototypes to build, trade-offs to evaluate, mistakes to correct, and many lessons to learn along the way.

We know the task is colossal.

But we also know that this is precisely the kind of moment where new foundations can be laid.

If successful, FROG could become useful for rapid prototyping, system supervision, orchestration of complex workflows, industrial control, and many other domains where visual reasoning and deterministic behavior matter.

And beyond the immediate horizon, there is room for even bigger dreams.

Why should a modern open graphical language not one day help drive highly complex systems in advanced industrial, scientific, or even space applications?

Why should it not one day be robust enough to help orchestrate the software logic of machines operating in the harshest environments imaginable?

Why not imagine, one day, a world where a language born from this effort helps guide a rover on Mars?

Ambition should not be confused with fantasy.

Ambition is what allows difficult things to begin.

This is only the start

The repository is open.

The work has begun.

And in the coming weeks and months, we will publish more articles and reflections explaining in much greater detail what we want to build, how we think about the architecture, why we are making certain choices, and what kind of ecosystem we believe should emerge around FROG.

There is a lot to explain. There is a lot to build. And there is a lot to challenge.

But this is the beginning.

FROG Free Open Graphical Language https://github.com/Graiphic/FROG

If you believe in open tools and the future of graphical programming, feel free to share this post.

We need you. The more people discover the project, the faster the community can grow and the faster we can build something truly useful for engineers, researchers, and developers.