Rhope Blog

Blog Home Downloads Documentation RSS


by Mike Pavone

I did my first work on what eventually became Rhope in late 2005. At the time, I was working at a small company working on tools for data driven publishing. One of the tools I was working on was a data import plugin for Adobe InDesign. Such a tool can be a boon when you're producing a large catalog both by saving time and removing much of the tedium; however, most designers producing these hefty catalogs still produce them by manually copying and pasting data in from spreadsheets. There are a number of reasons why this persists, but one of them is that doing anything more than a basic import requires a bit of logic. To deal with this, most import plugins have some kind of simple scripting language.

Most print designers are not programmers. A web designer will probably have at least some exposure to Javascript and maybe even one of the common server side languages like PHP, but the print world is still largely programming language free. As a result they tend to avoid anything that looks like programming including the scripting languages built into these tools. I started to think about how to tackle this problem and remembered an interesting game I played in high school in which you built a virtual robot and then programmed it using a "box and wires" programming environment. So I started looking online for existing languages with a similar concept and stumbled upon Prograph, Labview, Pure Data and the dataflow paradigm. As a result of my perusing, I formed an initial concept of what I wanted the language to look like and I added concurrency support as a secondary goal.

So with a preliminary design in hand, I set off to write my first prototype of Rhope (then called Visuality). By the end of 2005 I had it working to the point that it did ... something. That something wasn't useful, the interface sucked, there was no real concurrency support and the interpreter was incredibly inefficient, but it did actually run a trivial program. With this small victory under my belt, I began work on a more efficient, multi-threaded interpreter. A couple of weeks later, I was stuck. A novice at both writing interpreters and multi-threaded code, I was having trouble wrapping my head around the problem of writing a thread-safe, reasonably efficient interpreter for supporting this implicitly parallel language. So I decided to put my language aside for a while and work on other things. Eventually I started working on an open source Palm OS clone called Knose OS.

So for quite a few months, I didn't touch Rhope at all and focused all of my energies on Knose. In July of 2006, I got a new job that required a more extensive commute. So I had two 20 to 30 minute train rides each day and I kept myself entertained by working on Knose. At some point, I think in September or October that same year, I accidentally left the flash drive with the latest Knose sources at home. With few other entertainment options during my train ride, I turned back to Rhope. Progress was slow for a while as I had to reacquaint myself with the code, but I was a bit frustrated that none of the people who said they wanted to help with Knose had actually produced anything so I stuck with Rhope.

Eventually I got past the hump of writing the first version of the multi-threaded interpreter and I started to write some trivial programs. At this point, Rhope was still a completely visual language and it was clear that code density (or lack thereof) was an issue. To an extent, the issue could be solved by making the visual elements less chunky, but a large part of the problem was inherent in the language itself. An expression like If[[n] < [2]] was made up of 4 distinct "boxes" with wires connecting them. Even if I made the boxes as small as possible and made the "wires" connecting them have no length, it would still be 4 lines of text. To solve this problem, I decided to make Rhope a hybrid textual/visual language. A user could write Rhope code in a completely visual environment, use a more traditional text based environment or they could mix the two by putting textual expressions inside visual blocks.

Some of the quirks in Rhope's syntax are actually the result of this close relationship to the visual language. The "positional" inputs (i.e. something(0) refers to the first input, blah(1) the second, etc.) in particular came directly from the way the visual language worked at the time. Since inputs were already using parentheses and lists were already using curly brackets (at least I think List literals were implemented at that point), my choices for characters for other parts of the language were rather limited.

Over time the visual environment stagnated. It had changed from being the primary motivator for the project to a secondary goal and it was badly in need of a rewrite. The old visual editor no longer compiles and so for the moment Rhope is strictly a textual language. That will change eventually. Writing the new visual editor is on the roadmap to version 1.0. It's just not a priority right now.

So that's pretty much all of the interesting turns in the road leading up to Alpha 1. The overall direction of the language didn't change much after that point though there were a few interesting events in between, one of which I'll post about in the near future.

Username: Password:
Don't have an account? Register now!