[Date Index] [Thread Index] [Author Index]
Re: Mathematica daily WTF
In article <ifmrvv$pim$1 at smc.vnet.net>, Andrzej Kozlowski <akoz at mimuw.edu.pl> wrote: > > anyway, it does not matter as far as the point I was making is concerned, > which is that the C-like structure of Mathematica procedural programs is > helpful to people (somewhat) familiar with C or Fortran. > I'd argue it is also extremely helpful to people who _think_ physically, or if you like procedurally, and who are primarily focused on solving problems that have an inherently procedural character. The successive steps (lines, cells, expressions) in a procedural program will very often state or mimic or reproduce what happens as a function of time in a dynamic system, or as a function of distance as a wave propagates, or mimic the flow of control in a complex system, or . . . As such, they simplify the process of _coding_ these programs; they _document_ and make readable what the program is doing, step by step; they make it easy to _insert later refinements_ inside the procedure (e.g., tests for current values or for exceptional cases at points within the procedure). All of these things are much more valuable to some of us in our use of Mathematica than the speed at which the code executes, or the brevity with which it can be typed. And none of this is to argue that many basic functions within the language (things like Fourier transforms, finding matrix eigensolutions, many others) should not be provided and used as pre-coded non-procedural routines within larger programs. I make a lot of use of self-programmed Modules in my own programming. The active or working part of the completed program, where numerical results get asked fror and results displayed, can be quite briefly written, mostly just setting input variables, then calling these modules. But these modules themselves are heavily procedurally coded internally, and I think that makes a lot of sense.