MathGroup Archive 2002

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

Search the Archive

Fw: Re: Mathematica is NOT a functional language

  • To: mathgroup at smc.vnet.net
  • Subject: [mg37732] Fw: [mg37708] Re: Mathematica is NOT a functional language
  • From: "Hermann Schmitt" <schmitther at netcologne.de>
  • Date: Sun, 10 Nov 2002 05:38:34 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

Hello,
Excuse me, that I state some simple thoughts, being in contrast to the
 thorough insight of Orestis:
If you look at the statements of Jens-Peer in a general way, you may state,
Jens Peer proposes subroutines as the way to structure programs. That the
subroutines are called functions in this case is rather irrelevant.
This leads to the conclusion:
Oh what revelation: This is always the starting point of OOP, because the
OOP fans think that using objects leads to better programs than using
subroutines.

 Hermann Schmitt

> ----- Original Message -----
> To: <mathgroup at smc.vnet.net>
> Sent: Saturday, November 09, 2002 6:29 AM
> Subject: [mg37732] [mg37708] Re: Mathematica is NOT a functional language
>
>
> > Jens-Peer Kuska <kuska at informatik.uni-leipzig.de> wrote in message
> news:<aqfpm3$7eu$1 at smc.vnet.net>...
> >
> > I would be grateful if you answered with some concrete arguments on
> > the fundamental functional character of the Mathematica language.
> > Telling this group how you 'feel' about the Mathematica language is
> > not very helpful. This is a technical issue, after all.
> > Orestis Vantzos
> >
> > > Hi,
> > >
> > > Mathematica allow many programming concepts.
> > > Because it should be used by as many persons
> > > as possible and all these persons should pay for
> > > a Mathematica license.
> > >
> > > It is not a good idea for a commercial product to
> > > force the customers to learn functional/logic
> > > programming if these cutsomers have 10--20
> > > years of programming experience with FORTRAN 77
> > > (as the most physicist have).
> > >
> > > Deep in it's internal structure Mathematica
> > > is a functional/logic language and a functional
> > > logic language uses functions, patterns and
> > > transformation rules *and* it is optimzed
> > > to do this.
> > >
> > > If someone like it, he can use Do[], For[] and
> > > Goto[] as in a FORTRAN program. This
> > > will not make Mathematica to a imperativ/procedural
> > > language.
> > >
> > > OOP is developed for simulations and
> > > graphical user interfaces where the objects
> > > *must* have its own life like a window on screen
> > > or a car in a traffic simulation.
> > > This concept is very clear realized in Objective C
> > > or Eiffel.
> > >
> > > Every programming languagage has its own taste
> > > and flavor. The taste and flavor of Mathematica
> > > is functional/logic and if someone can't exist
> > > without the object oriented flavor he should
> > > stay away from Mathematica.
> > >
> > >
> > > Regards
> > >   Jens
> > >
> > >
> > >
> > >
> > >
> > > Orestis Vantzos wrote:
> > > >
> > > > [I know what you're thinking; this guy is nuts!]
> > > > Anyway, Jens keeps attacking the whole OOP-Mathematica idea based on
> > > > the single premise that 'This is a Functional Language'. He even
does
> > > > it in a rather abrupt manner, which I do not appreciate.
> > > >
> > > > Well guess what; Mathematica is NOT a functional language. It can
> > > > definitely be used like one.But...
> > > >
> > > > a) Wolfram in the Mathematica Book seems to suggest that Mathematica
> > > > is primarily a rules-based language...in A new kind of Science this
> > > > assumption is even stronger.
> > > >
> > > > b) Symbols and rules are the fundamentals of Mathematica.
> > > > Symbols have UpValues and DownValues (and OwnValues,etc. but let's
> > > > keep it simple).
> > > > It is true that an evaluation of the expression s_Symbol[args___]
can
> > > > be thought of as 'the function s is applied to the subexpression
> > > > Sequence[args]'.
> > > >
> > > > This is ONLY a metaphor!!!
> > > >
> > > > What really happens is that the symbol s is called upon to apply its
> > > > transformation rules stored under DownValues on the expression. This
> > > > is the ONLY objective description of the process. Everything else is
> > > > an assumption on part of the programmer.
> > > >
> > > > Moreover, UpValues completely throw the functional metaphor out the
> > > > window:
> > > > in this case s_Symbol[x_Symbol,rest___] is transformed not according
> > > > to the 'function' s but according to the UpValues of 'argument' x !!
> > > >
> > > > So Jens, LISP is a functional language, since its fundamental
> > > > structures are function-based. Mathematica is just a darn good
> > > > simulation of a functional language. So good, that we have learned
to
> > > > ignore that it is only a facade.
> > > >
> > > > People like me are trying to build a different interpretation of
what
> > > > all these symbols and rules are doing (or can be persuaded to do)
> > > > inside Mathematica. You look at symbols and see functions; I look
and
> see
> > > > objects. An OOP package will only be a 'simulation', since
Mathematica
> > > > is not inherently OO, but I repeat that all the talk about
functional
> > > > programming in Mathematica is no better in any way.
> > > >
> > > > Rules and symbols are real; the rest is a mindgame.
> > > >
> > > > Regards,
> > > > Orestis Vantzos
> >
>



  • Prev by Date: Re: Representing integers as sums of 3 squares
  • Next by Date: Symbolic Inequality Solving
  • Previous by thread: Re: Mathematica is NOT a functional language
  • Next by thread: Spline Arc-Length and Even Sampling