Early on in my career, I found programming language design and compiler/interpreter construction fascinating enough to tinker with on a regular basis. So, I created a handful of languages that try to prove some point or other or have what I thought were interesting quirks. Most of them are absolutely not meant to be used industrially and the implementations almost certainly aren’t up to the task if you try.
(Had enough already? Head back to the main page)
It’s probably best to sort of like ships in a bottle, minus the glue fumes and tweezers. The languages rarely serve an engineering purpose of their own, but are an interesting diversion, and usually make a good closed project.
A lot of this is older, worked on “in the public eye” on a long-defunct mailing list for programming languages that were peculiar in some way. At the time, I released all the code into the public domain with a request that people using it in interesting ways contact me. More recently, in pushing things to GitHub, I’ve had a change of heart and licensed the current versions under the GPLv3, feeling that I would much rather see changes to things released to the public rather than someone finding a use for it and keeping everything under lock and key.
(Not to rant, but it’s the twenty-first century. If your money-making scheme requires secrecy, it’s probably not a very good scheme, especially when it comes to code…)
There’s a good chance that, if you recognize my name and haven’t interacted with me directly, this is why you know me. Thue (pronounced TOO-ay after Axel Thue) has its own Wikipedia page for being (as far as I can tell) the only programming language whose only operation is rule-based replacement, in this case based on semi-Thue (also known as Chomsky-0 or unrestricted) grammars.
You can grab the source to Thue and give it a try.
I may revisit Thue in the future, because it doesn’t quite seem complete. While I think it’s still technically possible to do through extensive sets of rules, the ability to snag sections of text out of context and reuse them might give the language more meat.
With a name that seems more annoying every time I look at it, Das Klickenklacker also won me a small amount of renown in some circles. It was an attempt to take the two-dimensional Rube programming language, at the suggestion of creator Chris Pressey, and make the rules feel more predictable.
I’m not convinced that it was successful, but I’ve had students at least claim it was fun to work with, sometimes even when their grades weren’t in the balance, so I hereby declare victory.
Plus, the animations can be fun to watch. The implementation finally uses the ncurses library, too. So, this is another case that I (or an enterprising collaborator, if anybody feels the urge) where I might revisit the implementation in order to change the colors of objects as they stay in one place for longer periods of time.
This is the last of the things you may have heard of, if you’re here for the programming languages rather than to learn about me. Wierd (WHY-urd as in “wired”) was an attempt, with some collaboration, to create a language that combined the interesting features of Befunge and Brainf— with a minor new gimmick.
Wierd, then, runs a minimal stack-based virtual machine based on a two-dimensional program, but the “important” parts of the program are the angles between visible characters, not the characters themselves. So, in a very loose sense, there are no instructions, certainly none that get explicitly put into the program.
The language runs ASCII art “wires” that intersect at angles which, themselves, are meaningful. The angles translate into very simple instructions, which then execute. It turns out to be fairly horrific to program in, partly because the interpreter isn’t entirely complete, but mostly because overlooking an instruction generally requires a complete rewrite to lay everything out on the screen.
On the bright side, Wierd might be one of the very few programming languages that require no literacy. In fact, a visual editor that allowed for easy revision could make this a useful tool, though the minimalist instruction could still be annoying. (At one point, I prototyped a system that would take a list of stack-based instructions and rough out what the program needed to look like, trading literacy back for ease of use.)
This is another project that could probably use some attention. There was an old bug report that the jumps didn’t quite work. I was never quite able to understand what the user was trying to get at (because it was wrapped with an argument that example code wasn’t what the user wanted as an example), so it’s still out there, as far as I know.
An unreleased project for my programming languages course to limit the number of languages I assigned for students to superficially learn, I developed an interpreter for a language reminiscent of the versions of BASIC often used by 8-bit home computers, Commodore BASIC in particular.
While it lacks anything like strings, data types (other than real
numbers—IEEE floating-point, not Commodore), functions, direct
memory access (
POKE), and so forth,
the interpreter does have the ability to alter the behavior
of expressions and activate and deactivate a wide variety of flow
control statements, including many that are not found in any major
programming languages, and a
TRACE facility to see which
lines are executed.
Some time soon, I’ll release it and/or add at least some of the missing features.
This was intended as sort of my magnum opus and is surprisingly mentioned on my Wikipedia page. Unlike the other languages focused on some minimalist aesthetic, *W would have been my answer to INTERCAL on the humor side and old-style C++ on the complexity side.
I think the specification is feasible (if not very funny), but it definitely lacks in genuine complexity and I never got around to an implementation. Still, it stands as one of the very few “esoteric languages” that could be more than a toy.
It would have quirky comments, compound statements, data types,
subroutines, conditions, a rich set of operations (yes, including a
* operator), and so forth. Maybe one day,
and at some point I’ll link the original specification here.
I don’t recall if I ever released this (the complete lack of documentation suggests that I haven’t), but it’s a quick and dirty interpreter for the Post-Turing Machine, a simple computational representation developed by Emil Post that is often considered a special form Alan Turing’s a-Machine or the Turing Machine.
The language has a fairly nice model and syntax (not to mention one of my favorite language names), I think, but the code is pretty terrible, particularly the extremely lazy parser. There’s a fairly good chance I threw together a prototype to try it out and forget about it before the release I planned at the time.
This is a language trying to codify the idea of mu-recursive functions (partial functions taking a tuple of natural numbers to return a natural number) as a programming system, specifically using the Primitive Recursive functions (the smallest complete set). Incomplete, the language should include the ideas of constant (0), successor-ship, projection, composition, and primitive recursion.
What can I say? I enjoyed my Theory of Computation classes.
The package includes both an interpreter and a compiler to Sphinx C--, a high-level (C-like) assembler for x86 processors that I thought was a great idea at the time, but is now non-trivial (though still possible) to find.
Years ago, Turing Machines were basically an academic concept that hobbyists talked a lot about. It bothered me that, for all the talk, I hadn’t actually worked with one. So, I implemented the system.
This package contains a compiler that translates a Turing program (the specification of a Turing Machine) into bytecode that can be run on the linked emulator. It wouldn’t surprise me if I had visions of Java-like browser plug-ins running Turing across the Internet. That sounds like me at that age. And I did find a first pass on de-obfuscating the emulator code.
Finally, something that might actually be useful to somebody! My Master’s Thesis was meant to dovetail with a long-term PhD candidate who was a local hardware designer, a way to “rough out” a processor using the tools available to high-level languages, which didn’t really exist cheaply at the time for hardware.
Quick history: Since the campus was built on the cornerstone of our local military contracting industry, the department was still mourning the loss of Pascal as the official introductory programming language, and Ada was completely specified in formal ways, we decided that we should start with an Ada-to-VHDL compiler. The plan was to make this part of a suite of software-to-hardware tools developed for other theses, but that collapsed shortly after I graduated for a variety of reasons.
That said, I have released the version I found. I don’t believe it’s the final version, because my thesis contains example VHDL output and this code doesn’t produce it. But it should be close and probably just needs a little bit of attention, because I can’t tell the difference on a visual inspection from the code listing I published.
If I had to do this again (perish the thought!), I would probably focus more on the graph transformations, dependency checking, and the push for parallelism. I wrote that code because it seemed like it was obvious and necessary, but I have since found it’s a fairly novel idea.
Something else I would have liked to have looked at was circuit layout. It would have been great to put in a program and get even a lousy circuit diagram. As mentioned, though, that surely would have gotten farmed out to another student later, had the original plan remained in place.
Incidentally, I also found the thesis itself in some ancient WordPerfect format. If anybody really wants a copy, I could probably be convinced to release it under a Creative Commons license.
Back to the main page