Introduction to Caltha
Features
Caltha Language Specification
FAQ
Background
|
When I first started designing Caltha, I would never have envisioned the language it turned out to be. Although I considered 50 to be an excessive number of reserved words, it had not occurred to me that the ideal number might be zero. And while goto statements and memory addresses were always out of the question, I had not planned to get rid of all jump statements, all iterative structures, and all data references.
In light of all the features Caltha does not include, one might get the impression that the whole project is merely a theoretical exercise. But although my language has grown simpler with time, my goal to invent something of practical value has not changed. The following describes what led me to take up language design as hobby, explains the programming ideas I found most influential, and provides more information about the project in general.
My Background
My father introduced me to Pascal while I was in high school. Interested in designing my own computer games, I wrote code for years before taking my first programming course. Later, as an Engineering Physics student at the University of British Columbia, I completed as many computer science electives as I could get credit for. I also gained considerable programming experience through work placements at the local power utility, UBC's Earth and Ocean Sciences department, and a laser research centre in Germany.
As it turned out, 2003 was not the best year for a programmer to graduate. The industry had yet to recover from the so-called "dot-com burst". But I found a very rewarding job in mineral exploration, which took me to the Mediterranean, the Middle East, Australia, and all over North America. When I wasn't abroad conducting geophysical surveys, I was in Vancouver programming data management and visualization software. My signal processing algorithms helped the company replace much of its analog equipment with improved digital technology.
Despite the mathematical nature of my programming language, I am more of a technologist than a mathematician. Most of my projects were developed via an iterative process of coding and testing. This, I believe, is the usual method. Like most present-day software developers, I am experienced with objected-oriented languages and techniques. But now I am trying to adopt a new approach to programming.
The Technological Inspiration
My interest in programming language design was piqued by Python, which I started using in 2001. I was thoroughly impressed with the convenience of the language, as well as the extension now known as "Numpy" that adapts it for numerical work. Most of my experience at the time had been with C and C++, which encourage the use of memory allocation and loops for trivial array operations.
float* y = (float*) malloc(sizeof(float)*(n - 1));
for (int i = 0; i < n - 1; i++) {
y[i] = x[i + 1] - x[i];
}
Memory allocation in Python is handled automatically, and many operations can be performed on entire arrays at once. The result is a dramatic reduction in the amount code one needs to write.
y = x[1:] - x[:-1]
But Python is not without its own shortcomings. For one thing, its programs tend to run slower than those written in C, C++, or Fortran. And because the language was not originally designed for scientific work, the use of numerical arrays often requires the introduction of distracting statements and technological references.
from numpy import *
x = array([5, 3, 4, 7, -2], dtype=float)
I felt that scientific programmers would be better served by a faster language designed specifically for scientific applications. And for reasons that I can't explain, I figured that this might be a suitable project for me to take on in my spare time.
A Mathematical Approach
The Internet provides an aspiring language designer with an endless source of opinionated articles, comments, and rants. Thousands of software developers debate over object-oriented techniques, functional language features, static vs dynamic typing, etc. But of all the gurus, bloggers, and researchers, I was most inspired by an individual who spent the latter part of his life writing programs with pen and paper. Always skeptical of new technology, he offered the following analogy to explain his choice of tools.
"I don't need to waste my time with a computer just because I am a computer scientist.
[Medical researchers are not required to suffer from the diseases they investigate.]"
Edsger W. Dijkstra was no stranger to computers, however. He is known for co-writing the first compiler of Algol 60, the language that popularized structured programming. He also led the development of one of the first multitasking operating systems. But Dijkstra made many of his greatest contributions after he stopped writing software altogether. These included language features he designed but never implemented.
Most programmers will agree that it is more important for people to be able to read your code than for computers to be able to execute it. But Dijkstra went a step further, demonstrating that it is not always beneficial to write programs for computers at all. Below is his formula for calculating the maximum of the numbers x and y.
It is clear that x is the maximum if it is greater than y, and vice versa. But what's interesting is the case where x and y are equal. Both conditions are then true, and Dijkstra's notation doesn't specify which corresponding statement is to be selected. A computer would need additional rules in order to make the decision, but a human can immediately recognize that the choice is irrelevant. Dijkstra's programs were truly written people.
Because he didn't have to worry about technological limitations, Dijkstra was free to incorporate mathematical notations of any kind into his programs. That said, he would only adopt a notation if it was unambiguous; otherwise he would change it. Many language designers start with existing programming languages, then replace certain features with other features. Dijkstra started with traditional mathematics, then replaced certain notations with other notations.
At first Dijkstra's methods seemed impractical to me. He was concerned with the clarity of handwritten mathematics, whereas my concern was with the production of executable code. But eventually I came to accept that if the ambiguities of traditional math were rectified, then a mathematical formula could be executed as if it were computer code. Dijkstra's research, while appealing to theoreticians, in fact had the potential to be of great practical value.
The Caltha Project
Even after discovering Dijkstra's articles, it took me a long time to discard the technological language features I was used to. For years I planned to distinguish between data types such as integers and floating-point numbers, though finally I decided that "0" and "0.0" should be semantically equivalent in every way. It wasn't hard abandon data pointers, having suffered from memory leaks and similar bugs using C or C++, but I was very hesitant to give up the ability to pass variables by reference. Reserved words were relatively easy to omit. But the idea of extending brackets over multiple lines of code, a convention that cannot be typed, was difficult to accept.
Eventually I made a firm decision to design Caltha as a set of handwritten mathematical notations. My goal was still to create something practical, however, and hence originality was not one of my priorities. Many of the unusual conventions I adopted were the invention of University of Toronto professor Eric Hehner, an expert in formal programming methods.
After designing the core features of the language, I set up this website to share my work with others. Although I have the option of presenting Caltha programs as either typed code or computer-generated mathematical formulae, many of my examples are written by hand. My intention is to emphasize the point that, with a simple language, one can formulate and present their programs using only pen and paper. I hope readers will not get the impression that Caltha is impractical for computation. After the language specification is complete, I plan to start work on software for rendering and executing Caltha code.
|
Personal Information
After three and a half years in the mining industry, I am now returning to academia to pursue a master's degree in biomedical engineering.
My favourite sports include rock-climbing, swimming, waterpolo, and soccer. I also enjoy hiking, particularly in alpine settings. I named my programming language after a mountain in British Columbia.
Rhys Goldstein
|
|
|
The Caltha Language Website
