The main issue was that generating the tables was extremely slow (~15mins). We solved this by packaging the tables, but when the version of ply changed a table regeneration was forced on our users.
The recursive descent parser was also simpler and significantly more performant.
Are the solver algorithms part of the standard library or part of the execution engine? i.e., are Solve/DSolve/etc. written in plain Mathematica code, or are they special somehow?
This is a great question. I suspect they use hard-coded stuff deep in the math kernel for efficiency. I remember the Mathematica book goes into detail on this, but I don't recall the specifics.
The library is really impressive. I wanted to do some feedback linearization of a system and started encoding the dynamics into Mathematica. I got about halfway done doing it on my own when I discovered there was a built in to do it for me.
Mathematica's value is in the library, not the language. Wolfram etc put a ton of effort into making it do a good job on arbitrary problems. See the Mathematica book for me detail- for example, the root finding stuff is really neat.
When I was at the university[0], we were forbidden to use Caml Light, Lisp or Prolog in our compiler classes, because they would make the exercises too easy and so we wouldn't learn properly.
[0] Haskell was still to be born and we had Miranda instead.
Well, I mean, I understood the sarcasm and it was funny. Part of why it was so funny is because it's true. Haskell is amazing at many things, and one of them certainly is writing toy interpreters.
> This proves, once again, what a world-class, unbeatable tool Haskell is for writing toy interpreters.
This somehow suggest a) that it is not quite exactly really there, where one may want to develop a non-toy interpreter/compiler/... and/or b) that a lot of examples are just toy programs which can be as well developed in any language and one has now seen zillions of those in Haskell and everyone is convinced that Haskell is good for implementing toy interpreters. and/or c) that the quality of the code stays on toy level.
In this case it is a slightly more advanced toy interpreter, but the implementation lacks any information about its architecture, there is no documentation, stuff is hardcoded, etc. It's the typical slightly autistic implementation where there is the code and a some tests...
The real challenge would be to develop a non-toy interpreter/compiler/... Is there Haskell still a world-class, unbeatable tool?
Personally I'm not a Haskell user, but I like that people are writing code in it. Though for such an application I would like to see a bit more effort on the meta-information about the code. You can see that in some (!) Lisp programs, people invest some effort to make them very expressive and readable. Just read the PAIP code/book from Peter Norvig which implements some parts of Macsyma in Common Lisp.
But there is the danger of not being able to really compete for many high-level languages. Lisp had some attempts for actual products in this domain of computer algebra: Macsyma, Reduce and Axiom were the most prominent. The were developed as real products with actual end-users. They failed in the market place against languages with C/C++-based implementations like Mathematica. Though they are still being maintained as open source / free software projects.
Still, I don't agree with the snarky remark of the OP, hence why I wasn't getting it, as there are several uses of Haskell in production.
Besides Microsoft, Facebook and Intel there are quite a few other companies using it in production, specially in financial and insurance sector for data modelling.
I am the other way, I have dabbled quite a few times with Lisp languages, mostly Emacs Lisp, Guile and Clojure.
I am also a big fan of the old Lisp Machines, but having learned FP in Caml Light, my brain got hardwired to ML derived languages.
Use in production - often in-house production - is slightly different than development of a non-toy language implementation or a non-toy application (here an interpreter for a clone of the Mathematica language).
Non-toy computer-algebra applications in Lisp were/are Macsyma/Maxima/Vaxima, Reduce and Axiom. They were real products an end user could buy. There is an extensive amount of literature about Macsyma: http://ftp.math.utah.edu/pub/tex/bib/macsyma.bib
But then one might want to survive in the market place.
Btw., people even use the C64 still in 'production'. ;-)
Well, that's a rule engine embedded into Haskell. Great, but different from a language implementation of the Mathematica language (syntax / parser, ... , interpreter).
Anyway, that what I said above. Inhouse use for special purpose applications.
Just as a note, Norvig switched to Python for nearly all programming. Personally I think this is because nearly any language can do enough interesting things (like implementing an algebra or symbolic math library) but more importantly, far more people want to learn/use Python than lisp.
I am English (and so a natural English speaker) and I read it in the exact same fashion that you did. I think the original poster may have been trying to be sarcastic, (it still isn't clear), but was so subtle about it that they failed for both of us.
Yes, well, anyone can find that out if they care to. The point is the person you replied to was interpreting the original sarcasm, not trying to make a factual statement.
Do you know how many problems can be reduced to writing a toy interpreter? You're much too dismissive of a very useful software engineering technique. (That's if you meant your comment as sarcasm; if it's praise then I'd agree.)
I've written a toy TeX interpreter/macro-expander as my first "large" Haskell program. It really made me think hard about both Haskell and TeX. I think this is a great way to learn two languages at the same time if you already have experience.
Not any more than CPython is a scripting language for C. The Mathematica program is entirely interpenetrated. It does not have access to the underlying Haskell system.
That's a bit of a shame, in some way.
In the same way Hy [0] wraps Lisp's notation style around Python, it would be quite powerful if there was a way to 'wrap' Mathematica around Haskell; being able to combine the two would be interesting (and probably quite powerful).
you can use the Mathematica Kernel C API to make any language interface with mathematica (I did this with Python a long time ago). This typically involves the scripting langauge (or compiled language) invoking Mathematica functions, I;'m not 100% if Mathematica can then call back into Haskell or other language functions via a callback.
It also provides jupyter kernel.
The original author was hired by Wolfram, but the project still lives on!
http://mathics.github.io
Maxima is older than Mathematica and written in LISP. One of its contributors has written MockMMA to implement Mathematica in LISP:
https://people.eecs.berkeley.edu/~fateman/lisp/