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