Mathematica 9 is now available
Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: RE: Re: General--Difficulties in Understanding Mathematica Syntax

  • To: mathgroup at smc.vnet.net
  • Subject: [mg69123] Re: [mg69074] RE: [mg69033] Re: General--Difficulties in Understanding Mathematica Syntax
  • From: "Chris Chiasson" <chris at chiasson.name>
  • Date: Wed, 30 Aug 2006 06:34:32 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

Another system and its add-ons have intrigued me for a long time because
their notebooks really do look close to sets of equations an engineer
would write on a sheet of paper. However, I do not think that it
is actually a serious long term threat to Mathematica because it is
not oriented toward programming - which you always end up doing no
matter how good the interface and basic functions.

The more serious threats come from open general purpose programming
languages. One of the baddest is Microsoft's C# & the whole rest of
the .NET platform. Even though C#'s basic libraries are closed, the
language itself is open to be implemented by Free Software folks.
That's why its uptake has been so quick relative to Java and Java is
starting to be open sourced to compete with .NET. Also, XSLT is
another contender; it is weaker than Mathematica syntactically (but
even stronger than C# in openness and standardization). XSLT even has
a functional programming library. If XML & XSLT were simplified to
remove attributes, they would be a lot like Mathematica.

what C# code looks like - http://www.codeproject.com/cs/algorithms/

some screenshots from the mono C# project -
http://www.mono-project.com/Screenshots

Of course, I'll stick with Mathematica and its present licensing
scheme as long as I need it. Other language syntaxes still look
retarded to me compared to Mathematica syntax, but I know I'm biased.

On 8/29/06, robert.prince-wright at shell.com
<robert.prince-wright at shell.com> wrote:
> This thread is an important one for the folks at Wolfram who are after al=
l going to work to make a living by selling licenses. I was talking with an=
other engineer last week about the kinds of work we did. I have stuck with =
Mathematica and resisted the path to other maths packages despite the fact =
that the vast majority of engineers have taken the 'easy' route. This has l=
eft me stranded in some ways since there is now a huge inventory of compete=
nt Math utilities - e.g. Roark and Young. Others have also increased the so=
phistication of their maths packages so that they can be used as a web inte=
grated solution engine, much like webMathematica.
>
> One of the key benefits of the alternatives (I am told) is that they are =
easier to understand and there is more commonality with the normal Windows =
environment. I have to say after using Mathematica for research and having =
used it to teach the Applicable Mathematics course at The University of Gla=
sgow (1990) I can easily say I hated using the well know alternative when I=
 returned to Industry - unfortunately I was the only one in the office.
>
> I would guess that Wolfram would argue that Mathematica is aimed at a dif=
ferent market and there is some truth in that, however, having spent some t=
ime this morning looking at the competition I wonder if Wolfram are on a ri=
sky path since it's starting to look like Apple vs. Microsoft in the 90s.
>
> I think most would accept that David is correct in that the functional pr=
ogramming approach in Mathematica can result in code that is very difficult=
 to read first time over. I end up having to unwrap the experts code when e=
ver I'm looking to tap into Mathsource. Every now and then I am amused at h=
ow crafty some of you are when compacting code. The problem is not their co=
de, nor the syntax, it's the fact that Mathematica makes it difficult to un=
derstand what's actually happening as, for example, we MapAll, MapThread, e=
tc. a function onto a list, or list of lists. The current front end is stil=
l rather clunky and seems very underinvested. One simple way of helping peo=
ple up the learning curve (or reminding occasional users like me) would be =
to have an optional window which dynamically shows a Short version of the e=
ffect of what were typing in. This would save people like me from having to=
 repeatedly evaluate the complete expression in order to understand exactly=
 what the outcome !
> will be. Something akin to the Java applet that animates Map, Apply etc.
>
> We all know that Mathematica 6.0 is coming and one can only imagine that =
the next quantum step in Mathematica is being delayed to align with Windows=
 Vista - I'm just hoping that the 'next step' (bad pun for oldies!) is goin=
g to provide better support for the next generation of Mathematica users. L=
et's hope the fact my current job is being implemented near a place called =
Dinosaur is not my fate.
>
> Robert
>
>
>
> -----Original Message-----
> From: David Bailey [mailto:dave at Remove_Thisdbailey.co.uk]
To: mathgroup at smc.vnet.net
> To: mathgroup at smc.vnet.net
> Subject: [mg69123] [mg69074] [mg69033] Re: General--Difficulties in Understanding
> Mathematica Syntax
>
>
> 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, on=
e
> > 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 tha=
n
> > anyone around)? -- Well, that was a very salable skill, in magnetic cor=
e
> > 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
>
>
>
>


--=20
http://chris.chiasson.name/


  • Prev by Date: Re: Re: change of default behavoir for workbench
  • Next by Date: RE: Re: General--Exponential simplifications by default
  • Previous by thread: Re: RE: Re: General--Difficulties in Understanding Mathematica Syntax
  • Next by thread: RE: RE: Re: General--Difficulties in Understanding Mathematica Syntax