Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!agate!ucbvax!bloom-beacon!ANTARES.MCS.ANL.GOV!boyle From: boyle@ANTARES.MCS.ANL.GOV Newsgroups: comp.lang.scheme Subject: Parity with conventional programs Message-ID: <8910020245.AA06270@solaria.mcs.anl.gov> Date: 2 Oct 89 02:45:58 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 35 It seems to me that one barrier to the wider acceptance of functional programming methodology, especially by scientists and programmers interested in applications, is the perception that functional programs *necessarily* sacrifice efficiency for simplicity, clarity, adaptability, etc. I also believe that the time is ripe to attempt to demonstrate that this is NOT the case--that one can write in the functional style and still obtain programs that execute as fast (or faster) and that use as little storage as do well-written procedural programs on the same hardware. I would call such a demonstration a "demonstration of parity" between functional and conventional programming. I believe that several demonstrations of parity on programs for solving real problems would remove a large barrier to the use of functional programming, and encourage applications scientists and programmers to consider fp on its (obvious) merits. How about some discussion on this topic? Does anyone out there agree or disagree with these sentiments? Is anyone out there working on demonstrations of parity, or better yet, has anyone achieved some? Terence Harmer (now at Queens University, Belfast) and I have been working toward this goal at Argonne over the past year using automated program transformation techniques. We are within sight of the goal for several specifications for numerical and non-numerical problems of practical interest. We express these specifications in pure Lisp (lambda calculus); some use higher order functions. We transform them into Fortran or C programs for sequential, vector, and/or parallel computers. We'd like to hear from others working along similar lines. Jim Boyle boyle@mcs.anl.gov