Compyutinator vs Resolvinator Type Systems

Overview

This Livebook compares the type systems between Compyutinator (Python) and Resolvinator (Elixir), highlighting their differences and similarities in handling serializable data.

Setup

Mix.install([
  {:kino, "~> 0.9"},
  {:vega_lite, "~> 0.1.6"},
  {:kino_vega_lite, "~> 0.1.7"}
])

Core Data Types Comparison

Compyutinator Core Types (Python)

classDiagram
    class RiskData {
        +str name
        +str description
        +float severity
        +List[str] tags
        +Dict metadata
    }
    
    class SystemState {
        +str status
        +Dict[str, DeviceInfo] devices
        +List[WingStatus] wings
        +Dict settings
    }
    
    class WingStatus {
        +str name
        +WingType type
        +bool active
        +Dict metadata
    }
    
    class DeviceInfo {
        +str id
        +str name
        +str type
        +bool connected
        +Dict config
    }

    SystemState --> WingStatus
    SystemState --> DeviceInfo

Key Differences from Resolvinator

1. Type System Approach

   # Compyutinator (Python)
   @dataclass
   class RiskData:
    name: str
    description: str
    severity: float
    tags: List[str]
    metadata: Dict[str, Any]
   
   # Resolvinator (Elixir)
   defmodule Risk do
   use Ecto.Schema
   
   schema "risks" do
    field :name, :string
    field :description, :string
    field :severity, :float
    field :tags, {:array, :string}
    field :metadata, :map
   end
   end

2. Serialization Patterns

# Compyutinator - Dataclass with JSON serialization
@dataclass
class ConfigData:
    name: str
    version: str
    settings: Dict[str, Any]
    
    def to_json(self):
        return json.dumps(asdict(self))
        
    @classmethod
    def from_json(cls, data: str):
        return cls(**json.loads(data))

# Resolvinator - Schema with built-in serialization
defmodule Config do
  use Ecto.Schema
  
  schema "configs" do
    field :name, :string
    field :version, :string
    field :settings, :map
  end
  
  def changeset(config, attrs) do
    config
    |> cast(attrs, [:name, :version, :settings])
    |> validate_required([:name, :version])
  end
end

Core System Components

Compyutinator Components

compyutinator_components = [
  %{
    type: "Core",
    components: [
      "CCCore - Main system coordinator",
      "SymbolManager - Symbol tracking and analysis",
      "RiskManager - Risk assessment and handling",
      "LSPManager - Language Server Protocol handling"
    ]
  },
  %{
    type: "UI",
    components: [
      "CursorOverlay - Visual cursor management",
      "DownloadManagerUI - Download interface",
      "FlowEditorDialog - Flow editing interface"
    ]
  },
  %{
    type: "Data",
    components: [
      "ConfigData - Configuration management",
      "RiskData - Risk information",
      "SystemState - System status tracking",
      "DeviceInfo - Device management"
    ]
  }
]

Key Type System Differences

1. Schema Definition

   • Compyutinator: Python dataclasses with type hints
   • Resolvinator: Ecto schemas with field definitions

2. Validation

   • Compyutinator: Runtime type checking, custom validators
   • Resolvinator: Changeset-based validation, compile-time checks

3. Persistence

   • Compyutinator: JSON/SQLite serialization
   • Resolvinator: Ecto.Repo with PostgreSQL

4. Immutability

   • Compyutinator: Mutable by default
   • Resolvinator: Immutable by default

Data Flow Visualization

graph TD
    A[Compyutinator Data] -->|Python Dataclass| B[JSON]
    B -->|Serialization| C[Storage]
    D[Resolvinator Data] -->|Ecto Schema| E[Changeset]
    E -->|Validation| F[Database]

Type System Features Comparison

features = [
  %{feature: "Static Typing", compyutinator: "Optional", resolvinator: "Dynamic"},
  %{feature: "Schema Validation", compyutinator: "Runtime", resolvinator: "Compile-time"},
  %{feature: "Persistence", compyutinator: "Manual", resolvinator: "Built-in"},
  %{feature: "Immutability", compyutinator: "Optional", resolvinator: "Default"},
  %{feature: "Serialization", compyutinator: "Custom", resolvinator: "Built-in"}
]

Vl.new(width: 400, height: 200)
|> Vl.data_from_values(features)
|> Vl.mark(:point)
|> Vl.encode_field(:x, "feature", type: :nominal)
|> Vl.encode_field(:y, "compyutinator", type: :nominal)
|> Vl.encode_field(:color, "resolvinator", type: :nominal)

Unique Aspects

Compyutinator

1. Type Hints

   • Optional static typing
   • Runtime type checking
   • Dataclass decorators

2. Memory Management

   • Reference counting
   • Explicit cleanup in some cases
   • Qt object lifecycle management

3. Serialization

   • Custom JSON encoders/decoders
   • SQLite integration
   • Binary data handling

Resolvinator

1. Schema System

   • Ecto schemas
   • Changesets for validation
   • Database integration

2. Memory Management

   • Immutable data structures
   • Garbage collection
   • Process-based isolation

3. Serialization

   • Built-in JSON encoding
   • Protocol-based serialization
   • Binary protocol support

Conclusion

The key differences between Compyutinator and Resolvinator’s type systems reflect their underlying language paradigms:

1. Compyutinator (Python)

   • More imperative approach
   • Optional static typing
   • Mutable data structures
   • Custom serialization

2. Resolvinator (Elixir)

   • Functional approach
   • Dynamic typing with schemas
   • Immutable data structures
   • Built-in serialization

These differences influence how each system handles data validation, persistence, and transformation, with each approach having its own strengths for different use cases.