FAQ

Here are some questions that people often ask me about Kitten.

Why a new language?

Primarily, I wanted to see how far I could take this idea. I have always loved programming languages and developer tools, because they let me multiply others’ productivity. And there are many reasons to create a language—for research, for fun, to learn how languages work. Most languages will not attain general popularity, though their ideas may be incorporated into other mainstream languages.

As for why this idea specifically—I want a simple language that makes low-level programming feel high-level, with a predictable performance model and good interoperation with C, that uses static types to make my programs faster and more correct. In my estimation, the concatenative paradigm is the best foundation on which to build that language. And these ideas won’t work in other languages, because you can’t get the benefits of concatenative programming in a language that was not designed for it.

Why is it called Kitten?

It’s a small concatenative language. It’s also intended to be a practical successor to Cat, which was the first statically typed concatenative language.

Is it compiled or interpreted?

There is an interpreter written in Haskell, and a work-in-progress native code compiler. This enables you to try code interactively in the interpreter, then compile it to run efficiently.

Is it stable?

No. Kitten is under active development, and the syntax and standard libraries undergo periodic changes as the language matures. It is possible to build some practical software with the language, but there will continue to be breaking changes for a while.

Why functional?

I started playing around with Haskell in college for personal projects, and immediately fell in love with the ability to quickly write and refactor robust software using expressive, reusable, type-safe abstractions. Haskell is fast, but few programmers know how to write high-performance code in it. So I wanted to take that expressive power and bring it to the world of low-level programming, using a performance model that many programmers already know.

Why stack-based?

While doing programming language research in college, I stumbled across the concatenative programming paradigm. Functional programming had already given me an appreciation for the power of composition, and I realized how much more refactoring power you get from a language where composition is the default way to build programs. Stack-based programming is simply a natural way to enable that.

In addition, stack-based resource management has predictable runtime performance behavior: when you drop a value from the stack, it gets deallocated, no garbage collector required. That’s important for games and services where unpredictable GC pauses are not acceptable. In practice, it is more efficient to use a GC for some things, but this should be opt-in.