The issue with speed I have comes from the heavy numerical use I'm putting it to: strongly coupled nonlinear differential equations. What worries me is that NDSolve is 1400 pages long, written mostly in C, and relies heavily upon the compiler framework underneath, but it still takes minutes to evaluate what should in most cases take seconds. I suspect this is partly because the flexibility of the language makes it difficult to optimize during compilation, though of course it's difficult to tell from my vantage.
It would be beautiful, however, if NDSolve were implemented in the language itself. If the speed is sufficient for numerical code, then it should be sufficient to write that numerical code in the Mathematica language, and rely on compilation for a speed up. But that path hasn't been taken. While the compiler is immature, it seems that as a company it would make sense to adopt this strategy rather than relying mostly on a monolithic kernel built in C.
Circa MMA 2, Mathematica's kernel code was about 350,000 lines of C, whereas Maple had a Kernel of only about 20,000, with most of the routines written in Maple itself.
Pattern matching is wonderfully beautiful as a core concept, though.
It would be beautiful, however, if NDSolve were implemented in the language itself. If the speed is sufficient for numerical code, then it should be sufficient to write that numerical code in the Mathematica language, and rely on compilation for a speed up. But that path hasn't been taken. While the compiler is immature, it seems that as a company it would make sense to adopt this strategy rather than relying mostly on a monolithic kernel built in C.
Circa MMA 2, Mathematica's kernel code was about 350,000 lines of C, whereas Maple had a Kernel of only about 20,000, with most of the routines written in Maple itself.
Pattern matching is wonderfully beautiful as a core concept, though.