What if I want to deform the terrain with cubes, not a sphere? What if I want a sphere with radius X, not just a "small" sphere? What if I want the sphere to be made of ice? What if I want there to be red ice and yellow ice and green ice? Etc.
All questions are the same Big Question really. It's a valid one: What if your language doesn't let me say what I want to say? And for those who subscribe to the Sapir-Whorf hypothesis, the question becomes a philosophical one:
What if your language doesn't let me express the thoughts I have in my mind?
No one likes having their thoughts restricted by someone else's language. I certainly don't. George Orwell hated the idea so much, he wrote a whole book about it. Why would the CodeSpells community be any different? We are a community of dreamers. Our genre is "fantasy" -- a word practically synonymous with "dream." We want magic to enable dreams, not restrict them.
I'm excited, though, because I think I have a solution to the fundamental problem of: How do I make a language that enables the expression of all (reasonable) dreams?
I'll confess: my solution isn't really my solution. It's one that we (the human race) have been working on at an exponentially increasing rate since circa the 1950s: Don't build one language; Build a zillion. Different ones allow us to express different things in different ways. No humble-brag intended, but: I know a bunch of programming languages, libraries, and frameworks, and it's still a tiny fraction of the number that exist on the planet Earth.
I dare say, the CodeSpells Canon shall add a few more. Rune-wielding wizards of worlds far away would, I think, have noticed a very interesting fact: Runes are just things in the world; and spells are capable of querying and changing things in the world. The moment such wizards discovered how write spells capable of reading in more Runes, they would (as we did here on Earth) immediately begin writing what one might call "interpreters" or "compilers." They would immediately begin crafting new Runes, with new semantics, and new rules of combination. In other words: new languages. A Tower of Babel? I think of it more like a linguistic super nova.
So for the last few days, I've been in my wizard tower forging very specific facets of the CodeSpells Authoring Tools -- the facets that will enable me and others to create new Rune-based programming languages. Because CodeSpells is a community, I'm not just creating languages for my own CodeSpells Authored Works, like CodeSpells: The Seeker; I'm also paving the way for other developer/writers to do so.
One thing I've done is begin the creation of a library for defining how Runes look, for binding Runes to textual identifiers in the Racket language, and for producing Rune programs that are properly formatted and can be intermingled with text.
That last part matters because in CodeSpells: The Seeker, as you progress through the world, you'll be unlocking pages of a spellbook written by a powerful wizard known as The Seeker. The spellbook (essentially "documentation" -- if I may break the fourth wall for a moment) is the only way you'll know what you can do with the Runes you unlock in-game. Yep: Even Rune-based programming languages need documentation. Gotta learn 'em somehow!
Before I can get to authoring the "What can Runes do?" part of CodeSpells: The Seeker, I need to finalize things like:
So that's what I've been up to in my wizard tower. Let's get meta (as we must in CodeSpells) and talk about code for working with code!
If you happen to look at the source code for this blog post, you'll see that this non-Rune code:
(typeset-runes crunchy-demo-lang (build small))
produces this Rune code, with a "crunchy" look-and-feel I created by hand-crafting each rune in Inkscape.
However, this non-Rune code typesets the same (build small) a bit differently.
(typeset-runes (basic-lang) (build small))
Here's the result:
It changes the look and feel. It looks too cartoony. (Don't worry: I'm still working on it.)
One thing I'm committing to in this CodeSpells Reboot is to produce a meaningful blog post very regularly. Like: Every few weekdays. That means you'll inevitably see stuff that is unpolished and in flux. Stuff that's hot off the press. Stuff that's only been on Github for a few hours. I hope you enjoy the development process. I hope you'll enjoy always being clued in to what I'm working on and why.
And I hope, dear reader, that you'll be understanding and kind.
I want to point out a few things about the (still in progress) basic-lang.
Let's leave off with an admittedly silly example (but which actually does work in-game).
(define (C) (build small)) (C)
This code gets Runeified as follows:
This code defines a function (using). The function is called . Previously, the underlying identifier C was unbound, as was its Rune. After defining the function, the code calls it.
Like I said, a bit silly. But I bring it up to motivate some questions...
Some obvious ones: Where did the rune for the unbound C come from? What if we wanted to call that function something other than C? What if we wanted that Rune to look like something that reminds us of what the function does, not the letter C?
Creation of Runes for user-defined variables is a key technical challenge in Rune-based programming. Luckily, I have a few solutions, one of which makes use of both the "Runes-are-widgets-not-images" feature I mentioned before, and also the "Runes-are-defined-with-Racket-code" feature. *gasp!* Could it be? Could we use Runes to create new Runes? (How meta can we get with CodeSpells?) Stay tuned for updates on that and also on the look-and-feel of basic-lang.
- Stephen R. Foster
P.S. Please consider supporting us on Patreon. We can't do this without you!