
Kitten – A statically typed, stack-based functional programming language - throwaway7645
http://kittenlang.org/
======
evincarofautumn
Author of Kitten here, happy to answer any questions.

The site is pretty far out of date—it describes an older version of the
language/compiler, so it’s better to check out the GitHub repo[1]. I figure
I’ll send a pre-release announcement to all the stargazers, when the time is
right.

One of my new year’s resolutions is to work on Kitten every week this year,
and release it before the end of the year. I’m also working on a short ebook
(“Programming with Kitten”) to serve as the standard tutorial.

I could really use help with all this—building and marketing a language is no
small task. If you’re interested in contributing, even if you’re not familiar
with Haskell or compilers, I’d be glad to help you get involved. :)

[1]:
[https://github.com/evincarofautumn/kitten](https://github.com/evincarofautumn/kitten)

~~~
nothrabannosir
_> I figure I’ll send a pre-release announcement to all the stargazers, when
the time is right._

Completely tangential: how do you send a message to all stargazers?

~~~
evincarofautumn
Using the GitHub API, you can get the list of stargazers for a repo, then get
the public email (if any) from each of their profiles.

------
mr_luc
Factor was a big name in 'modern stack-based languages,' but of course it's
pretty dynamic. I gave Factor a couple of dives a few years ago (after walking
through jonesforth prior) and it felt surprisingly complete/mature (except for
lack of package manager, of course).

Given its novelty, I think it'd be lovely if Kitten took a page from some
other languages and had a "QuickStart" or "Crash Course" that consisted of
side-by-side examples comparing Kitten to Forth or Factor, or even some other
more common language like Javascript. (Ie, elixir-lang does this comparison
with Erlang on its website, and it can be helpful).

~~~
evincarofautumn
Factor has been a good source of inspiration when designing Kitten, and I
would recommend it to people who want to try a concatenative language _now_.
Kitten is not usable for real-world stuff yet—but it’s getting close, and
eventually it should be a good alternative to Factor for those of us in the
static-types camp.

I’m working on an updated tutorial, and I’ll definitely include some
comparisons to other languages that people are likely to know, say JavaScript
and C. But I still need to find the right balance between illustrative
comparisons and standalone descriptions.

~~~
throwaway7645
I like the concept of Factor and talked to the author awhile back who isn't
actively involved anymore. My problem comes from the confusing doc and lack of
beginner materials. Just because I can write a simple app in an imperative or
OO context doesn't mean I can write functional nevermind efficient
concatenative code without help.

~~~
evincarofautumn
I do hang out with Slava occasionally, and he’s been helpful even if he’s not
that into concatenative programming anymore. For better or worse, the current
Factor maintainers are focused more on language internals than onboarding new
users. Concatenative/compositional programming does require a different way of
thinking, which I think is easy to learn but hard to teach.

~~~
throwaway7645
Understood. Is concatenative programming not especially good for what he is
currently interested in?

~~~
erichocean
Last I heard, Slava was working on the Linux kernel at Google.

~~~
evincarofautumn
He’s working on the Swift compiler at Apple these days.

~~~
throwaway7645
That's pretty prestigious.

------
mbrock
Kitten seems like a cool project. If I find some free time I might try to
contribute something.

Somewhat relatedly, I've been fantasizing about a mobile friendly editor for
source code, and it's struck me that concatenative languages can be nicely
edited by moving tokens around, which should be quite doable on a smartphone.

Static typing would make it even better, since the editor could show type
errors, predict input, and so on.

~~~
evincarofautumn
That is one of the goals of the project—the simple language structure and
static types should let you do some interesting things with program
visualisation and editing. Email me (username@gmail) if you’d like to chat
about it—maybe we could build something cool together. :)

------
phantom_oracle
\- What other programming-languages inspired this one?

\- What market is this language addressing? (ie. where should I "be using
it"?)

\- What is the bus-factor?

\- How difficult is/was it to write/design your own programming language?

~~~
evincarofautumn
Kitten is inspired mainly by:

• Systems languages (C, C++)

• Functional languages (Haskell, OCaml)

• Concatenative languages (Cat, Factor, Joy, Forth)

As a functional language without GC, it’s intended for mid-level applications
where you might ordinarily reach for C++, but it remains to be seen how people
might actually use it. It might be useful as a lightweight scripting language,
or for writing low-level embedded code that _feels_ high-level.

The bus factor is currently very bad—people have contributed here and there
over the years, but I’m pretty much the only core developer.

Building a language is as hard as you make it, basically. You can make a
pretty good toy language in a weekend, or you can go all-in and try to create
something innovative, elegant, versatile, stable, usable, and performant. That
takes years, and it’s a process of discovery with many false starts.

------
murbard2
I'm glad to see a successor for the defunct cat. I love the precision and
concision you can achieve with this style of programming.

Cat was a big inspiration in Michelson, another concatenative, statically
typed, functional programming language that we designed to run smart contract
in Tezos.

[http://www.tezos.com/language.txt](http://www.tezos.com/language.txt)

~~~
evincarofautumn
I hadn’t heard of it—that’s very interesting, thanks. :)

It would be nice to use GADTs for Kitten’s AST, but last time I tried, it made
inference complicated, and I never figured out a good way to encode Kitten’s
permission system in Haskell types. Even just annotating Kitten types with
their kinds (in the old compiler) was too cumbersome.

------
lacampbell
Parentheses, tuples, for loops... my first impression is it doesn't look very
concatenative.

~~~
evincarofautumn
The Levenshtein example isn’t the best. It’s also using an older version of
the language with things like mixfix operators (“from()to(){}”) which have
since been removed.

Anyway, Kitten is concatenative at the term level (all terms denote functions,
juxtaposition is composition) but not the token level as in Forth (e.g., “{”
and “}” are not meaningful words on their own).

~~~
lacampbell
Interesting, I am curious as to why you are concatenative at the term level
only. Is it trying to make syntax more palatable to ALGOL family programmers?

PS: I loved your "why concatenative programming matters" article

~~~
astrobe_
Sorry but I have to be negative here because I love Forth.

People tried to make Lisp/Scheme less 'prefix', and it didn't fly. People
tried to make Forth less 'postfix', and it didn't fly.

The whole point of concatenative languages is the simple syntax and
implementation.

I wrote a Forth dialect in C - actually I wrote many over the years because
it's a refinement and adaptation process, but I'll talk about the one I'm
currently using. Its core is a little less than 2K SLOC that compile into a
~30Kb (yes, kilobytes) (~60Kb for Windows 32bits) . It uses a very
straightforward direct threaded scheme - something like ( _ip++)() - but that
's plenty fast already (think Lua-fast).

It's easy to modify because, well, I wrote it from top to bottom. At some
point I wish I had separators for number and binary numbers. In an hour or so
I could write things like 0b1010_1001. At one point I was tired to write
_"test.4" load*. I hacked the interpreter so that when it sees a word that
ends with ".4" it tries to load the file with that name. Very handy. At some
point I wish I could embed my interpreter into a large embedded application to
help with debugging. No problem either.

It's easy to extend. Need more accurate time stamps? Here you go:

    
    
        static void p_getms(void)
        {
    	struct timeval t;
    	gettimeofday(&t, NULL);
    	push(t.tv_usec/1000);
    	push(t.tv_sec);
        }
    

And then you add the function in an array to "register" it, like you do in
Lua.

I can write bindings to libraries almost on-the-fly thanks to the braindead
API which consists mainly in push() and pop(). No FFI required. It's also
trivial to translate a piece of code from Forth to C when you need speed. I
think it could even be automated.

THIS is what Forth is really about. I don't see the point of having people
"think concatenative" if they don't have all this in return.

You want static typing? I can understand, because Forth is quite unforgiving
and will segfault if you make a mistake and that can be annoying. Actually,
when I started to write the interpreter I'm currently using, my plan was to
write some kind of "linter" to help with that. However as an embedded systems
programmer I'm pretty used to printf() debugging (it might be a bad habit) and
Forth is pretty good at that because you can invoke a REPL very easily. So I
have yet to find the motivation to write that Linter.

~~~
lacampbell
Clojure syntax looks like a cross between common lisp and javascript, but it
manages to be the most popular lisp around by a country mile. On the one hand
I find it distasteful, on the other hand it hasn't seemed to hurt adoption. I
don't know if it drove adoption though - it's probably more likely due to the
fact the inventor of the language is a charismatic and prolific speaker. But I
digress...

I kind of agree with you. I don't think "softening" the syntax of a
concatenative languages is going to help much, and is more likely to drive
away the kind of PL dabblers who are interested in concatenative languages in
the first place. The vast majority of programmers will never try anything that
doesn't resemble ALGOL at least a bit. It's a lost cause to try and reel them
in.

IMO, the best way for nice languages to thrive is to be simple enough that
it's easy for a small number of people to maintain, and powerful enough that
the implementation and standard library can be constructed in as few LOC as
possible to minimize bugs. Being able to attach itself to an existing large
ecosystem with a minimum of fuss (ie, embedable in C or Java interop) also
seems to be a great trojan horse.

------
innocentoldguy
The REPL stack for doing calculations looks interesting (you can find it in
the tutorial link:
[http://kittenlang.org/tutorial/](http://kittenlang.org/tutorial/)). I'll have
to try it out though to see how well I like it.

