Subject: Re: Curious about functional programming From: Erik Naggum <erik@naggum.net> Date: 2000/07/22 Newsgroups: comp.lang.lisp Message-ID: <3173275744603505@naggum.net> * The Glauber <theglauber@my-deja.com> | My superficial observation is that Lisp users seem to be more | tolerant of side-effects in their programs than Scheme users. Side-effects in programming is a side-effect of programming with stateful objects. In its purest form, and certain Schemers want nothing less, Scheme eschewes statefulness and hence objects that have state information. This is one of the reasons it is often impossible to talk to Schemers and Scheme is useless for more than embedded languages that do all the side-effects behind the scenes. | I think you can do functional programming in imperative languages too, | and some of the things that are considered good coding in object- | oriented programming (short methods, "getter" and "setter" methods to | access members, etc) are a step towards functional programming. I consider object-oriented programming antithetical to functional programming. What do you do with an object that changes state or, more broadly, maintains some information about itself that may be modified by "methods" on it? In functional programming, you would return a new object. In object-oriented programming, other users of the same object would see the change. Object-oriented programming relies on object identity. Functional programming relies on objects not being referenced by anyone else. | Is F.P. an idea that's still considered important? Is it important | for Lisp programmers in "the real world"? As with all theoretical approaches to the real world, you always get something really important out of every theory that has been built from observations of the real world, but when the theory starts to depend more on the egos of the creators than on reality, however one defines and relates to it, it quickly loses its appeal to any others than its believers/investors. I view functional programming as an attempt to solve certain hard problems -- not those of application, infrastructure, modeling, human requirements, etc, but in the design of languages -- a consequence of which is that certain programming paradigms emerge and prove themselves worthy of examination and the occasional use, but 100% pure functional style is simply useless: If you have no side-effects, you have no effects on the real world, which has the same identity before and after your side-effect-free program. Taken to its extreme, side-effect-free programming would mean you had to create a new universe with every computation. Now that we've established that there has to be _some_ side-effects, the question is no longer whether they are good or bad, but _which_ are good or bad. The functional programming languages I have used and studied have not let me make that decision myself, but rather have tried to force me into accepting somebody else's choices. I don't think this is a particularly useful approach to programming paradigms, and I don't want to work against the languages I use. #:Erik -- If this is not what you expected, please alter your expectations.