The Arch Linux of Programming Languages
Just as Arch Linux has become the choice of developers who value simplicity, transparency, and control over their systems, Quartz embodies these same principles for programming languages.
"The KISS principle (Keep It Simple, Stupid) is the guiding philosophy behind Arch Linux. It focuses on elegance, code correctness, minimalism, and simplicity, and expects the user to be willing to make some effort to understand the system's operation."
— Arch Linux Wiki
Quartz takes this philosophy and applies it to language design. We believe that a programming language should be a transparent tool, not a black box that makes decisions for you.
Our Core Principles
🎯 Simplicity Over Convenience
Many languages pride themselves on "magic" — implicit conversions, hidden behavior, framework conventions that "just work." We reject this approach.
In Quartz, what you write is what runs. There are no hidden initializers, no implicit type coercions, no framework-imposed conventions. If something happens, you wrote it to happen.
```quartz
// No magic. No surprises.
let x = 5; // x is an int
let y = 5.0; // y is a double
// They're different types. No implicit conversion.
```
🔍 Transparency Over Abstraction
Abstraction is valuable, but not when it hides what's actually happening. Quartz gives you full visibility into the runtime.
- Inspect bytecode: See exactly what the compiler produces
- Trace execution: Understand the flow of your program
- Read the source: The implementation is clean, documented, and designed to teach
```bash
# Compile and inspect bytecode
./quartz --compile -o program.qzb program.qz
./quartz --dump-qzb-meta program.qzb
```
⚙️ Control Over Defaults
Your runtime, your rules. Quartz doesn't decide what standard library you need or what optimizations to apply. You choose.
- Modular standard library: Import only what you use
- Native extensions: Extend the language in C++ when you need performance
- Execution modes: Interpret for development, compile for production
📦 Minimalism Over Features
We resist the urge to add features just because other languages have them. Every feature must justify its complexity cost.
The core language is small. The runtime is lean. Dependencies are few. But from these simple pieces, you can build anything.
```quartz
// Small core, big possibilities
import system.io as io;
import system.math as math;
// That's all you need to start building.
```
Who Is Quartz For?
🔧 Tinkerers
You want to understand how things work, not just use them. You enjoy reading source code and aren't afraid to debug at a low level.
🎓 Learners
You're learning about language implementation, interpreters, compilers, or bytecode VMs. Quartz's codebase is designed to teach.
⚡ Minimalists
You're tired of bloated runtimes, massive frameworks, and npm installing the entire internet. You want a tool that does one thing well.
🛠️ Embeddders
You need a scripting language for your C++ application. Quartz is small, predictable, and easy to integrate.
Who Is Quartz NOT For?
We believe in honesty. Quartz isn't for everyone:
- If you need the largest ecosystem of packages and libraries
- If you prefer frameworks that make decisions for you
- If you want the most mature, production-battle-tested language
- If you need extensive enterprise support
For these use cases, more established languages like Python, Java, or Go may serve you better. We're okay with that.
Design Decisions
Why C-Like Syntax?
Familiarity reduces cognitive load. If you've used C, Java, JavaScript, or C++, you can read Quartz code immediately. We don't believe in syntax novelty for its own sake.
Why Both Interpreter and Bytecode VM?
Different tools for different jobs. The interpreter is great for development — fast startup, easy debugging. The bytecode VM is for production — better performance, distributable binaries.
Why Native Extensions?
Some things are better done in C++. Instead of trying to make everything possible in pure Quartz (which leads to bloat), we make it easy to escape to native code when needed.
Why Optional Type Annotations?
Types are documentation that the compiler can check. We make them optional because scripting should be quick, but we recommend them for larger codebases.
The Path Forward
Quartz is a living project. We're committed to:
- Stability: No breaking changes without good reason
- Documentation: Code and behavior that explains itself
- Community: Welcoming contributions and discussions
- Honesty: Being clear about what Quartz is and isn't
We're not trying to be the next Python or JavaScript. We're trying to be the best Quartz we can be — a small, brave language for developers who appreciate simplicity.