Design Philosophy
The design of Felico is guided by three core principles, in order of priority:
1. Fun First
Programming should be fun. This might seem obvious, but it’s often overlooked in language design. Felico takes this seriously:
- Whimsical elements: The name “Felico” (combining “feline” and “code”) and the cat emoji mascots 😺 😻 remind us not to take ourselves too seriously.
- Rapid experimentation: Fast feedback loops make trying new ideas enjoyable.
- Clear error messages: Debugging shouldn’t be frustrating—it should feel like solving a puzzle with helpful hints.
Fun doesn’t mean sacrificing power or correctness. It means making the journey of writing code enjoyable.
2. Friendly by Design
A programming language isn’t just syntax and semantics—it’s an ecosystem and community:
- Welcoming error messages: Errors should teach, not scold.
- Inclusive community: All skill levels welcome, all ideas considered.
- Assuming good intentions: We all make mistakes, and that’s how we learn.
A friendly environment naturally leads to more fun, creating a virtuous cycle.
3. Fast When It Matters
Speed is important, but it’s the third priority for good reason:
- Fast feedback loops: Quick compilation and testing cycles respect your time.
- Responsive tooling: IDE integration, formatters, and linters should be instant.
- Runtime performance: Efficient execution, but not at the expense of fun or friendliness.
Fast feedback makes programming more fun and more friendly by reducing friction.
Influences
Felico draws inspiration from:
- Rust: Memory safety, ownership concepts, friendly error messages
- Zig: Simplicity, compile-time execution, explicit control
- TypeScript: Gradual typing, developer experience
- Elm: Pure functions, helpful errors, no runtime exceptions
What Felico Avoids
Some common language features are intentionally excluded:
Function Coloring
Async/await often creates “colored functions” where async and sync functions can’t easily interoperate. Felico aims to handle effects without splitting the world into two incompatible halves.
Implementation Inheritance
Classical OOP inheritance often leads to rigid hierarchies and tight coupling. Felico favors composition and traits over inheritance.
Experimental Nature
Felico is explicitly an experiment. This means:
- Breaking changes are expected: We’re exploring, not maintaining compatibility.
- Ideas are tested: Some will work, some won’t—that’s the point.
- Community input matters: Your feedback shapes the direction.
The goal isn’t to create the “perfect” language, but to learn what works and what doesn’t in service of our three core values: Fun, Friendly, and Fast.