About Til

It’s been a very interesting and (mostly) pleasant experience to develop yet another programming language and I believe more programmers should try that at least once in life. It’s enlightening.

There are plenty of motivations to create a new language. Some people are unhappy with the current options and may want to try their own take on the subject. Some do that for fun. Many may think being the creator of a programming language will open doors to a bright career. And others just want to learn more.

I just want to learn more and, yes, I am learning. I now know D and some of its ecosystem much better than before, I understand a lot of decisions from other languages I thought were weird (like “connecting” into processes when using Erlang shell, for example) and, specially, I’m starting to experience the human side of this new language thing: some people excited about the project, others are skeptical and I’ve got even some detractors

You see, it’s not only about technical stuff, but also about people’s expectations. And that’s a very interesting learning path.

Expectations

I could say I’m a “Python guy”. I really enjoy dynamic languages and all the power they give to programmers. And I also like to learn new languages so that I can have a better perspective about all possible ways to achieve some objectives.

Do you want the language to be lightweight and simple? Does it have to be extensible with C? Does it have to be written in C? You want few keywords? Or lots of keywords? Big standard library? Or no standard library at all? Well, there’s a language for each case and many more.

But when you start something new, it’s kind of natural that people project their own desires into the not yet fully shaped project and start expecting many different things, so all of sudden there are people really expecting that, for instance, Til is going to be “fast” or even saying that “if it is not fast, what is the point?”.

So I think it’s better for everyone if I, the dictator-for-life of the language, write down what I expect of this project.

What I expect

An implementation that is easy to understand

I’ve been working with Python for a reasonable time, now, and curiously I never touched any CPython code. Maybe because it has more than 65K LOC (I’m trying to count only the main part, not stdlib), maybe because it’s written in C or maybe because the project is now so big (in many aspects) that (i) it feels a little unapproachable and (ii) my help kind of seems… unnecessary.

And I don’t like this situation. I would love to understand better how this language I like so much is implemented and runs and do everything it does. But I always feel somewhat overwhelmed.

Also, I’m lazy.

Another language I learned to love is Tcl. It’s such a pleasure to write some programs in Tcl! Also, the development pacing of the language itself is slow and, man, that’s awesome. You can write your program confident that a new major release is not coming in the next five to ten years - the ecosystem stability feeling is amazing. And the language is really simple (simple and effective, not stupid as Golang), to the point where coming back to any old project is… easy! That’s not something I can say even of Python (but, of course, YMMV).

The official Tcl implementation is also written in C and has around 80K LOC (counting “generic” and “unix” folders inside Tcl8.6.10). The code is much easier to read, IMHO, than CPython, and you can also study jimtcl code or even picol to understand it more if you want less lines of code to scan through.

Being more approachable is nice. It gives you the impression of something that is human made, not brought to you by some distant gods. I feel a bit more invested in Tcl than in Python, now, because for me, Tcl implementation code seems much easier to understand - although I don’t consider the language itself to be “better than Python” (actually, I have mixed feeling about it).

So I expect that Til become a very approachable language. First, because it’s implemented in D, not C, and D is a very nice language, with code generally being much easier to understand than C.

Til is in a almost usable state right now and it has still less than 4K LOC. I hope the codebase will remain small so that people will find it easy to grasp.

And that’s a clear objective. Any trickery intended to speed up execution won’t be included if that makes the code hard to read or reason about. Yes, I also enjoy using a fast language, but I’d rather have a codebase that is friendly and accessible to new programmers.

Code that is easy to understand

I decided to create a “command language” because I find them usually easy to read and reason about.

The exceptions, of course, are “obscure bash things”, that I’ll avoid for obvious reasons.

I don’t want to fill the code with too many “symbols”. I’m walking in a thin line, here, since Tcl itself has, in my opinion, too few symbols (and that’s the rationale behind the Extraction syntax), but I also don’t want to resolve any problem in the yet another one way.

Also, whenever I feel necessary, I’m relying on familiarity: if I need to use a symbol, I’ll be trying to make it feel “natural” (if there’s such a thing in our work), like the “spawn” alternative, &.

# Using `spawn`:
set p1 [spawn procedure_1]

# Using `&`:
set p2 [procedure_1 &]

(The later is better in this case because procedure_1 will be instantiated as a Command from the beginning, while spawn must collect the name and create a new Command by itself.)

Code that is easy to manage

Code is not only written, but also managed: by yourself, by your team, by other project contributors. It’s going to be subject to review and “pull requests” and diffs and validation and whatever. And that’s why I try to avoid giving too much freedom of style.

For instance: line continuations. They don’t follow the “mainstream” thread of “escaping the \n”, putting a \ at the end of each line. I never liked this thing, because programmers sometimes feel forced to align them. And, as you may have noticed, line continuation tokens live in the worst part of the line: the end.

So a code piece that was born this way:

set a [a_command \
    with a lot \
    of arguments \
    like really a lot \
    of them \
    ]

may end this way:

set a [a_command      \
    with a lot        \
    of arguments      \
    like really a lot \
    of them           \
    ]

Why? Because people are strange.

And some funny guy would even try to make this pass, just for fun:

set a [a_command   \
    with a lot      \
    of arguments     \
    like really a lot \
    of them            \
    ]

But the fact remains: it’s weird and unintuitive. Should programmers say “this line is going to be continued”? I believe it’s easier to think in terms of “this line is the continuation of the preceding one”. And, by using a smart syntatic trick, one can even make the whole piece of code seem like one singular thing:

set a [
    a_command
    . with a lot
    . of arguments
    . like really a lot
    . of them
]

It’s much easier on the eyes and now there’s no blanks at all in the end of each line. And there shouldn’t be problems in deciding how to indent: just use always 4 spaces for each level and don’t try to spare a newline after the opening bracket.

Ease to write a compiled module

Writing a Tcl extension nowadays feel really easy, and writing a module for Til should be even easier than that.

By using D instead of C, it’s already more pleasant in most of the cases, but I would like also to provide a “cookiecutter” template to make things really trivial - I really want people to rely on compiled modules instead of writing everything in Til. The language should only be the interface for more complex code written in a more rich and mature language.

Ease of deploy

And this deserves a whole new post…

---

And that’s it. I think.