Author: Sal Mangano
Author: Sal Mangano
Mathematica is a wonderful tool and over the years I have used it for an incredibly wide range of projects and tasks. However, for most of them programming has been a secondary issue with worksheet construction being the main way of building functionality.
Whenever I have had to work with Mathematica as a programming system the main problem I have had is in deciding how to treat it - is it object oriented, is it functional, is it a declaritive rule based system or is it just a scripting language? The problem is that it is quite capable of being treated as any of the above.
So when I approached this book "what programming style?" was my first question.
The answer is that the author takes a loose functional approach to coding, which I agree does suit Mathematica and the type of problems it is generally applied to better than most.
My second major concern was would the author value clarity or trickery. I was worried by the examples at the start of the book that demonstrated how powerful a language Mathematic was by showing off single line unintelligible functions. Perhaps this was just a starting ploy?
And indeed once the book got started a concern for the essential virtues of clarity and maintainability started to come to the fore. The author discusses the various programming styles and opts for functional. Then the book goes on to explore the functional elements of Mathematica and here the trouble starts. There are many occasions when a few lines of code are presented and you are expected to understand them with minimal explanation.
Sometimes this is reasonable as the code is an illustration of an idea being introduced. Other times it is simply impossible without consulting another book or the manual. For example on page 33 the map-apply idiom is introduced but it uses the concept of a slot - an idea which is not introduced on the page lthough the index says it is. As a result you have to guess what the code does. This sort of presentation is repeated in other examples and understanding what is going on is often very difficult. The quality of the code also starts to be very variable with difficult to follow compact single line functional code.
The range of recipes is very wide: Data structures, rule-based programming, string and text processing, 2D graphics, 3D graphics, Image processing, audio, algebra, calculus, statistics, science and engineering, financial, the user interface, parallel computation, cross-language use, debugging and testing. All of the examples are simple to intermediate in approach but how far the examples go depends on the subject matter.
There is no tensor algebra, no abstract algebra, limited exploration of differential equations, almost nothing on integrals, and so on. The quality of the code varies greatly as already mentioned and most of them can be found in the Mathematica book and elsewhere.
This is a difficult book to sum up. It is a useful source of Mathematica examples but the quality of the explanations and in some cases clarity of code lets it down in a big way. The final conclusion is that while this isn't a complete failure it could have been much better.
|Last Updated ( Tuesday, 31 August 2010 )|