Registered: Sep, 2005
Re: functional/procedural schism
Posted: Sep 19, 2006 6:04 AM
> > > It's also true that we commonly
> > > work with declarative statements - recipes ask for
> > > yolks, how you get them out of the shell is
> > unspecified.
> > That's prefectly in line with imperative languages,
> > especially OO.
> Finally we can connect with Christopher Diggins'
> frequently stated concern about order dependence.
> The problem is that with imperative languages (including
> OO) we cannot be sure that the second time we say egg
> yolks produces the same result as our first call for egg
> yolks (some hidden state change may have scrambled our
> eggs in the meantime).
> With a declarative language egg yolks are egg yolks
> irrespective of when or how often we ask for them. (In my
> patchy understanding, in a functional language calling a
> function with the same parameters should always give the
> same result.)
Maybe the language doesn't guarantee this but you can make this the behavior of a factory, for example.
I was thinking of your recipe example here and really, there is no recipe that I have ever seen that didn't specify some order of operations. You can mix the eggs in after you've put the rest of the ingredients in the oven. And in the real world, eggs change state. Once scrambled, they do not magically return to an unscrambled state. You can't make a cake with eggs cooked sunny-side up. After you use your dozen, you have to go to the store to get more. In the manufacturing world, heat-treated parts are not equivalent to parts that are awaiting heat-treatment. Hole that is drilled will be there until it is filled with something.
It seems to me that the OO model is a much closer similacrum to our experience of the world than the functional model. A lot of the proerties of functional languages exist primarily for technical reasons (like the idempotent restriction you mention) not because they are useful or natural to the developer.