julia seems to be positioned as a kind of matlab / r replacement. but i'm finding it works very well as a faster python, for the kind of programs i am writing in my free time (learning about / analysing block ciphers, most recently).
its big idea is multiple dispatch, like clos (oo-lisp) multimethods. where you would define an "underscores" method in python (ie to extend the language for a new class), in julia you define appropriate functions for that type - the cute thing being that the new type doesn't have to be the first parameter.
so, for example, the equivalent of
class Foo:
def __repr__(self):
...
would be
function show(io, f::Foo)
...
end
and the end result is something that has more of a FP flavor than python. it's very appealing.
if you're looking for a "dynamic scripting" language that takes some of the good bits from static typing, and has decent performance, it's worth a try.
I think another big advantage of CLOS that Julia took is that you can dispatch on the type of not just the first argument but on the combination of the types of all the arguments
Multiple dispatch is very powerful paradigm and Julia takes it a good bit further even than CLOS. There's a good comparison of Julia and CLOS in terms of parametric types and dispatch in Julia's Wikipedia entry:
It also compares with Dylan and Fortress, which are the other major non-research multiple dispatch languages. The unique combination of features that Julia has is
1. a fully dynamic type system (code with type annotations is still dynamically typed)
2. functions are all generic by default, including all the built-ins and operators
3. support for parametric types that you can dispatch on.
This combination of features working smoothly together turns out to be very powerful, especially when designed so that you don't have to talk about types except when you want to.
Fair point, although R's multiple dispatch barely counts as a language feature at all, but is really more of a standard add-on library (read on). All S4 is doing is using a hash table keyed by method signatures to look up which function body to call. You don't even need any syntactic support since "defining a generic function" is just a matter of defining a function that does a hash lookup and then applies that function to its arguments. R doesn't provide any syntactic support for adding methods to generics – you literally have to give it a vector of strings of argument class names. Since you can do all of this in any language – even C – it's arguable that multiple dispatch isn't really part of "the R language" at all, but rather "the R system" happens to ship with a standard implementation of hash-based multiple dispatch and a few of the built-in function like "show" and "plot" are defined using it.
Due to not being a deep language feature, S4 lacks some crucial abilities. It doesn't support any sort of type hierarchy besides the special "ANY" class. Without the ability to define a type hierarchy and program to abstract types, most of the power of multiple dispatch evaporates. Even though it is technically an implementation detail, I've found that performance is a critical feature for multiple dispatch to really come into its own. R's S4 dispatch has been described as "slower than S3" [1] – and S3 dispatch is not exactly fast. Unless really basic things like + and array indexing can be generic and usably fast, you're not really cooking with gas.
Thanks for the explanation. What do you mean by "It doesn't support any sort of type hierarchy"? I've contributed to a package that defines some S4 methods on a base class and relies on that implementation being called on derived classes as well.
This may be a misunderstanding on my part because I am by no means an R expert (I've done a fair amount of stats work in R, but no library development). Can you add a method for base class "Foo" which will automatically apply to "Bar" which is a subtype of "Foo"?
> We will be supporting a 0.2 line of releases that maintains compatibility with 0.2 with minimally invasive bug fixes, so this is a good time to switch to 0.2 for production systems.
This release was a fairly long time coming from the previous 0.1 stable release. If you've been considering trying Julia out but were worried that it was moving too fast (it's been moving pretty fast), this is a good time to try it out. Not only will the 0.2 release line be supported with minimally invasive bugfixes, but also the 0.3 release is going to largely consist of performance improvements.
For anyone interested in using Julia for numerical optimization/mathematical programming, see http://juliaopt.org/.
We have pure-Julia implementations of standard unconstrained methods [1] as well as a domain-specific modeling language [2] for (integer) linear programming with links to open-source and commercial solvers. Julia's performance and advanced language features such as metaprogramming really make it a great language for optimization [3].
I'd love to switch to Julia, but I rely on a lot of packages that are only available in R (e.g. lots from http://bioconductor.org/). Is there any way to call R code from Julia?
After using it for smaller projects, one of the few things I don't like is multidimensional arrays. I would prefer if only arrays of arrays were possible and had some syntax sugar.
Edit: And perhaps some special treatment by the compiler for optimization. I find multi-d arrays counter-intuitive and clumsy on some situations. Also, currently I'm forced to write ugly code like array[x,y][i].
You can of course use arrays of arrays if you like, but multidimensional arrays are indispensable for numerical work, especially linear algebra – matrices are 2D arrays after all. When doing numerical work in C, for example, you have to simulate multidimensional arrays by doing your own index calculations to translate back and forth between linear indexing and N-d indexing. Having language support for this is a must if you want to target numerical programming.
I'm confused about your reference to C. C has multidimensional arrays, and all the elements are laid out contiguously in memory. No index calculations are needed, it's all done by the array indexing operation.
If you have this code:
int a[10][10];
then:
&a[x][y] == ((char *)a + x * sizeof(a[0]) + y * sizeof(a[0][0]))
where sizeof(a[0]) is == sizeof(int) * 10.
quick edit: added a (char *) cast so the arithmetic doesn't multiply by sizeof(int) again
Right, I should have clarified. That works for statically allocated arrays but not for dynamically allocated ones. Since matrix dimensions are generally not known ahead of time, in real programs you almost always end up needing to simulate multiple indices using explicit index arithmetic.
Memory layout mostly. For example, a 10x10 64-bit floating-point matrix should be stored as contiguous chunk of 100 inline 64-bit floats. This is quite different than an array of arrays, which is represented as an array of pointers to separate boxed 1-d array objects. The contiguous layout is not only far more efficient, but also is what all numerical libraries like LAPACK and FFTW expect. If numerical arrays were not laid out like that in Julia, then we wouldn't be able to do fast linear algebra or FFTs.
Of course, sometimes you do want an array of arrays, such as when each array needs to have a different length or element type – which you can of course do. Which is why I'm a bit confused about how having support for multidimensional arrays is a problem. If you find them confusing, why not just ignore the feature and use arrays of arrays all the time?
I'm also not clear on what "special treatment by the compiler" means.
> Of course, sometimes you do want an array of arrays, such as when each array needs to have a different length or element type – which you can of course do. Which is why I'm a bit confused about how having support for multidimensional arrays is a problem. If you find them confusing, why not just ignore the feature and use arrays of arrays all the time?
The standard lib and 3rd party libs use multi-d arrays, so I can't avoid them. But I guess it takes some time to get used to.
> I'm also not clear on what "special treatment by the compiler" means.
I meant something like saving an array of arrays into a continuous memory block and somehow enforcing that the sub-arrays must have equal length. But now I realize that this is probably impossible...
I haven't used Julia yet, but would be curious to hear more about your experience. Was it overall positive? How does it compare with your experience using other languages?
I'm on mobile so just a summary - I have tried tens of languages and Julia is the probably my second-most favourite (first is Ceylon). I'm really impressed by it and can highly recommend.
Does anyone know what the state of plotting is in Julia? I couldn't really find any convincing examples for that. For many applications, plotting really is a big requirement.
That said, I look forward to a future where Julia will take over many use cases that are served by Matlab right now.
With a plotting package that generates image files, like 'Winston', there is easy support in Julia Studio to get some interaction. When the image file is opened in an editor window, it is live updated with each run of the program. see:
http://www.kees.cc/images/JSplot-big.png
there's a package (called gadfly) that works like r's ggplot2. i haven't used either a huge amount, so it's possible the julia version has gaps, but i could produce basic, very attractive graphs with ease in both languages.
While the focus of many of its contributors remain scientific computing, and its use in academia is growing, the language in itself is very amenable towards more mainstream programming. For example, there are packages (at varying level of maturity) for HTTP Servers, HTTP middleware, templating with Mustache, Redis, database access, Logging etc. So I'd say, the language itself is very suitable for mainstream programming, and the library ecosystem around it is growing and maturing quite well for such a young language.
There is also a great interface to Python, giving you access to the wide range of its libraries.
Mainstream is a very context specific term. Julia is not a general purpose language, it's primarily for numeric computing. Within the domain of technical computing it's one of the most expressive languages.
I would strongly disagree with this. Julia is a general purpose language. In fact, part of the premise is that it is a numerical computing language because it doesn't special-case numerical programming. This is in stark contrast to Matlab and R, for which numerical things are extremely special-cased.
its big idea is multiple dispatch, like clos (oo-lisp) multimethods. where you would define an "underscores" method in python (ie to extend the language for a new class), in julia you define appropriate functions for that type - the cute thing being that the new type doesn't have to be the first parameter.
so, for example, the equivalent of
would be and the end result is something that has more of a FP flavor than python. it's very appealing.if you're looking for a "dynamic scripting" language that takes some of the good bits from static typing, and has decent performance, it's worth a try.