In article <s6yg1wclykz.fsf@aalh02.alcatel.com.au> Chris.Bitmead@alcatel.com.au
(Chris Bitmead uid(x22068)) writes:
> So all you have to do is generate a unique name for each node, right?
> Just an incremental number perhaps.
Sure, but then I lose the ability to tell whether two trees
have the same value, because they no longer do. So I have to
write a value-comparison routine that ignores the tags.
Of course, I can solve that problem too. But that's not the point.
The point is this: Someone suggested that if we were just to use
a language with a particular set of features (high-order functions,
closures, and something else that I forget at the moment), we would
all realize how horrible C++ was. So I picked one example of such
a language and gave an example of a problem that is not easy to solve
directly in that language. I intended that example (and still do)
as an existence proof that that particular language is not perfect,
thereby gainsaying the claim that the mere existence of these particular
features will show that languages without them are wretched.
Now, of course I can solve these problems in that language if I change
the problems appropriately. That will be true of any language that is
Turing-complete. But the fact is that some languages encourage particular
ways of thinking about programming and other languages encourage
other ways, and I do not believe that any particular way of thinking
about programming styles has an absolute moral superiority over any other.
As yet another example of this, I imagine that an experienced Haskell
programmer would say that generating unique names for each node is
tricky, because doing so is not referentially transparent unless the
serial number of the next node to be generated is passed around the whole
program (I do not think Haskell has global variables, or any way of
imitating them, because they are not referentially transparent). So
I would probably be urged to adopt yet another solution in the name of
referential transparency.
Now, referential transparency is very nice indeed, especially when you're
trying to reason about programs and prove their properties. But
writing substantial programs that are referentially transparent requires
yet another dramatically different way of thinking about programming,
which carries its own set of advantages and disadvantages.
In practice, which of those disadvantages you are willing to accept in
trade for which of those advantages should depend on the context, which
includes the problems you're trying to solve, the problems you might
be trying to solve in the future, the support structure that is available,
the local culture, your own experience and taste, and so on.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
|