Re: Re: General--Difficulties in Understanding Mathematica Syntax
- To: mathgroup at smc.vnet.net
- Subject: [mg69031] Re: [mg69006] Re: General--Difficulties in Understanding Mathematica Syntax
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Sun, 27 Aug 2006 01:24:02 -0400 (EDT)
- References: <echdk4$oir$1@smc.vnet.net> <ecmgpr$9b3$1@smc.vnet.net> <200608260604.CAA02766@smc.vnet.net> <54B808EB-0990-4D9B-A310-33F14AAF73BE@mimuw.edu.pl>
- Sender: owner-wri-mathgroup at wolfram.com
On 26 Aug 2006, at 11:23, Andrzej Kozlowski wrote:
>
> On 26 Aug 2006, at 08:04, 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 don't really disagree with you but I also find your comments
> somewhat.
Those horrid gremlins got me again :-( It should have been "I also
find your comments somewhat incomplete".
Andrzej Kozlowski
> I think the answer to the question: is it much better to use
> functional rather than procedural programing depends above all on
> what you are doing. I am doubtful that your view correctly reflects
> the "vast majority" of Mathematica users.
> For some purposes, for example, when you want to implement quickly
> in Mathematica an algorithm written in some sort of pseudo code in
> some book on algorithms, and many other similar purposes,
> procedural code will generally be much more convenient. It indeed
> corresponds better to the way normal processors work and therefore
> it is use din almost all books on algorithms etc.
>
> For purely numerical purposes, provided your program can be
> compiled, you can often achieve pretty satisfactory results with
> procedural code (but note that it is very hard to make use of
> Mathematica's ultra-efficient numerical methods like packed arrays
> or SparseArrays unless you have use functional programming. This
> may not be important to you but judging by the posts to this list
> people who do not care about the speed of execution of their
> numerical code are not "the vast majority of cases".)
>
> Finally, the area that interests me most and where I have the most
> experience: symbolic algebra. Here I have no doubt that "algebraic"
> languages (which for the sake of argument we can identify with
> "functional") like Lisp, ML or Mathematica, etc., are vastly
> superior to procedural ones. Just remember that you can map a
> function not only onto a list but onto any algebraic expression.
> Here is a silly example I just made up on the spot and which is not
> supposed to have any significance besides showing the kind of thing
> that would be pretty hard do accomplish in a non-functional language:
>
>
> (If[#1 >= 3 && PrimeQ[#1], #1^2, #1] & ) //@
> (7*x^2 + 3*y^4 + 2.5)
>
> 9*y^4 + 49*x^2 + 2.5
>
> This may be of little interest to those users not interested in
> symbolic algebra, but if they are not interested in it than I am
> not exactly sure why they use a Computer Algebra System rather than
> an ordinary programming language, like, for example, Basic.
>
> Andrzej Kozlowski
>
>
>
>
>
- References:
- Re: General--Difficulties in Understanding Mathematica Syntax
- From: AES <siegman@stanford.edu>
- Re: General--Difficulties in Understanding Mathematica Syntax