Julia, I Love You
r-bloggers.com
r-bloggers.com
If I wanted to implement the Fibonacci numbers in R I would do it like this:
x<-numeric(25); x[1:2] <- 1; for(i in 3:25) x[i] <- x[i-1] + x[i-2]; x[25]
Which takes about 1/10,000 the time of the recursive version (about .4 milliseconds on my machine).
So the conclusion I draw from the article is not that Julia is faster than R, but that you should know what your languages strengths are, and write code accordingly.
I'd love to see some examples of real statistical work were Julia's syntax is as easy as R, but the performance is superior.
Javascript is interpreted and doesn't have it either, yet it's 145x faster.
So one of the claims of Julia is that you write code in the most natural manner, and depend on the compiler to make it fast. So, for example, the claim is that adding the optional type parameters do not necessarily make your code faster... type inference is good enough in most cases (there are obvious counterexamples, eg with global variables, but its true in the majority of cases). Also, unlike for eg. Matlab or R, vectorising your code does not necessarily produce performance gains, arrays are good enough. One of the side effects is that the standard library is implemented in the language itself, and thus extending built-in types is a breeze.
Therefore, I think its a very interesting effort in itself. Whether it is good enough to displace any other language is a completely separate issue. As said below, the base of useful libraries in languages such as R is phenomenal. But that should not, I think, preclude admiring a very interesting new language, for the possibilities that it hints at, if only as a highly engaging mental activity.
Personally, and subjectively, I think the combination of the above, and multiple dispatch, causes the language to have a highly pleasing sense of elegance.
Disclaimer: I really like Julia, and loving it for some numerical stuff right now. That said...
Potential downsides:
- Very new, standard libs are still in flux
- Matlab-like syntax, which I have mixed feelings on
- Clustered parallelism uses ssh for transport, which I find slow (vs MPI)
- 1-based array indices (for Matlab and Fortran familiarity)
You can declare a 21 element array indexed from -10 like so:
real x(-10:10)
So hopefully anyone familiar with Fortran isn't hung up on 1-based indices.
Though it's designed as a scientific language, their goals of having C-like speed and yet Ruby-like beauty make it the perfect target for such a project.
Anyone else interested in trying it out with me?
I just finished up building a microblogging framework using Flask, and I'd love to do the same with a lean MVC framework in Julia, particularly if you achieve anything close to C-like performance.
Is Julia said to be fairly stable at this point?
By the way, have you seen brubeck: http://brubeck.io/ It would be interesting to build this framework on top of Mongrel 2. Not saying we should necessarily try. But it could be fast, fast, fast.
He explains that dynamic languages are not inherently slow. It's their current implementation that's slow. Java is not fast thanks to static typing, it is fast thanks to the Hotspot VM, which builds upon the StrongTalk VM implementation.
Quote taken around the 13" mark (some trolling included ;) ): "Ruby has the dynamic part, and Java has the fast part. And this has led to this assumption that people have that the reason that Java is fast and Ruby is slow is because Java is static and Ruby is dynamic. And that's just not true, that's just a myth. Nothing about Java being fast has anything to do with it being static. It's simply that the papers that the Java people read were the ones that told you how to make it fast, and the papers that Matz read were the ones that told you how to make it usable."
Julia looks interesting, but I don't see anything that makes me jump up and say, "I want to use that!" Everything I have seen so far can already be done with R, Python, or a combination of the two. If there are a few minor drawbacks to any process in R or Python, I would rather live with it than learn yet another language. Speed is not an issue -- if it is then I am likely coding incorrectly. If I have coded correctly, then it is worth taking the time to create a C library (and since everything else is in perspective, this is just "monkey coding" and never takes as long as we think).
I wish all of the folks who are bright enough to create their own language would voice their wants and needs to the existing coding communities to see if their needs can't be met rather than making something brand new. This kind of community interaction is crucial for a language to mature. Wouldn't you rather have a few very mature languages rather than a million young ones (each of which has its own pros and cons)?
Apart from Ada, which is probably the most popular language in the category, there are two named Alice (http://www.alice.org/, http://www.ps.uni-saarland.de/alice/), and others named Claire (http://www.claire-language.com/), Mary (http://en.wikipedia.org/wiki/Mary_(programming_language)), and Miranda (http://miranda.org.uk/). If you allow ancient Greek names, there's also Io (http://iolanguage.com/) and Ioke (http://ioke.org/).
Having said that, it'd be interesting to know how many people think "gem", "girl's name" or "derivative of Perl" when they first hear it.
Not sure what that means for the sexes, possibly nothing.
For a more powerful example (lifted straight from the Julia docs), we can compare Julia and R code for computing the 25th Fibonacci number recursively.
In the context of speed, 500 times slower is more dramatic than 75 times slower.
I don't think anyone has trouble with the arithmetical inequality. The issue is that the recursive Fibonacci number algorithm is notoriously unrealistic (it's exponential in its argument, growing as φ^n). Because of this, the claim that the example is more "powerful" is a little dubious.
I've thought having it both ways was an insurmountable barrier, and one had to sacrifice the ease-of-use of familiarity to the power of homoiconicity. I guess a resolution is to cheat, and have both sets of constructs (redundantly).
What's Julia's solution?
I don't think there's any inherent contradiction between the two, depending on what you mean by "the power of homoiconicity" (1). Homoiconicity doesn't mean you need to use lists: you could make a language like C but with native structures to hold all of the syntax. It's just that "cons cell and symbol" happen to be a really simple set of tools from which you can build everything you need.
I suspect that languages that try to have both do it by sacrificing simplicity. They have syntax that looks like C, and then make it homoiconic by building essentially a DOM for all of that syntax. Perhaps the idea is that writing and reading "x = y + z" is deemed sufficiently common that they're OK with making metaprogramming more complex if they get to keep Algol syntax.
(1) By "depends on what you mean", I meant: is simplicity requisite for power? I would say "yes", but I can imagine there's someone who would say "no" and consider Algol-plus-DOM (is that what Julia is?) to be as powerful as simpler languages.
But I think to be homo- (same) iconic (symbols), the language has to be those symbols. By this strict definition, it has to be a lisp. Maybe there's a looser definition possible, between a DOM and Lisp. I think a parallel lisp-syntax would do it (i.e. you can write everything using a lispy syntax; but there's also a friendlier syntax.
hmmmm, you could do this for any language, provided a AST representation (i.e. lispy) syntactically unambiguous with the rest. That subset of the language would then be homoiconic. e.g. add a first-class AST syntax to Java. Is that the kind of DOM you were thinking of?
public class HelloWorldApp {
public static void main(String args[]) {
System.out.println("my class name is: " + HelloWorldApp.Ast.Name);
System.out.println("i have " + HelloWorldApp.Ast.Methods.Length + " method(s)");
}
}
That's a problem, in Java: the compilation model is so constrained that even if you could write this, I don't think you could use it to make macros, since there's no way to control "read-time" versus "compile-time" versus "run-time" as you can in Lisp. So perhaps homoiconicity isn't enough: you need that, plus something like EVAL-WHEN.
You're right that the AST is available only for passed text; I hadn't thought of that as a limitation, but you're right. I was thinking of macros, that you define and manipulate within a program: the limitation doesn't affect this use case. Doing it this way, you also get control of {read,compile,run}-time.
I think it's fair to say there are degrees of homoiconicity; you can get some of the benefits by having just a subset of the features. I conject that "a language with full homoiconicity" is identical with "a lisp" - but it doesn't really matter, if we're interested in benefits.
It seems that in this case, Julia is extremely slow compared to Python, probably because the LVVM stuff has to fire up first...
Any thoughts?
Edit: Submitted it on GitHub and it seems to be a genuine bug: https://github.com/JuliaLang/julia/issues/661
- There's no quick way to del/clear the current environment. Namespaces are planned but not yet implemented.
- If a function is redefined, there is no automatic recompilation of dependent functions. It's easy though to list or recall existing functions.
Give it a go. It's a lot of fun. Some of the core team have been invited to present at Lang.NEXT.
Further information:
https://github.com/JuliaLang/julia/wiki/Graphics
I rather like Julia's parallel syntax, but I'd really prefer that the inter-host communication by done via MPI on the back end for performance. Something to hack at if I ever get time...