Frequently Asked Questions
Why make a language?
Tomo began as a pandemic hobby project and it grew out of control. Working on a programming language is genuinely fun for me, so it’s been an off-and-on hobby project for several years. I think Tomo is a good showcase of a bunch of ideas I think should catch on in mainstream programming languages. Tomo serves as a proof-of-concept that these ideas can work in practice. It’s unlikely that Tomo itself will catch on as a mainstream language (one can hope!), but at the very least, I hope that it will inspire future languages to take some of the best ideas and take them further.
What is Tomo’s target application?
I didn’t build Tomo with a specific application in mind, but rather a specific level of abstraction. Tomo is great for the same level of abstraction as Go (garbage collected, but high performance), but with more user-friendly features and some neat bells and whistles that Go lacks. It’s a language that tries to steal some of the best qualities of both Python and C: convenient and readable, but fast and simple (with an extra sprinkling of type safety).
Some applications I think might work especially well:
- Command-line applications (the built-in argument parsing is very helpful)
- Web servers (good performance and safety features)
- Game scripting (easy C interoperability, good performance)
- Desktop applications (C interop, good performance)
- Raspberry Pi projects (efficient use of resources and good cross-platform support)
Essentially, it’s good for cases where you might write C code or work with a C library, but would prefer to have more safety and user-friendliness, and not worry about manual memory management.
Tomo is probably less well suited to:
- Hardware drivers
- Operating systems
- Game engines and graphics programming
- Memory-constrained hardware
In other words, if having a garbage collector is a dealbreaker, then pick another language!
Why are lists 1-indexed?
Having spent a lot of time programming in Lua, I’ve come to be very fond of
1-indexed lists/arrays. 1-indexing has a lot of ergonomic benefits over
0-indexing that makes it easier to avoid off-by-one errors.
list[5]
is the fifth element in the list. This also extends to
numeric ranges: (5).to(7)
encompasses the numbers
[5, 6, 7]
. Since list indices are 1-indexed, it means that
numeric ranges don’t need to be half-open ranges
(i.e. low <= x < high
). It also means that list indices are
human-readable. Consider this code:
for i,line in lines
say("$i) $line")
As a programmer, you don’t need to convert between a “computer-readable” index and a “human-readable” index. In general, my experience has been that this leads to fewer off-by-one bugs.
One example of a common pitfall is reverse iteration of array indices in languages like C or Python:
# Forward:
for i in range(0, n): ...
# Backward:
for i in range(n-1, -1, -1): ...
// Forward:
for (int i = 0; i < n; i++) { ... }
// Backward
for (int i = n-1; i >= 0; i--) { ... }
Since Tomo uses 1-indexed lists, the length of a list is a valid index, which means that iteration becomes less prone to off-by-one errors:
# Forward:
for i in (1).to(n) ...
# Backward:
for i in (n).to(1) ...
Similarly, operations like “take the first n
elements of a
list” do not require off-by-one adjustments: list:to(n)
.
The one inconvenience I’ve encountered working with 1-indexed languages is
that wraparound behavior is more inconvenient. For example, if you
have a ringbuffer, it’s annoying to wrap an index. Tomo addresses this issue
with the mod1
operator, which performs “clock arithmetic”
wrapping. In other words, x mod1 12
behaves like the numbers on a
clock face: 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 ...
. It’s simple to
use wraparound behavior on a Tomo list:
list[index mod1 list.length]
.
Why whitespace sensitivity instead of curly braces?
This comes down mainly to personal preference. I enjoy Python’s indentation-based syntax and find it easy to work with. Languages with curly braces tend to use more vertical space for the same code, which means that less actual code can fit on screen at one time. I prefer the compactness and reduced visual noise of indentation-based blocks. I won’t argue that all languages should work this way, but I think that the massive success of Python is testament to the fact that indentation-based languages are viable.