Re: OO versus RDB

Tony D wrote:
> Marshall wrote:
> > What my job is has no bearing on whether arguments about
> > which definition of a term is right are interesting or not. Such
> > arguments are always uninteresting. It is the semantics behind
> > them that are interesting.
>
> How can you discuss semantics if you can't agree on what you're
> discussing the semantics of ?

You can't discuss *anything* if you can't agree on definitions. However that was not my point.

> Definitions are important; that's why we
> have so many bunfights in these newsgroups about them.

No. *Agreeing* on definitions is important; the specific definitions themselves are unimportant. We can pick out any collection of phonemes and use them to describe any particular semantic principle or abstraction or whatever. It doesn't matter; all that matters is that we agree. If two people are discussing what the effects of writes to variables are on return values, it doesn't matter if they call it "purity" or "referential transparency" or whatever. However if they are arguing with each other about what a particular term "really means", they have left the path of wisdom.

For example, I don't know what a "bunfight" is; it suggests to me two underclassmen arguing about who gets the last dinner roll.

The point is, many terms have different meanings in different contexts. There are nuances. The semantics of the nuances are probably quite important. This does not then translate in to there being a "correct" definition and an incorrect one. We can evaluate definitions only on utility, and that utility is likely to be context-dependent. Hence I am utterly uninterested in whether the C sense of "function" is more "right" than the mathematical one, or the Haskell one, or whatever.

> If we're discussing a "function" which always writes a predictable
> value based on the inputs to a global variable, this "function" could
> still be termed both pure (the output always depends solely on the
> input) and referentially transparent (that is, the function body could
> be written in line with the parameters substituted with no change of
> overall meaning, or another way, the same "net effect"). However, I
> would still deny that this subroutine is a function, because it is
> producing more than one output; you would have to consider the output
> to be both the return value *and* the updated store, especially if
> you're in a language like Pascal or C which exist to describe store
> changes. (As a side note, I would also remark that when I was learning
> Pascal it was considered exceptionally bad form to have a function
> alter anything in store; a function was there to compute the returned
> value. If you wanted to return more than one value, that was a
> procedure. This was, however, only a stylistic consideration, although
> I think a function that had the kind of side effect we're talking about
> here would be considered a nasty surprise by many.)

All this is just you saying what your preferred definition of "function"
is. Fine.

> And as Adrian said,
> if your "functions" create side-effects, you both inhibit the ability
> to safely optimise your code, you create possibly unexpected
> interactions with short circuit evaluation, you could find interesting
> issues with an overambitious optimiser, etc. etc. etc.

The last point is a nutty one: if the compiler has bugs, of course all bets are off.

> "Side effects" (as in changes to global variables) are bad news; they
> have been known and considered as such in imperative languages for many
> a long year. There are a few circumstances where they make sense in
> that environment, but they are still to be discouraged.

Sure.

> Also, you mentioned in an earlier post that your description of a
> function fitted with the mathematical definition of a function. Which
> mathematical definition of a function describes side effects ?

The very question fills me with ennui and lassitude. Such an uninteresting issue to consider. In any event, none of them do, but I didn't say that they did. However they don't exclude the possibility either.

Please remember: my only points were

1. A parameterized abstraction (by whatever name) that contains writes to variables but no reads has its return value determined exclusively by its inputs, despite the writes.
2. This is useful to know [and as a side matter:]
3. People get quite fired up when you point out item 1).

Is there any non-terminological disagreement with any of these points?

As to what we call any of these issues, I just don't care. Any name will do.

Marshall Received on Mon Jul 10 2006 - 05:05:20 CEST