Juila vs Mathematica (Wolfram language): high-level features

[Акатер Дима]

It's mentioned here http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica was one of the programs that inspired Julia. How does Julia compare to Mathematica's language?

To make the question more specific,

- it's about languages, not implementations, so Mathematica's FrontEnd capabilities are irrelevant (and it's also not about “which one is faster”)
- it's not about free vs non-free
- it's not about communities and support
- it's not about anything related to OOP (feel free to write about, sure, but I will probably be very passive in discussions concerning OOP)

- it's about the languages' most high-level features, like meta-programming, macros, interactions with other languages and the way it treats types

For example, Wolfram language (which is now the name of Mma's core language), implements meta-programming capabilities via term-rewriting and Hold. It provides some foreign-language interfaces via MathLink (which could be WolframLink already) and also has SymbolicC. It is untyped and proud of it; types can be implemented easily but they are of little practical need in the absence of compiler.

- it's also about the languages' most distinctive features: are there things Julia has that WL does not have? (Which means adding them to WL would require reimplementing Julia in WL, much in spirit of Greenspun's tenth rule.)

To provide a starting point, here is the definition of type in Julia from documentation http://docs.julialang.org/en/latest/manual/metaprogramming/

type Expr
  head::Symbol
  args::Array{Any,1}
  typ
end

Maybe there's a typo in docs (line 4) but it doesn't really matter. What do Julia users do, for example, to avoid boilerplate code defining lots of types? I understand how to avoid writing boilerplate definitions in WL: it may not be easy but at least I know where to begin in case I need a program that would write new definitions or update existing ones.

[Knud Sørensen]

I installed wolfram  on my raspberry pi.
Mostly to play with free-form linguistics but I couldn't get it to work.
I considred D, Julia and Wolfram for a  raspberry pi project.

But D(dmd) and  Julia is not in the apt-get archve for raspberry pi
and wolfram is behind a paywall on other platforms.
So, I decided to go with racket.

I don't know much about it but there is some talk about reactive programming. See:
http://en.wikipedia.org/wiki/Reactive_programming
https://www.coursera.org/course/reactive

One of the reasons I have had look at Julia and wolfram is that I took a course in systematic program design some time ago.
https://www.coursera.org/course/programdesign
It teaches that the structure of the program follow from the structure of the data,
and I was looking for a programming language which uses this fact and places the data first. Like:

suffixTree res=("GTAGT$",[5, 2, 3, 0, 4, 1],[0, 0, 0, 2, 0, 1]).suffixArray2suffixTree

The idé is that by placing the data first the programming envioment might help you find the right function or series of function (with tab complete ?),
or maybe write some systematic code automatically.

Well, this might just be some late night rambling not much about Julia or Wolfram.

Knud

[Jason Merrill]

Julia and Mathematica are very, very different languages.

Mathematica's underlying model is heavily based on pattern matching and term rewriting. Most function definitions in Mathematica should really be thought of as replacement rules

  > f[x_] := Sin[x^2]

means "replace any expression with the head `f` and any single argument with the expression on the rhs". Mathematica hardly has the concept of an undefined variable; it just has symbols that don't have any replacement rules yet. So you can make new expressions, e.g. like this:

  > f[q + 1]
  Sin[(q+ 1)^2]

Mathematica makes it possible to write procedural "do this, then do this, then do this", for-loopy code, but working that way is very much working against the grain. It's much more natural to structure your programs as successive replacements that transform symbolic expressions. This means that the implementers make every effort to expose any kind of data that you might care about as a symbolic expression of some kind. Symbolic graphics are a great example to study: in that case, you can do things like change all your points to red circles using a replacement rule.

Julia has a much more traditional evaluation model. It's totally fine and natural to write procedural code like you would in C, and when you do, you can get performance similar to C. The biggest advantage of Julia over Mathematica is that Julia tries to make its semantics obvious enough that you can reason about performance. You can also reason about the way your data is stored in memory. Mathematica generally tries to abstract these details away, and the result is that being able to write fast C code does not translate at all into being able to write fast Mathematica code.

Both Mathematica and Julia let you dispatch to different definitions of a function based on its arguments, but Julia does this according to the Type of all of the arguments, and Mathematica does it according to structural pattern matching rules.

The most important thing the two languages have in common is that (almost?) all of the syntax maps to expressions, where an expression is an object with a head and args. This uniformity makes it easier to treat code as data, allowing code to be generated and transformed in similar ways that other data structures are.

Julia typically does code transformation at parse time (or maybe macro-expansion time is separated from parse time?), using macros that take in an existing expression and return a new expression to be spliced into the code before compilation. See http://docs.julialang.org/en/latest/manual/metaprogramming/ for details.

Mathematica doesn't make a lot of distinction between parse time, compile time, or evaluation time. You transform code any time you want to, using the same pattern matching replacement rules that you use to get anything done at all.

I hope some of this is helpful. You've asked a very broad question, and it's difficult to figure out what's relevant in a summary. It's a bit like trying to answer the question "How is Brazil different from Japan" or something like that.

[Mike Innes]

I think what this question boils down to is this: All else being equal (performance, price, support), which language is ultimately nicer to program in?

Mathematica is a fantastic - if not the best around - DSL for symbolic maths. It's term-rewriting paradigm is pretty much perfectly suited what it does, so if you're using it for quick equation plots or to cheat on your calculus homework, don't hold your breath waiting for a replacement. It also ends up having what looks a lot like Julia's multiple dispatch on steroids; you can match not just on type, but also on internal structure, or even the unevaluated expression or the function being called itself. This is enormously powerful; you can implement a fully-functioning dictionary type in seven lines of Mathematica, and it might not be fast but it's beautifully declarative. So, if you're looking for Julia to have some killer feature that makes it more powerful than Mathematica, you probably won't find one.

But. But. As cool as some of Mathematica's features are, fundamentally it's a language designed to let non-programmers write one-liners. And unfortunately, what are great design decisions in that context fall flat outside of it. For example, its syntax - writing S-Expressions as function calls is mostly great, until you have to write control flow statements and variable bindings as if they were function calls, which gets old fast. The syntax needs to either be simpler (a la Clojure) or more helpful (a la Julia) IMHO. Also, holding arguments, blurring the line between code and expressions; all great for short-term usability, but all that magic under the surface ends up being a lot of conceptual overhead for anything complex. Symbolic programming with no syntactical overhead is a great feature one percent of the time, but it gets in the way the other ninety-nine.

Some points for Julia: firstly, interop. You can import a C library and call it really easily; same for Python and soon Java. Also, Julia's code is generally easier to reason about than Mathematica's, especially for writing macros; there's no magic going on where you don't expect it. What's great about Julia is that despite this, it's still really powerful (thanks to multiple dispatch etc.). Also, it's more straightforward to generate and evaluate code in Julia, which is often useful. For these reasons, Julia would be my language of choice even if Mathematica was just as fast/free/whatever.

Last point: the language's approach to types has little to do with the presence/absence of a compiler. Yes, the Julia implementation is compiled, but this isn't about implementations, right? Both Julia and Mathematica are dynamically, strongly typed (not untyped - everything in Mathematica has a type, accessible via Head[]). Anyway, there's nothing stopping you from using lists and maps to represent your data, just as you would in Mathematica, and avoiding using types altogether. Persistent.jl and Lazy.jl give strong support for functional programming, so you're not going to be missing out. And you can get rid of code repetition / boilerplate by generating and evaluating code as above.

Oh, and there's no typo in that definition - Expr.typ will be dynamically typed, or equivalently have type Any.

Hope this helps.

[Jason Merrill]

Let's keep the conversation on the list. That way, people who know more about Julia than I do can tell me when I'm wrong.

On Sat, Jan 25, 2014 at 1:29 AM, Акатер Дима <...> wrote:

Thank you.

> The biggest advantage of Julia over Mathematica is that Julia tries
> to make its semantics obvious enough that you can reason about performance.

I believe this to be the matter of particular implementation, not related to the core language. Mathematica is closed, so users mainly can't reason about performance merely because they can't investigate the source code. So, from the following point…

> The biggest advantage of Julia over Mathematica is that Julia tries to make its semantics obvious enough that you can reason about performance.

…could you elaborate on how is this related to semantics? Do you suppose Disassemble symbol is impossible in a language like Wolfram's due to its semantics? Or were you not really referring to the core language here?

You're right, my comment about semantics was kind of vague. But it isn't "just an implementation issue." It's also a design/philosophy issue. What I was trying to express is that it's fairly straightforward to write low level code in Julia that maps in a simple way to the machine code that will actually be executed. You really can't say the same about Mathematica's core language. They do have facilities for compiling functions for particular types, or representing C symbolically, but those are far from the most obvious way to use the language.

You can find lots of concrete examples on the Mathematica mailing list. About once a month, someone writes a "what is the fastest way to do x" post, where "x" is some reasonably simple low level thing. Here's a random one I just found:

https://groups.google.com/d/topic/comp.soft-sys.math.mathematica/uiMFIOus6KU/discussion

They're discussing fast ways to count how many elements of a list fall in a particular range. The high level functions like "Count" are relatively slow compared to things like

  mma> data = RandomReal[1.,1*^7]; min = .2; max = .3;
  mma> Total@Unitize@Clip[data,{min,max},{0,0}]

I claim that it takes *a lot* of experience to know that that is the code that is going to be fast, compared to the other 15 approaches people bring up there, because the mapping between Mathematica's core constructs and the machine's core constructs is far more complicated and indirect than for Julia.

In contrast, it doesn't take deep familiarity with Julia's standard library to come up with about the fastest way to write this operation.

  julia> function count_range(arr, min, max)
              count = 0
              for elt in arr
                if min < elt < max count += 1 end
              end
              count
            end

It takes more than one line to write, but it's *obvious*. My Mathematica license is expired these days, so I can't run the benchmark, but I bet it also smokes the fast solution in Mathematica.

Now you might claim that this is an implementation detail, and that with a Sufficiently Smart Compiler, Mathematica could generate code that's just as fast as Julia. But because of Julia's language design, it doesn't need a Sufficiently Smart Compiler--it just needs a Smarter Than Many But Still Completely Tractable Compiler.

Now you can write for loops in Mathematica too, but they often aren't that fast. Why? I don't really know, but I'm sure it has to do with Mathematica "doing the right thing" for all kinds of complicated, possibly symbolic, constructs that you might put inside the for loop; in other words, complicated semantics.
 

> The most important thing the two languages have in common is that (almost?) all of the syntax maps to expressions

This is one of the most interesting parts. How does type declaration in Julia map to an expression? What can users do with type declarations, as standalone objects? “RTFM” would be OK answer but I'd really prefer a discussion. :-) Does “quote type […] end end” work? Is there a way to investigate and edit syntax tree directly? manual/metaprogramming does not seem to address these questions.

Maybe someone else can weight in here, but I'm inclined to say RTFM. Then read the implementation of some macros in the standard library.

> Does “quote type […] end end” work?

Yes... try it. You can step through the pieces of the resulting expression by looking at the head and the args of the returned expression, and then looking at the head and the args of all the args, etc. recursively.

[Johan Sigfrids]

On Saturday, January 25, 2014 9:24:17 PM UTC+2, Jason Merrill wrote: 

  mma> data = RandomReal[1.,1*^7]; min = .2; max = .3;

  mma> Total@Unitize@Clip[data,{min,max},{0,0}]

I claim that it takes *a lot* of experience to know that that is the code that is going to be fast, compared to the other 15 approaches people bring up there, because the mapping between Mathematica's core constructs and the machine's core constructs is far more complicated and indirect than for Julia.

In contrast, it doesn't take deep familiarity with Julia's standard library to come up with about the fastest way to write this operation.

  julia> function count_range(arr, min, max)
              count = 0
              for elt in arr
                if min < elt < max count += 1 end
              end
              count
            end

It takes more than one line to write, but it's *obvious*. My Mathematica license is expired these days, so I can't run the benchmark, but I bet it also smokes the fast solution in Mathematica.

Having a Mathematica license and being curious I compared them. The Julia version is roughly 10x faster than the Mathematica version. 

[Knud Sørensen]

Here is a video demo of wolfram.

http://blog.wolfram.com/2014/02/24/starting-to-demo-the-wolfram-language/

[Tony Kelman]

There's a major difference in philosophy in that much of the high-level functionality in Mathematica is hidden in internal logic that is deliberately difficult for users to dive into. For example, from http://reference.wolfram.com/mathematica/tutorial/SomeNotesOnInternalImplementation.html#3826, "The code for NDSolve and related functions is about 1400 pages long." Profiling the choices Mathematica's Kernel decides to make when executing your code is almost impossible. It has some great well-developed algorithms all built in, but you have to trust it's making the best decisions automatically or do your best to find the limited set of options available to try to guide its behavior.

On the flipside, and this isn't a language feature as much as a very well-implemented functionality, is Manipulate[]. It is wonderfully simple to set up and deploy interactive data exploration using Mathematica - dragging a few sliders around can be a great way to explore parametric sensitivities in some problems. If you've never seen this in action before, have a look around demonstrations.wolfram.com for some examples. Julia has some catching up to do here, but I'm confident it will happen in time.

[Steven G. Johnson]

On Friday, February 28, 2014 2:13:30 PM UTC-5, Tony Kelman wrote:

On the flipside, and this isn't a language feature as much as a very well-implemented functionality, is Manipulate[]. It is wonderfully simple to set up and deploy interactive data exploration using Mathematica - dragging a few sliders around can be a great way to explore parametric sensitivities in some problems. If you've never seen this in action before, have a look around demonstrations.wolfram.com for some examples. Julia has some catching up to do here, but I'm confident it will happen in time.

This should be coming.  IPython just added protocol support precisely to support this sort of thing, which we will pick up in IJulia:

   https://github.com/ipython/ipython/pull/4195

[johan...@gmail.com]

I compared with Mathematica 9. Total@Unitize@Clip[data,{min,max},{0,0}] was for me roughly 3x slower than the Julia version; which sounds reasonable since Total, Unitize and Clip run once though the data. In Mathematica 9 you also have the option to compile to C, which then runs as fast as the Julia version:

$CompilationTarget = "C";

f = Compile[{{x, _Real, 1}, {min, _Real}, {max, _Real}}, 

  Module[{count = 0},

   Do[If[min <= x[[i]] <= max, count++], {i, Length@x}]; count], 

  "RuntimeOptions" -> "Speed"];

[Zahirul ALAM]

I have been using Mathematica regularly for five years now and I am a new user of Julia. As a first serious project I have used Julia to simulate a nonlinear optical pulse propagation problem. I originally have written the codes in Mathematica. The simulation time in Julia was roughly eight times smaller than Mathematica. I am sure I have missed many Julia tricks to make it even faster. In mathematica Table or ParallelTable are quite fast. I am disappointed that with the new version 10 Wolfram has not added any more parallel computation details. So for symbolic manipulation or doing a quick plots mathematica is unbeatable. Writing some basic parallel codes are also as trivial as it gets. 

One feature I would like to see from IJulia may be is that the input of greek and mathematical symbol in way that looks natural, e.g. using subscript, in division, integration etc as way to input. This will definitely be a significant improvement IMHO. 

second feature is to be able to plot a function in a way one can do in Mathematica. Plotting packages for Julia does this in very limited way (unless I am missing something)

[Stefan Karpinski]

On Mon, Jul 21, 2014 at 9:55 AM, Zahirul ALAM <zahiru...@gmail.com> wrote:

One feature I would like to see from IJulia may be is that the input of greek and mathematical symbol in way that looks natural, e.g. using subscript, in division, integration etc as way to input. This will definitely be a significant improvement IMHO. 

You can do Unicode input using LaTeX codes in IJulia by typing, e.g. \alpha<tab>, which will be turned into a Unicode α. That's not as fancy as what you can do in Mathematica, but I'm not sure we want to go there. I find editing Mathematica code pretty irritating and it's not that much better looking except for the "traditional" output mode, which you cannot use as an input format anyway.

second feature is to be able to plot a function in a way one can do in Mathematica. Plotting packages for Julia does this in very limited way (unless I am missing something)

Have you met Gadfly?

[Zahirul ALAM]

Thanks Stefan. I did find out that I can type \alpha<tab> for Unicode α. My point was more to do with the "traditional" input / output mode. 

btw if I am not mistaken I think in markup mode the \alpha<tab> does not work. I guess not even auto complete works in markup mode when pressed tab. May be I am doing it wrong. However it works just fine once the block is "compiled". But I think that has nothing to do with IJulia.

I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is indeed very pretty. It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. 

[Stefan Karpinski]

Gadfly has recently gotten the ability to do contour plots unless I'm mistaken, so hopefully that helps a bit. The \alpha<tab> business is actually a tab completion trick implemented in the Julia completion backend, rather than in the IJulia/IPython/Jupyter frontend. In markdown mode, you can use actual LaTeX input – as in $\alpha$.

[Tomas Lycken]

> It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved.

There is, actually, some functionality for contour and density plot already, but all the nuts and bolts aren't really tightened yet, and I don't know if the progress so far has been documented at all, but if you have a function `f = (x,y) -> z(x,y)`, you can do `plot(f, xmin, xmax, ymin, ymax)` to get a nice contour plot. Support for contour plots of matrices is under construction - take a look at [#293](https://github.com/dcjones/Gadfly.jl/issues/293) for more details.

Density plots is sort-of implemented through [Geom.rectbin](http://dcjones.github.io/Gadfly.jl/geom_rectbin.html) which may or may not be what you need.

// T

[Viral Shah]

On Tuesday, July 22, 2014 2:39:31 AM UTC+5:30, Zahirul ALAM wrote:

I have indeed met Gadfly. I had Gadfly in mind when I wrote that. It is indeed very pretty. It is only for 2-D plotting, does not do contour or density plot ( two types I tend to use the most). I am sure it will only get improved. 

You could also look at PyPlot, which uses Matplotlib.

-viral

[Zahirul ALAM]

Thanks Stefan, Tomas and Viral. 

Stefan and Tomas: Contourplot definitely looks very pretty in gadfly.  

Tomas: But I am afraid the plot contains extra lines which some of you have already pointed to be aesthetic issue. It is not entirely clear how to use the group aesthetic to fix it. I will read on. 

Viral: I am currently using the PyPlot package.

btw: on this regard, I am yet to  a straight forward manner to do find dual Y axis or dual X axis plot in either Mathematica, Matlab, Matplotlib, or Maple. May be in Gadfly this is a feature that can be built in. 

[Darwin Darakananda]

If it's possible, do you mind showing the function you were plotting that lead to the extra lines in Gadfly?  The current master should already be using the `group` aesthetic for contour lines.

[Daniel George]

It gets even faster if you make the slight change shown below in red:

$CompilationTarget = "C";

f = Compile[{{x, _Real, 1}, {min, _Real}, {max, _Real}}, 

  Module[{count = 0},

   Do[If[min <= i <= max, count++], {i, x}]; count], 

  "RuntimeOptions" -> "Speed"];

[lapeyre....@gmail.com]

On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:

It's mentioned here http://julialang.org/blog/2012/02/why-we-created-julia/ that Mathematica was one of the programs that inspired Julia. How does Julia compare to Mathematica's language?

To make the question more specific,

- it's about languages, not implementations, so Mathematica's FrontEnd capabilities are irrelevant (and it's also not about “which one is faster”)
- it's not about free vs non-free
- it's not about communities and support
- it's not about anything related to OOP (feel free to write about, sure, but I will probably be very passive in discussions concerning OOP)

- it's about the languages' most high-level features, like meta-programming, macros, interactions with other languages and the way it treats types

For example, Wolfram language (which is now the name of Mma's core language), implements meta-programming capabilities via term-rewriting and Hold. It provides some foreign-language interfaces via MathLink (which could be WolframLink already) and also has SymbolicC. It is untyped and proud of it; types can be implemented easily but they are of little practical need in the absence of compiler.
 

- it's also about the languages' most distinctive features: are there things Julia has that WL does not have? (Which means adding them to WL would require reimplementing Julia in WL, much in spirit of Greenspun's tenth rule.)

    I think it is easier to go the other direction and implement something like Mma in Julia. This is what I have done here:

    https://github.com/jlapeyre/SJulia.jl

I think Julia is uniquely well suited for implementing a Mma-like language.  I agree with the comment below that Mma is designed in part to appeal to non-programmers. A large part of its appeal is that it collects a lot of mathematics functionality that is hard to find elsewhere... all kinds of algorithms and special functions. Many of these can be used with one or a few lines of code. I kept the non-programmer in mind when writing SJulia.

   The question of what kind of type system a language has is somewhat polemic. In some sense, Mma is untyped. There is no hierarchy in expressions; they all have a head and arguments. I think hierarchies of mathematical objects are not well represented by hierarchies of programming language types. Which hierarchy a particular mathematical object belongs to and its exact definition is very fluid. Languages like Mma that attach no inherent meaning to expressions are well suited for mathematics for scientists and engineers. A matrix is an expression with head 'List' each of whose elements is an expression of fixed length with head 'List'.  Still types creep into Mma in various ways.

Some people prefer types to play a larger role in symbolic computation. For instance:

http://www.sympy.org/en/index.html

https://github.com/jverzani/SymPy.jl

http://nemocas.org/

Whether to use types depends in part on the domain of the language.  But even for rather general math capabilities, language design determines in part the role of types. Sympy (in python and Julia) aim to add symbolic computation capability to Julia.  They are more 'typed' than Mma and SJulia. But, it seems that python sympy is hybrid in this respect and also supports generic expressions.
 

[Chris Rackauckas]

I think types+dispatch is the right way to go. It's what Julia is founded upon, and it's what leads to really fast computations. A fast type/dispatch based symbolic system for Julia and in pure Julia would be a huge asset. And while the post said not to mention the front end, when talking about Mathematica you have to talk about the front end. The only reason why I use it over other CAS' is because that notebook looks like math. Until someone implements something like that in Julia, I will always have a reason to open up Mathematica.

[Erik Schnetter]

One of the strengths of Mathematica's pattern matching system is the ability for structural matching, e.g. to match a list where the second element is a real number. This is something that is not (yet?) possible with Julia's dispatch. It would be nice to be able to write something like

```Julia

function f(x::Expr where x.args::Tuple{T, Real, ...})

```

(with a more concise syntax) to mimic this.

-erik

--

Erik Schnetter <schn...@gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

[Steven G. Johnson]

On Thursday, September 1, 2016 at 8:25:27 PM UTC-4, Erik Schnetter wrote:

One of the strengths of Mathematica's pattern matching system is the ability for structural matching, e.g. to match a list where the second element is a real number. This is something that is not (yet?) possible with Julia's dispatch.

You can do it (see e.g. Match.jl), just not at compile time, because the elements of an array are not known at compile time, nor are the types of the elements of an Array{Any}.

[Andrew Dabrowski]

But what about nested pattern matching, or destructuring, isn't that much easier in Mathematica than Julia? For example defining a function of two lists by
f[{w_,x_}, {y_,z_}]:=x y/(w+z).

I remember reading the Julia manifesto a few years ago, where the stated goal was to create a single computing language that would replace Fortran, scipy, Mathematica, Matlab, etc. simultaneously. I thought at the time that it sounded nuts.

Can we all agree now that it was, in fact, nuts?

[Chris Rackauckas]

Someone can make a macro for Mathematica's pattern matching syntax.

[lapeyre....@gmail.com]

This is already implemented in SJulia:

  sjulia 1> f([w_,x_], [y_,z_]) := x * y/(w+z)

  sjulia 2> f([a,b],[c,d])

  Out(2) = b*c*((a + d)^(-1))

I have implemented several of Mma's pattern matching features. But, Mma's pattern matching is sophisticated. I have not implemented, for instance, associative-commutative matching, which Mma considers "structural" matching.  I experimented a bit with using SJulia features from julia.  Without looking at it now, I guess it would take some work to access the pattern matching.

Maybe you can also do this kind of destructuring matching with this

 https://github.com/toivoh/PatternDispatch.jl

which aims to add pattern matching to method dispatch.

[lapeyre....@gmail.com]

I was told that SJulia is broken on recent versions of Julia.
This is fixed now. It should work with most versions of 0.4, 0.5, and 0.6

https://github.com/jlapeyre/SJulia.jl