Github repositories of all scientific software that I wrote, including packages that I no longer use.

I wrote Symata, a general-purpose symbolic language heavily inspired by Mathematica. Here are example notebooks. I never would have undertaken such a quixotic quest were it not for the recent appearance of the Julia language. Why Julia ? Why now ? Both the language itself and its ecosystem made this project possible. I avoid Greenspun's tenth rule , which is

Any sufficiently complicated C or FORTRAN program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Julia,except that i have replaced "Common Lisp" with "Julia". In particular, I don't have to write all the necessary pieces: a parser, user interfaces, memory management, array types, etc.

The language

- Julia is unique in that it is a "dynamic", flexible language that also produces very fast numerical code— competitive with FORTRAN and C. As in other dynamic languages, accessing arrays is safe and memory is garbage collected. One can code as in an "array" language (like Matlab), but also using procedural and object oriented styles. Explicit loops are more or less as fast as statically typed and compiled languages. In fact the first program I wrote to test Julia produced code that ran three times faster than C++ (gcc). This is due to a failure of gcc to compile away layers of abstraction in random number generation, which is essential for my work. (Note: today (Nov 2016) the Julia code runs five times faster.)
- Julia's main focus is numerical and scientific computing. This focus is well supported by core and standard libraries.
- As in Common Lisp, symbols and expression trees are first-class objects. Data types are first class objects. Julia can manipulate Julia code on the syntactic level. This enormously simplifies implementing a program that does symbolic manipulation.
- The parser and compiler are integral parts of Julia that are available to programmers. Writing a parser is a big task. Symata simply uses Julia's parser and reinterprets the syntax tree.

- A large number of energetic and very talented scientists are engaged in developing Julia.
- Package management is built in, and integrated with github. Automated testing on various platforms is trivial. It has a very powerful command line REPL that can be (more or less) easily repurposed for Symata. Interfacing with C and FORTRAN is easy. Data formats are well supported, etc.
- Julia interacts well with Python. This includes finding and installing pieces of python in the right places, essentially automatically. Symata relies on the enormous effort of the authors of SymPy and mpmath for symbolic and numerical algorithms. But, python best supports object-oriented programming built around data-type hierarchies. Symata, like Mathematica and Maxima, is organized around expressions, which are highly mutable and can easily be repurposed and reinterpreted. The use of data types is comparatively flat and minimal.

In a similar, earlier, project, I wrote an extension (in Common Lisp) to the Maxima
computer algebra system for higher-level support of a packed-array data type.
You can find it
here, along with example code and other
Maxima code. Some documentation for the functions and variables is
here.
This grew out of my earlier project of
translation and compatibility functions from
Mathematica to Maxima.
(The translator relies on Richard Fateman's
parser.)
This translation code successfully translated and ran a good deal of practical code,
including a
quantum information package and a package that
translates states from first to second quantization.
(These are included in the repository.)
But the latter case made especially clear how idiomatic Mathematica code sometimes runs
inefficiently (by a factor of `n`

) when translated to Maxima. Mathematica expressions
support random access (and even packed arrays). Maxima uses linked lists. For most algorithms, almost every scientist
who does some computation
thinks naturally in a way supported by randomly accessible elements, and not at all in a way supported
efficiently by linked lists. This becomes important if `n`

is large (sometimes moderately large).
It can make the difference between “takes some time to finish” and
“never finishes”. It should be noted that sometimes a linked list *is* appropriate,
which, for Mathematica,
can be problematic. Maxima does not support third-party packages well, so I included a package manager.
I also couldn't stand writing one more routine with ad hoc documentation and argument checking, so I
included a language extension to create these when compiling the routines, which was
possible because Maxima is written in
Common Lisp.

The Rubi project uses Mathematica's powerful system of rules and patterns to implement an integration routine that is superior to Mathematica's built-in integration. Implementing this in Maxima would be difficult or impossible. [Update: 2015. Apparently the author of Rubi is reimplementing it as a decision tree using standard flow control statements, and in fact there is work to emit Maxima code.] This is part of the impetus behind Richard Fateman's project to more-or-less implement Mathematica in Common Lisp. Information on this project can be found here.