Subject: Re: Curious about functional programming
From: Erik Naggum <>
Date: 2000/07/22
Newsgroups: comp.lang.lisp
Message-ID: <>

* The Glauber <>
| 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.

  If this is not what you expected, please alter your expectations.