Re: General--Difficulties in Understanding Mathematica Syntax
- To: mathgroup at smc.vnet.net
- Subject: [mg69033] Re: General--Difficulties in Understanding Mathematica Syntax
- From: David Bailey <dave at Remove_Thisdbailey.co.uk>
- Date: Sun, 27 Aug 2006 01:24:12 -0400 (EDT)
- References: <echdk4$oir$1@smc.vnet.net> <ecmgpr$9b3$1@smc.vnet.net> <ecoqk2$39v$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
AES wrote:
> In article <ecmgpr$9b3$1 at smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gulliet at gmail.com> wrote:
>
>> Now, it is utterly better to use high-level constructs such as Map,
>> Thread, Apply, ... when you code in Mathematica.
>>
>
> I don't exactly quarrel with this -- but I sure don't fully accept it
> either.
>
> Concepts like Map[ ], Thread[ ], Apply[ ] are thoroughly understood by
> adepts, and marginally understood by some of the rest of us. They're
> not concepts, or terms, commonly used in everyday speech. And they may
> have some hidden subtleties in their operation, even some "gotchas", in
> how they apply to what's inside the [ ]s.
>
> Constructs like Do[] , If[ ], While[ ] are fairly likely to be
> understood not just by adepts, but by anyone who's ever done even very
> elementary programming in (horrors!) BASIC. Their programming use
> matches up pretty well with the same terms in everyday speech. They
> make the flow of the program logic more obviously visible (at least to
> us non-adepts). And I suspect they have fewer hidden gotchas.
>
> Writing complex Mathematica expressions as dense, deeply nested,
> sometimes lengthy expressions full of arcane shorthands ("\\@", etc) is
> akin to writing dense, arcane, possible lengthy prose sentences full of
> arcane terminology. Writing them as short, crisp, clear constructs, one
> task at a time, is like writing short, crisp, clear prose sentences.
> The people who construct "readability indexes" for prose have some
> opinions about this.
>
> [We all, of course, fondly remember APL: "Code once, read or modify
> never".]
>
> What is it that's actually **better** (for the "ordinaryt user") about
> these more sophisticated constructs?
>
> * Readability? -- except for adepts, I don't think so.
>
> * Faster, more efficient execution? -- perhaps so, but in the vast
> majority of cases, who cares?!?
>
> * More accurate execution? -- I sure hope not.
>
> * Shorter code (fewer characters)? -- again, who cares?!?
>
> * Bragging rights (I can accomplish the task with fewer characters than
> anyone around)? -- Well, that was a very salable skill, in magnetic core
> and assembly language days.
>
> Again, to each his own. Part of the genius of Mathematica is that it
> serves the novice user and the sophisticated adept. But "better"?
>
I agree with AES on this 100%. One problem with functional programming
is that it reduces easy problems to one line but leaves a novice with
little idea how to tackle a slightly more substantial problem - say one
with boundary conditions which mean the edges of an array need to be
treated differently. Of course there are ways to solve these problems
functionally as well, but they take a lot more experience and are not as
elegant. I teach both functional and non-functional approaches and point
out the advantages of each.
Yes, explicit loops are less efficient in Mathematica, but you can do
very sophisticated work with Mathematica without ever being troubled by
speed of execution.
David Bailey
http://www.dbaileyconsultancy.co.uk