Fri, 28 Feb 1997 13:40:25 -0500 (EST)
On Fri, 28 Feb 1997, Jecel Assumpcao Jr wrote:
> > 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.
Agreed, I've seen worse..It was intersting to see what sources he quoted
> > 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...
Well, I'm lucky I don't teach. <g> (Well, a little here and there for
UNIX, but nothing that pays..) I like reading technical papers (which
is funny, I hated reading them in college) and papers on programming/OS
design/database concepts. However, I guess what bugged me so badly about
this was the fact is was "We can't verify 'open system' system..I'll
prove is, but I'll not really..just keep stating is over and over." That
is what bugged me mainly about it.
> > > [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).
True...I'll more then likely add his paper to my collect.
And I was a bit harsh. =) Just seems a reasonable concept if one
spends a few minutes to prove.
> 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:
[deleted turtle example]
> It is, however, much easier to prove that the first program works
> than that this one does.
Is "The Children's Machine" a book or paper. It's be interesting to see
what context it was put in. It's true the first program is easier to verify
but under most of the "try and true" rules of Computer Science one should
beable to take in account simple for the more complex case. (Granted it will
still be a closed system, but ideal one has some limits on the
functionality of the program, else you endup with Microsoft "Do it all
Office with Visual Basic embeded in it." Which seems a bit extreme.
> > 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.
Actually, if I remember right he was going the other way. each piece
of the program was a "closed system" that can be defined by finate state
machines, but when you link those systems together and spread them accross
a larger area and run them in parallel the system is harder to prove. Which
I fully agree...However, I think if given enough time one should beable to
define a set of stable inputs and should beable to expect a certian result.
(Otherwise large navy ships in the US would be in trouble..MASSLY parallel
systems all attempting to talk to each other..A beta-testers nightmare. =)
> > 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.
I like playing with theories, but I am more of a hacker myself. I can
solve problems in the "small", but I don't know how flexable my solutions
would be in the "large" without re-evaluating. However, that is normally
taken into account at design time. (Take AOL as a good example of the
programmers/company not expecting to be the number one ISP in the
US. Thus all the overhalls and redesigns taking place.)
> > [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 ;-)
At least Java contains string routines..UGH..I moved from Turbo Pascal at
home to UCSD Pascal at highschool.. Blech.. Some days I wish about 80%
of the langauges would die...And C is one of them sometimes. =)