Launching Today: Mathematica Online
blog.wolfram.com
blog.wolfram.com
http://reference.wolfram.com/language/tutorial/WhyYouDoNotUs...
The biggest missing piece it's missing is the data used by Alpha. It's missing other things as well, but it's a start.
Especially since the guy only wrote a fraction of the "Wolfram System" (A NEW KIND OF SYSTEM!!!).
At it's core Mathematica is actually a rule rewriting engine. but except for more heavyweight uses you can view it as simply a Lisp with the worlds best standard library.
The jungle of function-definition-like expressions and the scoping constructs were particularly bad, but I also found that the language & the culture made it far too difficult to write readable code. (I find my eyes glazing over almost immediately when I try to read the Wolfram blog: it's so very hard for me to see the structure of the code.) Perhaps once you become happy with the core principles of the language all of this gets better, but I spent quite a lot of time thinking it and never really got there.
Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow.
Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience.
Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.)
The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
My experience with Mathematica is sort of like my experience with Fortran: if you stick to the sorts of problems for which it was developed (hard-core numerics for Fortran, symbolic manipulations for Mathematica), it's great, but if you want to do something more general you're in for a rough time.
(I understand Fortran's gotten progressively better, but I don't have any experience with anything after 95, and even that was a codebase heavily inflected with 77.)
Can you give an example of bonkers-ness?
The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0].
In fact the suite of functions you have available for basic list and hashmap manipulation is probably one of the richest among languages in this space.
Btw, its called a "term rewriting system", not a "rule rewriting engine".
> Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow.
It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops. But you can use Compile[1] if you want to write fast procedural-style code. We also do some amount of JIT compilation.
> Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience.
Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years?
> Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.)
> The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3].
Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing. The video helps a bit, and there is the fast introduction for programmers [4].
[0] http://reference.wolfram.com/language/guide/FunctionalProgra...
[1] http://reference.wolfram.com/language/ref/Compile.html
[2] http://reference.wolfram.com/language/ref/Eigensystem
[3] http://www.wolframalpha.com/facebook/
[4] http://www.wolfram.com/language/fast-introduction-for-progra...
Maybe :-)---this was a year and a half ago, or more. I do remember spending a fair amount of time trying to wrap my head around the implications of the difference between `f[x] = x^2` and `f[x_] = x^2`, and the differences between "Module", "Block", and "With". I also had a hard time with closures & symbols---I was trying use something not unlike the bank-account example from SICP (https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.htm...) to cache some intermediate computations, and it got very messy very quickly.
Now I recognize that this is in no way idiomatic Mathematica code, and I'm sure there is a nice Mathematica-y way to achieve this, but that's sort of my point. I have a problem, think "Aha! I know exactly how to deal with this in Scheme!", try to translate the Scheme solution into Mathematica, and either fail miserably or spend way too much time trying to figure out how to persuade Mathematica to do what I want. (I should perhaps admit that when I hear "Lisp" I think Scheme and to a certain extent CL, with lexical scoping, as opposed to elisp, with dynamic scoping. This is a flaw in my thinking I've never really gotten around to rectifying.)
> The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0].
Yeah, those were pretty natural.
> Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing.
This is important, I think, but I also think the problem's less in your documentation than in how I "learned" Mathematica. I got started using Mathematica for things like messy integrals, or differentiating and then simplifying some huge expression. Something comes up in a problem set, I try three or four times to do it by hand and always lose signs/factors/whatever, and then farm it out to Mathematica; as I gradually started doing more and more, I kept just porting Lisp experience, and this always worked just barely well enough that I wasn't forced to learn Mathematica on its own terms.
I suspect if I had thought about it as "basically m4 with a crazy-awesome standard library", rather than "basically Scheme with a crazy-awesome standard library", I might have been happier, but ultimately I needed (need) to recognize that Mathematica is its own thing, with its own strengths, weaknesses, and fundamental metaphors.
> Btw, its called a "term rewriting system", not a "rule rewriting engine".
Ack. Thanks; I'll try to bear that in mind.
> Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years?
No! You're right, that would be a terrible idea. I was using Eigensystem; in Julia I farmed it out to LAPACK via eigs(). My problem was in setting up the matrix to be diagonalized. The state space had something like seven degrees of freedom (four two-dimensional and three with arbitrary dimensions), so I was calculating matrix elements for up to something like N = 10^5 basis states. (There were some tricks to pull so I was iterating through O(N) states, not O(N^2).)
Ultimately, for sufficiently large N, the diagonalization is going to take much longer than the setup, just because the scaling's worse. For small-ish N, though, the setup was interminable, and those small-N test cases are precisely where I need to be able to move quickly when I'm trying to figure out which stupidity I perpetrated this time.
> It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops.
Yeah, no kidding. This was a classic Fortran-style problem, which is why I feel kind of stupid for having even tried to do it in Mathematica.
>> The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
>That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3].
Fair enough. And I have a very smart friend who has sworn by Mathematica for years (and just spent some time working for you guys)---maybe it really is a combination of how I approach Mathematica, the types of problems I've tried to solve in it, and the fact that de gustibus non disputandum. I can't shake the feeling, though, that I'd want to run away very quickly from a large Mathematica/WL project like Wolfram|Alpha.
Edit: missing newline, missing )
That's a really good example: you'd have to find the tutorial [0] to know what to do. And we could make that job easier by detecting your probably incorrect use of = instead of := and giving you a "I see you're trying to define a function" kind of deal. Of course people hated Clippy, so we have to tread carefully with that kind of thing :)
> This is important, I think, but I also think the problem's less in your documentation than in how I "learned" Mathematica.
Yes, I think you hit the nail on the head with this paragraph. It is possible to 'accrete' tricks in a way that potentially blocks you from having a holistic knowledge of the language. The workflows for symbolic manipulation, which involve lots of global state and symbols representing variables, is probably a prime culprit.
> My problem was in setting up the matrix to be diagonalized. The state space had something like seven degrees of freedom (four two-dimensional and three with arbitrary dimensions), so I was calculating matrix elements for up to something like N = 10^5 basis states.
That makes more sense. There might have been higher level ways to do this using functions like Array and Table, but perhaps not. And Julia is a really interesting language, I think we can learn a lot from them.
> I can't shake the feeling, though, that I'd want to run away very quickly from a large Mathematica/WL project like Wolfram|Alpha.
Huge codebases in any language get hairy. I'd say we're on a par with C++ in that respect (meaning: not very good, but workable).
Modern languages have had some innovations with clean package systems and API boundaries (though the ML family showed the way), so it's perhaps good we're still waiting to modernize our package system. Plus, I think we have a chance in the next year or two to really leapfrog other languages with some amazing static analysis tools.
Still in the lab, though :)
[0] http://reference.wolfram.com/language/tutorial/ImmediateAndD...
[1] http://reference.wolfram.com/language/ref/Array.html, http://reference.wolfram.com/language/ref/Table.html
Oh, man, that bit me so many times, especially when it had to interact with some kind of scoping trick. I read that tutorial (or the equivalent from before the WL), and never really got good intuition for how immediate & delayed evaluation worked and when to use which.
> There might have been higher level ways to do this using functions like Array and Table, but perhaps not.
I was actually using Table, but I was thinking of it as "iterate over these variables". Table's nice, although every once in a while it would break the picture I had in my head of it as "map-over-cartesian-products".
> Plus, I think we have a chance in the next year or two to really leapfrog other languages with some amazing static analysis tools.
Great! Another beef I have with Mathematica (and Scheme, for that matter) is that it doesn't have types: since I learned bits and pieces of Haskell and started using Julia seriously, I've come to love the way a type system can save me from my own stupidity. This is definitely a matter of taste, though.
The compile function spec -as little as is there - does not make me happy as a Lisp programmer. The compile function has only very limited capabilities...
From the doc:
> Compiled code does not handle numerical precision and local variables in the same way as ordinary Wolfram Language code.
This is a huge warning sign. It does not even say HOW it works differently. Mathematica from a language implementation point is stuck in the 70s... They have fancy stuff on top, but the basic language looks broken. The Lisp and FP communities faced these implementation and semantics problems (like lexical binding, having an interpreter and compiler with same semantics, implementing optimizing compilers for the full language, ...) in the 70s and 80s. Scheme, ML and other languages showed how this stuff should be specified and implemented.
That inference is not correct. That doc is one of many hundreds of 'guide pages' that collect together various functions by domain/concern. It's not meant to be the exhaustive proof of "WL is a modern functional programming language with all the features you expect".
> I fear these are all dirty hacks and performing very poorly.
Why do you fear that? From my experience we're about on a par with CPython.
> Why isn't it better specified?
There is a gargantuan library of documentation, available both offline and online, that covers every area of the language, including core language areas like scoping.
> Why isn't it better specified? Because Wolfram wants to prevent competition?
We don't need to obscure how the language works to prevent competition, we can rely on the fact that it would take hundreds of engineers (with a full spectrum of domain knowledge) a decade to replicate the kind of functionality we have.
The exact thing you seem to want, which is "what does a LISP programmer need to know about WL?" doesn't exist, but perhaps it should! It might make sense to add Block, Module, and With to the functional programming page, though the Scoping Constructs guide [1] is the place to start understanding our scoping.
> > Compiled code does not handle numerical precision and local variables in the same way as ordinary Wolfram Language code. > This is a huge warning sign.
Again, you seem to have little patience for documentation. The notes in the function page are a summary of salient points, rather than an essay about every detail. The tutorial goes into more depth [2].
And specifically: precision tracking is something almost no-one else does. BLAS can't do it -- so yes, the semantics have to change if you want speed. Lisp and the FP community would have the same problem if they represented quantities with the generality we do.
[1] http://reference.wolfram.com/language/guide/ScopingConstruct...
[2] http://reference.wolfram.com/language/tutorial/CompilingWolf...
I would want a spec of the basics of the language. Not a collection of vague statements and some examples.
> The tutorial goes into more depth [2].
A tutorial goes into more depth than the main documentation? Really?
If you read the tutorial, you see that the compiler is far from being able what a modern compiler for Lisp, SML, OCAML or Haskell does. The Wolfram compiler is mostly there to speed up some simple numeric processing. As you can see the parameters need to be numbers or 'logical variables'.
> compilation can speed up execution by a factor as large as 20.
Which is completely vague...
> For more complicated functions, such as BesselK or Eigenvalues, most of the computation time is spent executing internal Wolfram Language algorithms, on which compilation has no effect.
That more or less shows how primitive the compiler is.
> Compile can handle approximate real numbers that have machine precision, but it cannot handle arbitrary‐precision numbers
...
> An important feature of Compile is that it can handle not only mathematical expressions, but also various simple Wolfram Language programs.
Wow.
> Thus, for example, Compile can handle conditionals and control flow structures.
Really.
But as I said before, CPython is a close analogy for where we are at. What we don't have yet is the equivalent of PyPy. Still, if you were to make this kind of dismissive critique against the maintainers of CPython, I think most people would find it kind of silly.
Also, one should note that this documentation was written during an era when perhaps most of Mathematica's user base were people doing math, for which the primary use for compilation was things like plotting, numeric solving, and so on. The language of the tutorial reflects that heritage. At this point we should probably rewrite it.
(I also want an open-source implementation, but it would seem that isn't on the table.)
I can recommend the book by Paul Welling, as well as the books by Michael Trott (very meandering).
Just funking things up in the notebook is the most fun I've been having in a long time. You just get sucked into trying more and more things, adding manipulates around it, playing some more, taking the output image and running image processing on it then converting it to a mesh on which you solve differential equations.
The notebook is a literate programming document. It contains my thoughts and process for creating an algorithm/piece of code along with tests and examples. This is very, very different from how people traditionally "program".
However, Mathematica has some very real, very strong deficiencies if you wanted to build an application end-to-end within it. It's dynamically typed, with everything-is-a-list mentality. So you will get type errors.
Unit testing (let alone combinator libraries like quick check) are only available at the higher price levels.
Warning personal opinions ahead!! Wolfram employees often have have strange views on how software is built outside of Wolfram Inc. Unit tests are alien, and type checking or datatypes (Say, to make sure that order your fancy Mathematica based trading system is going to make is sane) are seen as only things dumb rails programmers need. Rather than tools to make developers more powerful.
I would honestly recommend every programmer learn Mathematica. I'm sure they'll find that they can aim far higher when they have the right tools behind them. It's the same distance again from Python/Ruby as Python/Ruby are from C. Probably more.
Actually, this is now available for everyone, something I advocated for. VerificationTest and TestReport are the key functions there.
Good implicit suggestion about QuickCheck.
We've supported unit testing in our Eclipse plugin for years, and with V10 brought the MUnit package into the System context with a redesign of the essential functions.
I would absolutely adore seeing smart check implemented in Mathematica. Please make it so.
A coworker is a former Wolfram employee who can explore data analysis in minutes in what it would take me hours/days to do in python.
Over the last year, as I incidentally got interested in Haskell and Lambda calculus, it dawned on my that Mathematica's language is built for functional programming. It felt like I'd just managed to find the light-switch. Now that I understand, it all makes sense when somebody says that all Mathematica essentially does is search and replace. I think this is in the spirit of a model of computation called [Markov algorithms](https://en.wikipedia.org/wiki/Markov_algorithm).
IMO they should just use a cookie to let you try it out for a couple of days, and then tell you that you need to buy the product. It's easy to circumvent, but a ton of people would just choose to pay for it.
I also think that they should have some kind of student pricing. Many students couldn't afford $15/month, but they might be able to afford $15/year.
Except Wolfram should just restore Wolfram Alpha to its once free glory (instead of the annoying nagware that it's become) and also offer this Wolfram cloud stuff at a reduced price.
The end goal for them should be to convince people that they need to purchase Mathematica. Pricing at $15/month means they're only really attracting existing Mathematica users who want the convenience of the cloud when they're away from their primary machine.
is all I get. Is it working for anyone else?
edit: sometimes a reload shows it for a second, then it says "session expiring" and the error page shows up again