🐸 FROG: Rethinking Programming for the Next Generation of Engineering Systems

What if programming was no longer about writing code… but about understanding systems?

For decades, software development has been dominated by text-based languages. Meanwhile, in engineering fields, another paradigm quietly proved its value: graphical dataflow programming.

Tools like LabVIEW demonstrated that seeing the flow of data is often more natural than reading syntax.

But today, the world has changed.

Systems are:

• distributed,
• AI-driven,
• hardware-heterogeneous,
• and increasingly complex.

And the tools we use to build them are starting to show their limits.

This is where FROG (Free Open Graphical Language) comes in, an attempt to rethink programming from the ground up.

1) Why FROG Will Surpass LabVIEW

1.1 LabVIEW proved the concept but locked the ecosystem

LabVIEW’s core idea was revolutionary:

Programming can be visual, not textual.

That idea remains valid.

But its implementation created structural limitations:

• closed ecosystem,
• proprietary runtime,
• limited extensibility,
• vendor lock-in.

FROG takes a fundamentally different position:

• open specification
• open file format (JSON-based expression)
• separation between language, runtime, and IDE

👉 This is not just an improvement. It’s a shift from product to platform.

1.2 From monolithic tool to modular architecture

LabVIEW is vertically integrated:

• language
• IDE
• runtime
• deployment

FROG breaks this into layers:

Expression (source of truth)
        ↓
Intermediate Representation (IR)
        ↓
Compilers / Backends
        ↓
Runtime (multi-target)

This separation enables:

• independent evolution of each layer
• multiple IDEs or toolchains
• hardware-agnostic execution

👉 In other words: FROG is not a tool, it is an infrastructure.

1.3 True hardware-agnostic execution

LabVIEW supports multiple targets, but remains tightly coupled to its ecosystem.

FROG is designed from day one to be:

• CPU / GPU / FPGA / Edge compatible
• portable across environments
• decoupled from any vendor stack

This matters because modern systems are no longer centralized:

• edge AI
• distributed robotics
• cloud orchestration

FROG aligns with this reality by design.

1.4 Inspectability and transparency

One of the biggest limitations of graphical tools historically:

what you see is not always what the system executes.

FROG addresses this by:

• defining a formal intermediate representation
• making transformations explicit
• enabling inspection at every stage

👉 This is critical for:

• safety-critical systems
• industrial validation
• debugging complex pipelines

1.5 Open innovation vs closed evolution

LabVIEW evolves through a single vendor.

FROG evolves through:

• community contributions
• research integration
• industrial extensions

This is a fundamental asymmetry.

“A language grows stronger when people can build around it.”

2) Why FROG Could Become the Best Language Overall

This is a stronger claim, and it needs a broader argument.

FROG is not just “better than LabVIEW”.

It targets a deeper problem:

the growing mismatch between how systems are built… and how we program them.

2.1 Programming at the level of systems, not syntax

Most languages optimize for:

• syntax
• expressiveness
• abstraction

FROG optimizes for:

• system architecture visibility
• dataflow clarity
• execution semantics

This makes it uniquely suited for:

• robotics
• industrial automation
• AI pipelines
• cyber-physical systems

👉 Because these domains are not about code, they are about flows, signals, and interactions.

2.2 A natural fit for AI and modern pipelines

Modern systems are graph-based:

• neural networks
• data pipelines
• orchestration graphs

FROG aligns directly with this paradigm:

• nodes = computation
• edges = data movement

This creates a convergence:

AI graphs ≈ system graphs ≈ FROG programs

👉 Unlike traditional languages, FROG does not adapt to this model. It is native to it.

2.3 Lowering cognitive load for complex systems

Text-based code scales poorly in:

• multi-domain systems
• multidisciplinary teams
• long-lived industrial projects

Graphical dataflow provides:

• immediate structural understanding
• reduced mental parsing
• better collaboration between roles

This is particularly critical in:

• robotics teams (mechanical + software + control)
• industrial environments
• research labs

2.4 From prototyping to production — without rewriting

A common problem:

• prototype in Python
• rewrite in C++ / embedded

FROG aims to eliminate this gap:

• same model
• multiple backends
• deterministic execution

👉 This could unify:

• research
• prototyping
• industrial deployment

2.5 Toward a universal orchestration layer

The long-term vision is not just a language.

It is:

a universal layer to orchestrate computation across heterogeneous systems.

From:

• embedded sensors
• to AI models
• to cloud services

FROG positions itself as:

• a control plane for computation
• not just a programming language

Conclusion — A Bold Claim, But a Coherent One

Saying “FROG could be the best programming language” is not a statement about syntax.

It is a statement about:

• alignment with modern systems
• openness of the ecosystem
• architectural clarity
• long-term scalability

LabVIEW proved that graphical programming works.

FROG asks a bigger question:

What happens if we rebuild that idea, with the tools, expectations, and scale of the modern world?

FROG on GitHub: https://github.com/Graiphic/FROG