Software development is fundamentally about transformations.

When we focus on transformations and relationships rather than just data, we unlock systematic approaches to solving problems. Category Theory provides the mathematical framework for understanding these transformations, and Forthic makes that framework practical for real-world applications.

// Imperative, verbose, hard to modify
function processOrderPipeline(order) {
  const validated = validateOrder(order);
  if (!validated.isValid) {
    throw new Error(validated.error);
  }

  const withTax = calculateTax(validated.order);
  const withDiscounts = applyDiscounts(withTax);
  const result = submitToPayment(withDiscounts);

  if (result.status === 'success') {
    return result.data;
  } else {
    throw new Error(result.error);
  }
}

Problems:

• Verbose boilerplate obscures intent
• Hard to see the transformation pipeline
• Difficult to compose or reuse parts
• Mixing control flow with business logic
• Variables accumulate as you go

Transformation-focused with composition:

["orders"] USE-MODULES

: PROCESS_ORDER   VALIDATE CALCULATE_TAX APPLY_DISCOUNTS SUBMIT_TO_PAYMENT;

current_order PROCESS_ORDER

Benefits:

• Clear transformation pipeline (reads left to right)
• Trivial to compose (just concatenate words)
• Trivial to abstract (define new words)
• No variable management (stack handles data flow)
• Intent is explicit

In Category Theory:

• Objects are types/data structures
• Morphisms are transformations between objects
• Composition is the fundamental operation

Forthic embodies this:

• Stack states are objects
• Words are morphisms (transformations)
• Concatenation is composition

# Each word is a morphism (transformation)
data                    # Object A (stack state)
  TRANSFORM-1           # Morphism A → B
  TRANSFORM-2           # Morphism B → C
  TRANSFORM-3           # Morphism C → D
                       # Result: Composition A → D

Composition has properties:

• Associativity: (A ∘ B) ∘ C = A ∘ (B ∘ C)
• Identity: There exists an identity morphism that does nothing
• Inverses: Some morphisms have inverses that "undo" them. If you have an inverse, you have the solution

These properties give you systematic ways to think about problems and how to solve them:

Forthic isn't theoretical—it powered nearly 1,000 engineering reports and utilities at LinkedIn.

What we learned:

1. Rapid Development

   • Building new apps became 10x faster
   • Most apps were 50-200 lines of Forthic
   • Composition meant reusing transformations everywhere

2. Maintainability

   • Changes were localized to specific words
   • Composition made refactoring safe
   • Code directly expressed business intent

3. Onboarding

   • Non engineers could tweak Forthic code
   • Stack-based thinking clicked quickly
   • Building on existing words felt natural

4. Domain-Specific Languages

   • Each domain built its own vocabulary
   • Teams created modules for their specific needs
   • Forthic became the abstraction

• Built-in branching (if/else/switch)
• Built-in loops (for/while)
• Built-in I/O
• Built-in networking
• Built-in database access

Because your runtime already has these things, and probably better than Forthic could provide.

The Forthic philosophy:

• Stay high level and focus on straight lines of transformation
• Focus on composition
• Leverage your runtime's strengths
• Extend with exactly what your domain needs
• Don't lock users into Forthic-specific patterns

You have:

• Thousands of lines of existing code
• Complex business logic in Java/JavaScript/Python/.NET
• Systems that work but are hard to compose
• Code that's difficult to abstract over

You don't want to:

• Rewrite everything in a new language
• Abandon your existing investments
• Lose domain knowledge encoded in legacy systems

Wrap, don't rewrite:

// Your existing legacy code (unchanged)
class LegacyOrderSystem {
  validateOrder(order: Order): ValidationResult { ... }
  calculateShipping(order: Order, address: Address): number { ... }
  applyLoyaltyPoints(order: Order, customerId: string): Order { ... }
  // ... hundreds more methods
}

// Wrap it in a Forthic module (minutes of work)
export class OrdersModule extends DecoratedModule {
  private legacy = new LegacyOrderSystem();

  @Word("( order:Order -- result:ValidationResult )")
  async VALIDATE(order: Order) {
    return this.legacy.validateOrder(order);
  }

  @Word("( order:Order address:Address -- shipping:number )")
  async CALCULATE_SHIPPING(order: Order, address: Address) {
    return this.legacy.calculateShipping(order, address);
  }

  // ... wrap more methods as needed
}

Now compose it:

["orders" "customers" "inventory"] USE_MODULES

: PROCESS_NEW_ORDER   VALIDATE CALCULATE_SHIPPING APPLY_LOYALTY_POINTS RESERVE_ITEMS SUBMIT;

What you've achieved:

• Legacy code still works (unchanged)
• Now it's composable (wrapped in modules)
• Built higher-level abstractions (PROCESS_NEW_ORDER)
• Easy to modify pipeline (just edit word sequence to remove/insert new steps)

Forth (the inspiration):

• Low-level (memory cells, bytes)
• Minimal abstraction (closer to assembly)
• Amazing for embedded systems
• Less suitable for modern app development

Forthic (modern evolution):

• High-level (arrays, records, dates)
• Rich abstractions (modules, decorators)
• Designed for application development
• Leverages runtime's type system

What Forthic keeps from Forth:

• Stack-based execution
• Concatenative composition
• Word-based vocabulary
• Elegance and simplicity

What Forthic adds:

• Modern data types (from your runtime)
• Easy module creation (@Word decorators)
• Standard library (array, record, string, etc.)
• Multi-runtime architecture

• AI can learn word vocabulary (finite set)
• Stack operations are deterministic (predictable)
• Composition is systematic (Category Theory)
• Errors are catchable (type checking possible)

Token efficiency matters:

• Forthic expressions are 10x more concise than JSON protocols
• More context fits in prompt windows
• Faster inference, lower costs

You're wrapping existing code:

• Have legacy systems that need to compose
• Want to build DSLs over existing APIs
• Need rapid prototyping with existing libraries
• Building tools that orchestrate multiple systems

You value composition:

• Think in transformations, not just data structures
• Want trivial abstraction and composition
• Appreciate mathematical foundations
• Enjoy elegant, concise code

You're building AI applications:

• Need systematic approach to tool composition
• Want token-efficient AI integration
• Building agents that compose behaviors
• Integrating AI with legacy systems

You need a complete general-purpose language:

• Forthic intentionally relies on host runtime
• Not designed to replace JavaScript/Python/Java

You're unfamiliar with stack-based thinking:

• There's a learning curve
• Different mental model than OOP/functional
• (But once it clicks, it's powerful!)

Ready to try categorical coding?

1. Read the Getting Started Guide - Install and run your first Forthic
2. Build a module - Wrap some of your existing code
3. Compose transformations - See how they naturally combine
4. Think categorically - Ask "what's the inverse?" when solving problems

Join the mission:

• ⭐ Star the repos if this resonates
• 🎓 Build something and share it
• 💬 Discuss ideas and patterns
• 🤝 Contribute modules and documentation

Category Theory has been around for 80+ years.

It's not a trend or a fad—it's mathematical foundation for reasoning about composition and transformation.

Forthic makes those ideas practical for modern software development.

• Thinking in transformations
• Systematic composition
• Leveraging existing code
• Building higher-level abstractions

That's why Forthic exists.