Many years from now, when power users, researchers, and historians look at this article, they will see how it all started and glimpse the vision behind our work.
Ah, vision - a fascinating subject, and a quality not appreciated by all. Like the ability to dream, to imagine, and to dwell in the realm of mathematics and technicality. For imaginative minds, it's dangerous to wander too far; without standing on solid ground, one can hardly make real progress. Often, it pays to be hands-on.
Divooka is (or is becoming) a complete, general-purpose, high-level, multi-paradigm, flexibly typed, modern visual programming language/system, complete with package management, standard libraries, application frameworks, graph editors, IDE, CLI executor, code generator & compiler, derived frontend apps, examples, documentation, and accompanying tutorials and training materials. We've achieved the majority of this already, so it's not an exaggeration to list them now. What's more, there are still ideas I haven't put into words.
It's hard to do one thing well, and to achieve all of this with limited resources, we need a good strategy. Of course, the strategy itself is a secret I won't share - it's fairly simple, really, but requires determination and execution power. After a year since incorporation last July, it's useful to review and recap what we've done and where we are.
In this article, I'll focus on the period from January to August 2025, but to give a complete picture, I find it instructive to look back and highlight outcomes from last year and key lessons learned.
Early 2024
2024 was about the modernized inception of what Divooka is today.
Neo was reviewed a third time, and we managed to trim down most legacy code. It was time to think more broadly about the concept of "general-purpose visual programming," rather than just a demonstration for data analytics. A new repository was created for modern development. Gospel was conceived.
Talks with investors and prospective entrepreneurs mostly confirmed that this subject is hard, and we learned there are countless low-code platforms in China. That is good.
A disagreement with a co-creator helped me settle the fact that we would definitely go desktop-first and worry about the web later.
The conception of Quadrinity and the flexible office software framework inspired me to quit my job and move forward.
July–Sep 2024
During initial incorporation, development was highly focused, and Divooka, though very simplistic, was a well-defined, easy-to-perceive single tool with only a handful of nodes. With Haopu's help on plotting, it quickly looked like a handy little utility for data analytics - a subject matter we should continue to explore and focus on in the future.
At the same time, to prepare for public preview and an angel investor meeting, I spent a month making prototypes for many potential application areas, including experimental libraries and web use. Due to lack of sophisticated integration and completeness, I doubt these prototypes made as strong an impression as I hoped.
On the marketing side, the concept of a case competition was pitched during this time, but it never materialized later in 2024 due to slow progress on software completion and the dashboard library.
Sep–Dec 2024
With the promise of investor funding, I decided to expand operations and start hiring contractors to work on various aspects of the overall Divooka platform, including GUI design, website improvements, and preparation for first practical use. In a previous article, I mentioned that end users were unlikely to use Divooka directly during initial adoption. To elaborate:
- Lack of comprehensive DSL libraries at this stage.
- Overall complexity and learning curve as a general-purpose programming language.
While we could have focused on DSL, the second point made it unlikely to gain traction (given how unknown we were) and not commercially feasible any time soon. Thus, we needed more specific, tool-like, highly focused, direct end-user GUI applications.
For that reason, we published Fantasy Planet Painter. We also planned to publish Arcadia, but timeline issues prevented it.
It was during this period that we conceived what was previously known as "ZFA," while "fighting" for the trademark of "Zora" in Canada. Due to delays with investment funding, personnel management, and other corporate matters, we didn't make significant progress on the modern Morpheus framework or ZFA at that time.
In conclusion, during these busy four months, there was not much I would call technical progress. Most efforts were miscellaneous but time-consuming. I also learned it was better to take more matters into my own hands.
Jan–Aug 2025
January to August has been much more fruitful and productive, despite major distractions in January, May, and July. With help from Aaron, Allan, and ChatGPT - and without the communication burden of contractors and external collaborators - progress has been slow but steady. More importantly, I've had time to investigate highly technical matters and build foundational work.
The Web Summit in May and internal training from April to July helped us greatly polish the Neo graph editor, stabilize Neo's internal serialization format, and establish Divooka for general-purpose use.
Ecosystem-wise, I've done plenty of investigation and prototype work on Python integration, build automation, code refactoring, and preliminary work on online services.
There has been extensive work on Neo and Neo-first features, including general GUI improvements, bug fixes, plugin framework enhancements, subgraph work, generics, lambda support, multilingual framework setup, procedural context, and other experimental work. Related to this is the improved Neo serialization format, which is becoming more robust and stable. We haven't yet worked on package management. Although we are trying to make it DiDS-conformant, it's still far from achieving a single final format.
DSL-wise, there has been initial work on Ol'ista, Glaze!, Slide Present, and Novella. Many utilities were also created for ChatGPT and GenAI services, including interfaces for Nvidia NIM, ComfyUI, and Hugging Face inference services. Different users have different demands, and it's hard to focus on any specific library without a pilot project. While we do have internal pilot projects, they are large in scope and still require groundwork, so Divooka hasn't yet played a significant role. I do want to seek external collaboration on this - but at the moment resources are constrained.
On the plotting front, as of early August, Aaron has made significant progress on the mid-level plotting API, making Divooka's plotting library almost "self-sustainable," able to meet a wide range of demands.
Although data analytics is arguably not our only focus, use case investigations have improved in-memory DB handling, refactoring, and preliminary libraries for PostgreSQL ingestion. One architectural challenge is expression interpretation: we decided long ago that, at least for data analytics, it's not efficient to rely entirely on node interfaces - some coding is desirable. The main focus is SQL snippets through our in-memory DB library, though at times LINQ expressions and in-place C# scripting have been useful. However, concerns with the latter are robustness, error tolerance, predictability, increased distribution size, and future program export compatibility.
The data analytics API also faces the challenge of whether to focus on OOP or tabular data as intermediate formats. Sometimes one is more convenient than the other, which increases development costs to maintain both. Eventually, we will likely keep both but prefer exposing the tabular format in Divooka.
A more complete picture of "data analytics" in Divooka would extend into data science and machine learning. There's plenty of research to do here, including choosing a foundational library, gradually building our own infrastructure, and developing graph-friendly, visual-programming-first APIs. This will have to wait until next year.
Summary
The most visible outcome is that Neo is receiving significant updates. On the programming language front, Divooka's function libraries are growing as the language becomes more capable, flexible, and production-ready. Once we start working on package management, it will be more prepared for practical day-to-day use. However, package management requires a fully functional online service first.
Meanwhile, we are actively exploring more "direct-user-facing" applications, which I'll discuss in future posts.
We could use a lot of help on DSL work, and that's the plan as the foundations solidify and architectural decisions become clearer.
References
Wiki Entries on related subjects:
DevLogs on Divooka/Neo progress:
- DevLog 2025801: Procedural Context Type
- DevLog 20250711: Flappy Bird in Divooka! (Sneak Peak)
- DevLog 20250710: Generics in Divooka
- DevLog 20250708: Procedural Context Visual Debugger in Divooka
- DevLog 20250619: Modularization Improvements
- DevLog 20250613: Ol'ista Web Framework
- DevLog 20250610: Plotting in Divooka
- DevLog 20250510 Dealing with Lambda
- Progress Share 20250509: Graph Local Lambda Calculus in Divooka
The Introductory to Visual Programming with Divooka Textbook:
- Access it online here!
Additional references:
Glossary
- DSL: Domain-specific Library
- DiDS: Divooka Document Specification
- DiOS: Divooka Open Standards
- Gospel: The new, revived, modern incarnation of Parcel, gateway into Divooka; Now a new graph editor frontend for Divooka
- Neo: The Windows graph editor for Divooka
- Morpheus: The cross-platform GUI framework and graph editor architecture for Divooka
- Quadrinity: A way to perceive office suite software as a single framework consisting of multiple views, like Blender's workspaces
- ZFA: Zora Frontier Architecture
Top comments (0)