## Thoughts on Julia

Recently, a new scientific computing language Julia has been released (or rather, received much attention). I attended a talk by one of its creators last week and I am less than impressed. Granted, it is still very much in its infancy, but it seems more like a programming language research project than a language created to solve problems, even though that's what it is being sold as. The talk largely focused on the interesting aspects of the language itself (in fairness, I don't see how else one would fill in an hour timeslot).

My primary problem with it is that it appears to be a variant of Matlab, while there are already lots of Matlab clones out there like Octave. The problem with Matlab is that it is such an unorganized language, with lots of annoyances that make actual programming extremely painful. For example, the random hodge-podge of short built-in functions in the global namespace, the 1-based indexing (yes, this is actually a hassle when you want to implement complicated algorithms), the lack of concrete typing.

There are a few positives. Its automatic parallelization is is neat, but its ability to scale up automatically remains to be seen. The fact that its entirely open source is also a huge plus.

The closest to an ideal language at the moment is Lua, except for its 1-based indexing. A more C-like syntax and array slices would be nice, too. Here is my ideal scientific computing language checklist:

- C-like syntax. Seriously. It is so well established that most people can read it. Anything other than curly braces, to me, just makes identifying blocks harder than it needs to be. I might be biased on this one.
- 0-based indexing (ranges are lower inclusive and upper exclusive). Mathematicians, shut up. When you try to obtain sub-blocks of matrices, it is far more natural to think in terms of offsets rather than ordinal positions. Reading Matlab and Fortran code that tries to do this is extremely confusing with the off-by-1 corrections in the slices. This phenomenon extends to areas far beyond matrix slicing.
- Multiple return values from functions. Wait hold on. Let's start with actual fuckin' functions (I'm looking at you, Matlab). While Matlab actually does allow multiple and contextual function return values, the fact that it forces you to put each function in its own file is absurd. All new languages that don't allow multiple return values: why? This is 2012. We can build this. We have the technology.
- Sensible function names. "eig" is NOT a good function name. Hm, let me compute an eigenvalue and store it in a variable. What shall I call it? How about "eig". Well fuck. Mathematica has the right idea here. The function names are borderline-too-long, but they are clear, descriptive, and unlikely to clash. The Mathematica module system is also quite sensible, with namespaces for functions and variables.
- Compilable to clean C-code. This is a feature that basically no language in existence supports. For scientific computing, the final stage in prototyping is producing production-ready code. Which means standards compliant C89 code, period. Anything more sophisticated risks not being supported on the target platform. This feature pretty much requires some kind of type declaration or hinting system in the language. I'm okay with this being required, but practically, it is better if this is required only for code generation.

Note that I don't require special matrix syntax, such as the single-quote transpose operator in Matlab, or the ungodly quantity of non-ASCII symbols in Mathematica. The language of mathematics will always be too rich and fluid for a programming language to keep up with, especially one that hopes to maintain support and compatibility. Until this holy-grail of a language comes around, I will stick to C and Lua.