Text-Based Pseudo Code for Divooka Pipelines

Purpose

The text-based pseudo code format is used to express Divooka pipelines in a concise, readable, and implementation-agnostic way. It serves three primary goals:

• Clarity — communicate data flow without syntactic noise
• Documentation-first design — examples remain stable even as syntax evolves
• Conceptual alignment — emphasize transformations, not control flow

This format is not executable. It is a semantic representation of pipeline logic intended for documentation, design discussions, and onboarding. It's also not intended to match directly to actual Divooka programs.

Such pipelines are more specifically applicable to dataflow processing contexts. This document serves as a guidance for community technical discussion on related topics.

Core Model

Divooka pipelines are modeled as:

data source → transformations → output

Each step:

• receives a collection or stream
• applies a transformation
• returns a new collection or stream

Syntax Overview

1. Assignment

Pipelines typically begin with a named binding:

images = load("input/*.png")

• Left-hand side: identifier
• Right-hand side: data source or pipeline

2. Pipeline Operator

The pipeline operator (|>) represents left-to-right data flow:

processed = images
  |> resize(width=1024)
  |> convert("webp")

Equivalent conceptual model:

convert(resize(images))

3. Transformations

Transformations are expressed as function-like operations:

filter(price < 100)
map(name, price)
group_by(category)
count()

They are:

• stateless (conceptually)
• chainable
• order-dependent

4. Data Sources

Common entry points:

load("file.csv")
fetch("https://api.com/data")
stream("events")

These represent external or initial data inputs.

5. Sinks (Outputs)

Pipelines terminate in side effects or outputs:

save(data, "output.json")
print(result)

Or inline:

data |> transform() |> save("out.json")

6. Inline Expressions

Simple expressions may appear inside transformations:

filter(age > 18)
map(total = price * quantity)

These are declarative and avoid imperative constructs.

Canonical Pattern

A typical Divooka pipeline follows:

result = source
  |> transform_1(...)
  |> transform_2(...)
  |> transform_n(...)

save(result, destination)

Design Principles

Declarative Over Imperative

No loops, mutation, or control flow constructs are shown.

// Avoid
for item in items:
  ...

// Prefer
items |> map(...)

Linear Readability

Pipelines are read top-to-bottom, reflecting execution flow.

Minimal Syntax

Only essential constructs are represented:

• assignment
• pipeline operator
• transformations

Data-Centric Thinking

Focus remains on what happens to data, not how execution is managed.

Applicability

This pseudo code format is best suited for:

Documentation

• explaining features
• illustrating common workflows
• providing examples without locking syntax

Design & Prototyping

• sketching pipelines before implementation
• discussing transformations and composition

Onboarding

• introducing users to the Divooka mental model
• reducing cognitive overhead of real syntax

Non-Goals

This format intentionally omits:

• error handling
• concurrency semantics
• type annotations
• control flow (if/else, loops)
• performance considerations

These belong to the actual implementation layer, not the conceptual model.

Example (End-to-End)

data = load("orders.csv")

summary = data
  |> filter(status == "completed")
  |> map(total = price * quantity)
  |> group_by(customer_id)
  |> sum(total)

save(summary, "customer_totals.json")

This example demonstrates:

• ingestion
• transformation chaining
• aggregation
• output

Summary

The text-based pseudo code format provides a stable, expressive layer for representing Divooka pipelines. It abstracts away implementation details while preserving the essential structure of data-driven workflows.

Throughout the documentation, we will be using this format extensively for discussing various functionalities and examples of Divooka.