OO theory

[Jecel Assumpcao Jr]

> I've read the paper.  I have seen better papers.

I've seen many worse. I didn't like any of Wegner's previous
papers (starting with his August 86 Byte OO language taxonomy),
for example.

> It really did not contain any "new" information.  It was badly setup.
> If I would have been the Computer Science teacher and this was a paper
> that explained and extended a current topic.  It would have failed.
> But that is just "IMNSHO."

Wow, you're tough! I'm glad I didn't have a teacher like you :-)
But I think it is also a matter of taste - I like to write
informal papers like that too, while a lot of people hate it.
Those who love greek letters and squigly signs can always read
Luca Cardelli...

> > [Peter says you can't prove correctness]
> Incorrect,  Peter explains why Interactive Machines are hard to develop.
> Be them OO or procudural.  In a nutshell (VERY nutshellish!) it states
> that if you take *EVERYONE INPUT IN THE WORLD* and try to let the computer
> under stand it.  It's not posiable to verify such a machine via standard
> Turing concepts.  (Which is a no brainer.. =)

True, but just because it is obvious doesn't mean that many
people have already noticed this. I already knew this, but it
is nice to have a reference you can point people to (I haven't
seen many others).

It is interesting that I was reading "The Children's Machine" by
Papert just a few weeks ago and he said the same thing. He gave an
example of an algorithmic (closed) Logo program to make the turtle
go around a 100 by 100 square:

      repeat 4 [ forward 120 right 90 ]

If the turtle is not positioned just right initially, it may
fail to work. He then showed the following interactive program
that always works (including for most shapes besides 100 by 100
squares!):

      if touch.left then [left 2] else [right 2]
      forward 2

It is, however, much easier to prove that the first program works
than that this one does.

> However, the paper did hit on something that is critical.  Parts of this
> "Interactive Machine" are verifiable via Turing and Church's concepts. It's
> these pieces that when put in large projects with many inputs can't alway
> be expected to give accurate results (His airline example..Locking system
> on it would be interesting since it would require some type of "time-delay"
> seat locking so you don't overbook a plane).  Which is correct.

I don't remember the airline example, so maybe it's time for me
to read the paper again. But it seemed to me that he claimed that
the problem is that when you decompose a closed system, each part
might be an open system (which is hard to prove correct). So you
have to do "whole program" analysis to get results, which has
some nasty performance implications.

> However, I do believe that Tunes will endup the same.  You can verify the
> pieces of the puzzle, but I'm very interested on how the program written
> with these pieces on a parallel-distributed platform will work.

I am interested in the same thing. But I am a hacker, not a computer
scientist. So I am choosing some paths that work reasonably well
in practice, even if they don't work in theory.

> [Note, I agree with needed an OS/Programing Enviroment for secure
> programming, but I'm  not totally converted to "Tune will be it" concept.
> However, I don't believe JavaOS w/ Java programming langauge is it either,
> but at least Java is a step to a FULLY platform independent(sp)
> langauge.  Something we have needed for a LONG time...Even if it's "candy
> coated" =)]

I still remember some funny ads that showed how a 6800 programmer
had to become a hot dog vendor when his platform became obsolete,
and the Z80 programmer started selling peanuts. But our hero, the
UCSD Pascal programmer moved on to the 8086, 68000 and so on and
lived happily ever after! At least Java doesn't make you predefine
your file sizes ;-)

-- Jecel