Re: s-exprs + prototypes

["Felix Klock's ll1 list proxy" <address@hidden>]

On Tuesday, June 24, 2003, at 12:22  PM, Christopher Barber wrote:

>
>>> Not allowing objects to have mutable state would weaken
>>> the object
>>> metaphor to the point where the average programmer would find it hard
>>> to grasp.
>>> The way humans perceive the real world, objects can and do have
>>> mutable state.
>>
>> I think that many functional programmers (myself included) believe 
>> that
>> functional programs are easier to reason about because they may 
>> easily be
>> understood as the composition of many separate pieces.  That is, when 
>> I want
> to
>> understand the behavior of an object receiving a message in a world 
>> with
>> mutable state, I must consider all possible states of the object.
>> If this object refers to other objects, I'm really stuck.
>
> Then you are stuck for many common programming tasks: anything 
> involving
> interaction with system objects such as file or window handles, or 
> other
> external objects such as ActiveX objects, etc.
>
>> A purely functional call, however, depends only on its inputs.
>>
>> There's a reason that mathematics is mathematical. I think that 
>> computer
>> programming should take this approach as well.
>
> But most programmers are not mathematicians, nor are most programming 
> tasks
> particularly mathematical in nature.
>
> There is no question that the functional idiom is mathematically 
> elegant.  It
> just just doesn't map very well to how most people think.

I've seen this argument used a lot in forums like this (heck, I've used 
it myself quite a few times), but I just noticed one problem with it: 
how good are people at thinking about what *other people are thinking* 
?  I suspect that we muddle along well enough to get by in life, but no 
one has really developed a good mental model for how the human mind 
itself manages to muddle along so well!

This is relevant because we need to ask ourselves: is the primary 
purpose of a formal language to be read (and comprehended by a human 
mind), or written (and executed by some other automata that is capable 
of reading the script)?

Languages that "map well to how most people think," it seems to me, 
often excel at being written down, but when it comes time for another 
human being to take an arbitrary human-composed script and make sense 
of what it is doing, then (sometimes) there exists no other solution 
for the human except to manually execute the script, doing the same 
actions that a machine would perform, making no high level leaps of 
intuition except for (perhaps) applying some mental abstraction 
function to make the computational state map onto some abstract model 
of the problem state.  Perhaps this is *because* the language was 
designed to map well on how people think, and so we have no better 
chance of making sense of it than of any other semi-irrational human 
being.

Is this true of languages that have been designed to be read and (more 
importantly) reasoned about?  Certainly you can construct cases where a 
reader would again have no other choice but to emulate the interpreter 
("You can write bad code in any language").  But my question is, what 
kind of code is the language *encouraging* you to write?

I'm not really trying to argue the side of Functional Programming at 
this point.  Perhaps FP is a case of OVER-optimizing for reasoning and 
analysis, increasing the cost of writing the program (using Monads or 
what not) beyond the acceptable level.  But now I'm curious as to 
whether there's any merit in exploring this relationship between the 
language/human-thinking mapping and overall code maintainability.

-Felix

p.s. at this point I can see why Brian T. Rice was calling this thread 
a waste of bandwidth.  I don't suppose we can just call the 
object/function fundamentality debate a religious one?  Then all the 
contributors could be known as Fundamentalists!