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>