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. On Thursday, January 23, 2014 2:47:11 PM UTC-8, Акатер Дима 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.) > > 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} > typend > > > 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. >
