Divooka Design Principles
Divooka is a "flexibly-typed multi/mixed-paradigm AI-enabled all-in-one-stack modern 4th-generation all-platform programming system":
- All in one stack: refers to the programming model, and the fact that we rely on specialized graphical frontends, like doc and present for specialized "framework" and "plug-in" logic.
- Modern: No legacy shit, modern C#, fully context aware node suggestion, automatic code gen for high level application.
- Programming System: It integrates IDE, compiler, editor, application frameworks and frontend apps.
- Divooka is not a single program but a system of interoperated components that can be reused here and there for custom applications. A good example is the Stewer runtime whose functions are seem similarly in many places.
As we strive to be modern and provision DSLs when appropriate. A lot of design decisions are ultimately driven by available resources - utilizing existing formats and libraries facilitate the development process (e.g. YAML, SkiaSharp), even though existing standardization not always suit Divooka the best. In general, the goal is to provide an isolation layer so library specific implementation details (e.g. dependency on SkiaSharp) are hidden from the user, and the users only need to become familiar with Divooka native APIs.
Configuration Style
Prefer strongly typed and explicit values on each function - instead of state based configuration as in traditional C style procedural APIs, which may incur small overhead with certain graphics API due to resource updates cross CPU-GPU border but generally is easier to use from high-level scripting perspective. See blog for an overview for now.
Graph-Native API
Per configuration style (as mentioned above) and the high-level nature of usage, we prefer flat, explicit, self-contained nodes - from development perspective, this means expose things as static in C#.
A recurring pattern in Divooka and in how we approach things and solve problems is there is always three different levels one can approach things First, high level; Second, mid level; Third, low level. A good example is the GUI application frameworks and Data Grid operations.
Fundamentally and practically, to become good at solving problems is to be very familiar with all kinds of data structures and tools available, especially those that come with the platform, so as to avoid doing repetitive work.
Others
Notice specific libraries and programs may have their own design principles.
Below is an exuahstive reference to standard libraries that have specific design styles:
- Pure
- Data Grid library
See respective documentations or design notes for details.