The ! operator already has a meaning, which is negation. There are also many different ways to run pipelines: `run` just runs it, letting output pass through to stdout/stderr and returning nothing, but raising an error if the process fails; `success` suppresses process output and returns true or false based on the return status of the pipeline; there are also various ways of reading from and writing to pipelines, or starting pipelines asynchronously and letting them run in the background. So using ! for just one of these many ways of running external programs seems short-sighted.
There are superficial similarities. The main things that make Julia different than other dynamic languages are:
1. The expressive, sophisticated type system
2. Using multiple dispatch as its core paradigm
3. Extreme interoperability with C libraries
4. C-like performance
Of course, LuaJIT gets great performance too, so that's actually rather similar to Lua. Lua also isn't nearly as naturally suited to scientific programming.
I've been using Julia for my thesis research lately, and I find multiple dispatch to be a great match for writing mathematical algorithms, especially because of the ad-hoc specialization that it allows based on all parameter types. OO approaches always seemed weird for this sort of thing, where you'd have to decide which type "owns" the ability of how to work with the other types.
What I wish for:
- faster lambdas and which capture numbers as values not as addresses. I left Python over the latter, it caught me up all the time. At least Julia developers don't consider it a feature and plan to fix it.
- to be able to specify function domain and range types, for documentation and sanity checking
- maybe some improvements in comprehensions would be nice, so I could have an Array of Arrays of something e.g.. Currently the [x for...] comprehensions tend to collapse things together while the {x for ...} comprehensions tend to lose the types of what's inside.
Overall a great language already and a positive experience.
> I find multiple dispatch to be a great match for writing mathematical algorithms, especially because of the ad-hoc specialization that it allows based on all parameter types. OO approaches always seemed weird
This _is_ an OO approach, just not the common Java-type OO approach. Common Lisp's Object System (CLOS) has had multiple dispatch for decades.
Multiple dispatch turns out to be truly awesome for mathematical code. In my opinion, the focus and careful selection of features for technical computing, while being a general purpose programming language is what differentiates julia from other dynamic languages.
This is what I'm curious about ... what is an example of one of these carefully selected features for technical computing at the language level that is distinct from the other (dynamic) languages?
Clearly, a lot of work has gone into the library side of things, but I'm curious what is special about the language level for technical computing.
The type system is actually one of the key features for this. Systems like NumPy are essentially a way of grafting a type system onto Python arrays. Julia's design allows Array to be be a completely generic parametric type, but when specialized as Array{Float64} or Array{Int64} it is memory-compatible with C, Fortran and NumPy. As a result, Arrays can be shared between Julia, C, Fortran and NumPy without any data copying.
Another feature that's very useful for technical computing is the ability to easily create user-defined numeric types with storage and performance that's just as good as Julia's built in types (which are actually also just defined in Julia). They can also easily be made to interact completely transparently with other numeric types. A very simple example can be found here:
These 13 lines of code define a modular integer type that has the same storage and speed as regular integers, but with modular behavior, and interoperates with normal integers (i.e. `1 + ModInt{11}(1234)` works). Because of generic programming, you get matrices of ModInts for free, again with performance like plain old integers but different behavior. The same applies to defining new representations of things like matrices or dicts.
The language is carefully constrained so that type inference can work in the majority of the cases, allowing efficient code generation. The details are in our julia design paper here.
Also, a number of other language features include: `ccall` to make it easy to call C and Fortran libraries, multiple dispatch which is already discussed here, real metaprogramming capabilities which have traditionally been considered optional in this class of languages, keyword arguments (coming soon), coroutines (julia Tasks) which integrate nicely with the asynchronous networking runtime so that it is easy to overlap computation and communication, immutable types, and I am sure this is not exhaustive.
Julia is a huge step forward in practical programming languages. I was super impressed when I saw it at Strange Loop last year, and they've made strides since then.
1. In the REPL, highlighting of matching parenthesis/brackets (like in CLISP) would be good.
2. In the top-level Makefile, add a target "make distclean" to mean "make cleanall". distclean is the "GNU standard" [1]. Similarly "make mostlyclean" could clean everything except major dependencies.
We did use to have a distclean, but seems to have been lost in various build system updates.
Matching parentheses/brackets in the REPL would be really nice too. Can one do this with readline? It would be great if you could file an issue - just trying to nudge you into joining the fun. :-)
20 comments
[ 3.4 ms ] story [ 29.0 ms ] threadBTW, the lightning round is awesome. Thanks विराळ् :)
I'd have said Common Lisp as well, but some might argue point #1 with respect to that.
It is nice to see others (re-)discovering the joy of full on multiple dispatch though!
An expressive dynamic language with repl and native code compilers. quite nice.
The one thing so far that I don't like is <> around identifiers.
What I wish for:
- faster lambdas and which capture numbers as values not as addresses. I left Python over the latter, it caught me up all the time. At least Julia developers don't consider it a feature and plan to fix it.
- to be able to specify function domain and range types, for documentation and sanity checking
- maybe some improvements in comprehensions would be nice, so I could have an Array of Arrays of something e.g.. Currently the [x for...] comprehensions tend to collapse things together while the {x for ...} comprehensions tend to lose the types of what's inside.
Overall a great language already and a positive experience.
This _is_ an OO approach, just not the common Java-type OO approach. Common Lisp's Object System (CLOS) has had multiple dispatch for decades.
* http://en.wikipedia.org/wiki/Multiple_dispatch
Clearly, a lot of work has gone into the library side of things, but I'm curious what is special about the language level for technical computing.
Another feature that's very useful for technical computing is the ability to easily create user-defined numeric types with storage and performance that's just as good as Julia's built in types (which are actually also just defined in Julia). They can also easily be made to interact completely transparently with other numeric types. A very simple example can be found here:
https://github.com/JuliaLang/julia/blob/master/examples/modi...
These 13 lines of code define a modular integer type that has the same storage and speed as regular integers, but with modular behavior, and interoperates with normal integers (i.e. `1 + ModInt{11}(1234)` works). Because of generic programming, you get matrices of ModInts for free, again with performance like plain old integers but different behavior. The same applies to defining new representations of things like matrices or dicts.
http://arxiv.org/abs/1209.5145
Also, a number of other language features include: `ccall` to make it easy to call C and Fortran libraries, multiple dispatch which is already discussed here, real metaprogramming capabilities which have traditionally been considered optional in this class of languages, keyword arguments (coming soon), coroutines (julia Tasks) which integrate nicely with the asynchronous networking runtime so that it is easy to overlap computation and communication, immutable types, and I am sure this is not exhaustive.
1. In the REPL, highlighting of matching parenthesis/brackets (like in CLISP) would be good.
2. In the top-level Makefile, add a target "make distclean" to mean "make cleanall". distclean is the "GNU standard" [1]. Similarly "make mostlyclean" could clean everything except major dependencies.
[1] http://www.gnu.org/software/make/manual/html_node/Standard-T...
We did use to have a distclean, but seems to have been lost in various build system updates.
Matching parentheses/brackets in the REPL would be really nice too. Can one do this with readline? It would be great if you could file an issue - just trying to nudge you into joining the fun. :-)