With that said, I find the lengths to which Mathematica takes pattern-matching fascinating. There's something beautiful about having
Fold[f, 0, Range[1, 5]]
f[f[f[f[f[0, 1], 2], 3], 4], 5]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.
Richard Fateman's reviews of Mathematica are at:
http://www.cs.berkeley.edu/~fateman/papers/mma.pdf http://www.cs.berkeley.edu/~fateman/papers/mma6rev.pdf
MockMMA is at http://www.cs.berkeley.edu/~fateman/mma1.6/
The most interesting discussions to me are in the first link: specifically, the limitations surrounding the use of pattern matching for the type system, the limitation of limiting UpValues to a single depth, and the analysis of the 'infinite' evaluation model.