Re: Function vs. Procedure
- To: mathgroup at smc.vnet.net
- Subject: [mg37127] Re: [mg37114] Function vs. Procedure
- From: Alexander Sauer-Budge <ambudge at MIT.EDU>
- Date: Sat, 12 Oct 2002 05:04:51 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
There is indeed a logical and fundamental difference, but not in what
can be done, as all "complete" languages are "equivalent" in terms of
what can be done with them (it all has to become machine code
eventually). But this nuts and bolts equivalency is hardly the whole
story, as I don't think any of us would want to dig a tunnel with a
spoon just because it is possible, and similarly, I am sure there is a
reason why you are using Mathematica and not assembly language.
As some linguists have postulated in the context of human languages,
languages might effect our ability understand the world and reason
about the world (and thus solve problems). This should be clear from
your experience with mathematical notation-- a good notation can help
you solve problems by revealing symmetry and structure (at least in the
sense of patterns). In this way functional programming languages *tend*
to represent computation at a much higher level than procedural
programming. For example, adding the elements of a vector in a
functional language style, "Fold[Add,0,vector]" , focuses on the
conceptual fact that we are contracting a vector with an addition
operator, while a procedural style, "sum=0; Do[sum = sum + vector[[i]],
{i,1,Length[vector]}]" focuses on the mechanics of summing. There are
benefits to both styles and much much more to the story than I've
indicated here (like issues of verifying that a program is correct, or
at least won't crash the computer or run forever, as well as
reusability, parallelization, memory management, and on and on,
efficiency).
Although I am certainly not an expert in this area, I suggest a
reasonable place to start would be what functional programming
advocates consider their classic manifesto, which you can access by
clicking on the title "Can Programming Be Liberated from the von
Neumann Style?" of the following discussion:
http://lambda.weblogs.com/discuss/msgReader$4172
You can find much more information about functional programming and
language design in general through this web log if your interested. I
also found the article below to be very interesting
Paul Hudak, "Conception, Evolution, and Application of Functional
Programming Languages," ACM Computing Surveys, September 1989, Volume
21, Number 3, p.359-411.
As far as why, when and where to choose one approach over another: in
general, you need to by informed of advantages and disadvantages of
different styles, know how to program in different styles, and have
good representative languages from different styles available to you so
that you can choose, to the best of your ability, the best tool for the
problem. For any given language, you should use it as it was design to
be used, since languages, like it seems for all engineered things, tend
to be quite fragile when used in ways they weren't design to be used
(if you've programmed in C, think about how much trouble you can get
into with the preprocessor macro facility if you are not careful).
As far as Mathematica is concerned, you can choose either style in many
cases, but I feel that Mathematica in many ways is a naturally
functional programming environment, with its use of first-class
functions and its basic building blocks being constructs like Fold,
Map, etc., so I approach it as such. I am actually still learning
Mathematica, but I think the book supports my feeling because it says:
"Functional operations provide one of the most conceptually and
practically efficient ways to use Mathematica. "
Alex
On Thursday, October 10, 2002, at 03:20 AM, Steven wrote:
> Is there a logically fundamental difference between functional and
> procedural programming? What I mean to ask is, can we do exactly the
> same
> thing with purely functional approaches as we can with purely
> procedural
> approaches?
>
> Is this basically the recursive verses iterative distinction?
>
> Why would one chose one approach over the other?
>
> STH