As best as I can tell, I am in what I believe to be a unique situation:
I am the maintainer, sole developer, and probably the only active user of the programming language SPITBOL.
(If you know of anyone else who is maintaining an open-source implemenation of a programming language that has only one user, please let me know, via comments to this post.)
Let me explain.
In June of this year I took over maintainership of Macro SPITBOL. Mark Emmer had labored for almost a quarter century in this task. He kept Macro SPITBOL alive, and that is the task I face going forward.
Macro SPITBOL, the work of Robert B. K. Dewar and the late A. P. “Tony” McCann, is the best implementation of the SNOBOL4 language yet created. I believe it to be a remarkable accomplishment.
SNOBOL was created at Bell Labs in the early 60’s. The basic reference is The SNOBOL4 Programming Language, by R. E. “Ralph” Griswold, J. F. Pogue, and and I. P. Polonsky. It is known to SNOBOL4/SPITBOL folks as just “The Green Book,” due to the color of its cover. (Mark Emmer secured the rights to make it available, and the pdf for the book is freely above at the cited URL.)
SNOBOL was the first language to address processing strings and text in a serious way. It’s most notable innovation was the notion of “pattern.” As part of this, it introduced many primitives such as BREAK and SPAN. Those terms are now commonly used in many libraries and programs that process text.
SNOBOL was one of several languages widely taught in “Introduction To Programming” courses in the 70’s and early 80’s.Then — I think it fair to say — SNOBOL sank into obscurity.
Macro SPITBOL was created in the mid 70’s. Dewar and McCann finished their work by the late 70’s. I did the port to CDC 6600 in the late 70’s, and worked with Robert to do the port to the IBM/PC 8086 in 1983. Mark Emmer then took over the project, and did ports to Mac, Solaris, and various versions of Unix.
At most ten people worked on refining the SPITBOL implementation. I’m the only one still working on it. Mark lends a hand now and then, but more as an advisor than programmer.
Since taking over maintainership I have finished the Linux port (Mark had already done most of the heavy lifting). I started writing about SPITBOL on this b log to drum up interest, and I am actively working on the port to Apple’s OSX, to be followed by a port to the ARM architecture, so that SPITBOL can be made available on Apple’s ioS and Google’s Android operating environments (both use ARM chips).
Here is where the work stands:
- There have been just over 3,000 downloads of the Windows version since it was released in open-source form in July 2009. I’ve received less than ten, if not zero, emails and blog comments about this version since its release.
- There have been 30 (thirty) downloads of the Linux version since it was released two months ago. I’ve heard back from few than five people that they have downloaded it and also tried it.
- While a few (under 10) folks have expressed interest in the work, no one has stepped forward to work on the code as a developer.
- I’ve seen no sign anyone is actively using SNOBOL4/SPITBOL in a serious way. SPITBOL was once used by folks in the linguistics community, but I’ve seen no sign of recent work.
- I did a search on Google for “SPITBOL” in June and got about 17,000 matches. I also did a search on “SNOBOL4” and got about 47,000 matches. I just repeated the searches and got the same results.
- Despite making many posts about SPITBOL on my blog, I have yet to see any one of them achieve more than 20 or so views.
In summary, though I know I have advanced the code, I have been a failure trying to drum up interest in the project.
I am not giving up. I have several reasons to push on:
- SPITBOL is unique in the power it provides to manipulate strings and text. I’ve yet to see anything else come close.
- SPITBOL is both amazingly fast and compact. It can compile hundreds of thousands of lines of code per second, in a program consisting of under 20,0000 executable instructions. It runs at the hardware level. For example, it includes a compacting mark-sweek garbage collector, while I know of at least one widely-used programmng language that still uses reference counts. 
- The ARM implementation should be *very* fast.
- I have packaged the system so it is self-hosting. SPITBOL uses tcc for its C compiler, NASM for its assembler, musl libc for its runtime libraries, and Rob Lanbley’s toybox to provide basic Unix commands. SPITBOL is built with these open-source packages, and the source for them is included in the SPITBOL distribution, so you get not only Macro SPITBOL, but a complete development environment to boot.
- I believe there is a great opportunity due to the poor support for Unicode in other programming languages and libraries. If I can add full support for Unicode, I hope to realize “if you build it, they will come.”
- Perhaps most important: SPITBOL is fun!. I’ve been programming for over fifty years, and I have never had so much fun save when I was working on SPITBOL, as either user of the language or as an implementer.
- The quality of the system will speak for itself: Code Talks.
- Knowing that I am starting from zero, any progress will be great news, and it will be fun to see how far I can get. I had a similar experience working with Philippe Charles on Jikes. We started from nothing, and were able to build something that achieved some success. I hope to repeat that, and I know I will have fun trying to do so, even if I don’t succeed.
It is also evident that talking about SPITBOL is a thankless task for now, so I’m going to put off blogging, twittering and such, so I can concentrate on the coding, which after all is all that matters.
Most importantly, I believe that polishing the implementation and porting it to new environments is not enough.
The *only* way to move the project forward is to finish needed refinement and ports as soon as possible, and then to use the result to write applications in SPITBOL that demonstrate what can done when programming in SPITBOL.
I have a few ideas about useful applications, and hope to get to work on them as soon as possible.
We shall see…
1. Can you name a widely-used contemporary programming language that still uses the 60’s software technology of reference counts to manage storage?