Re: Mathematica as a programming language.
- Subject: [mg2973] Re: Mathematica as a programming language.
- From: evans at gte.net (Mark Evans)
- Date: 17 Jan 1996 05:38:31 -0600
- Approved: firstname.lastname@example.org
- Distribution: local
- Newsgroups: wri.mathgroup
- Organization: GTE Intelligent Network Services, GTE INS
- Sender: mj at wri.com
In article <4bg3fg$ob8 at dragonfly.wri.com>, ngjune at ecf.toronto.edu wrote: > I would really like to know why so many people choose Mathematica over > other available programming languages. I'm trying extremely hard to like > it but I still don't know what makes it "the choice of millions of engineers, > scientists, mathematicians, and students". > > Who is going to be impressed by my knowledge of Mathematica? Microsoft, IBM, > and Corel don't care .. I'm not putting down Mathematica, but I'd like to > know who uses it, and why do they prefer it over other languages. My perspective as a traditional programmer is that Mathematica is two nice things at once. First, it is an interactive prototyping environment for algorithms. Results can be immediately plotted, analyzed, modified, and retested. Secondly, it is a vacation home for external object code. By interfacing C algorithms with Mathematica through MathLink, I don't have to worry about GUI issues -- not even a file system. I just get data from MMA, churn it, and return it. Then I can plot it or analyze it from Mathematica directly. The alternative is to either (1) save the data to disk and use another program for analysis (how about MMA?), or (2) look at the data in a runtime debugging window. Most debuggers are just not well equipped for this kind of thing. So C and MathLink is a winning combination when you are writing numerical C algorithms. Also, the transition from Mathematica-based algorithm prototypes to running C code is typically very straightforward. Generally speaking, Mathematica lets me structure data in any way I please. I can toss large arrays around without writing low-level loops. Constructs like Map and MapIndexed enable this. I have done a lot of image processing in Mathematica. I cannot recommed Mathematica as an image processor, but it is a good place to prototype algorithms. Graphics in Mathematica is one of the major draws for me. The open architecture lets you invent new types of graphics without getting your hands dirty in the details of the operating system (i.e., pushing bits around). You tell Mathematica where to draw the points, lines, and polygons, and you're in business. You can overlay custom graphics onto default plots. For example, I use ListDensityPlot to display images, and graphics primitives to produce overlays that reveal the workings of my algorithms. Another example is the commercial Optica package. This package does optical ray tracing and produces excellent graphics showing the whole process from any direction you please because the graphics is Mathematica-based. When you refer to "other available programming languages," I would guess that your concept of a programming language is not quite clear enough. I would distinguish between a real "programming language" like Mathematica and a "macro language" like you find in many other programs (e.g., Spyglass Transform). Sometimes vendors turbocharge a macro language and call it a programming language. A "macro language" manipulates sets of fixed, hard-wired routines that in turn operate on your data. A true "programming language" puts you in direct contact with your data. You can use built-in routines or write your own from scratch. All the primitives you could desire lay at your fingertips. If you pick up one of the Mathematica programming books, you will discover that Mathematica supports all kinds of programming paradigms simultaneously: procedural, object-oriented, relational, functional. The selection is up to you. This flexibility is a unique feature of the product. Let me conclude with the following remark. I have used a variety of programming languages, including some off-the-wall cases like LabView graphical programming. In almost every case, I encounter some frustration with the language because I want to do something that it will not support. The sole exception is Mathematica. I have ALWAYS found a way to do what I want in Mathematica -- and quickly, assuming the reference book is handy. There are situations where I wish Mathematica had another way of doing something, but never has there been a case where Mathematica could not do it at all. In those situations I just fire off an e-mail suggestion to WRI and go my merry way. With other programs, I sit around wondering whether I shouldn't have tried it in Mathematica first. Mark Evans evans at gte.net