"Good Ideas, Through the Looking Glass"

Some folks here might find this interesting:

  Abstract

  An entire potpourri of ideas is listed from the past
  decades of Computer Science and Computer Technology.
  Widely acclaimed at their time, many have lost in
  splendor and brilliance under today's critical
  scrutiny. We try to find reasons. Some of the ideas
  are almost forgotten. But we believe that they are
  worth recalling, not the least because one must try
  to learn from the past, be it for the sake of progress,
  intellectual stimulation, or fun.

    http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_origFig.pdf
    "Good Ideas, Through the Looking Glass"
    Niklaus Wirth

-r

···

--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

FYI, here is a quote which seems relevant to Ruby:

  Although the possibility of program modification at
  run-time was heralded as one of the great consequences
  of John von Neumann's profound idea of storing
  program and data in the same memory, it quickly turned
  out to enable a dangerous technique and to constitute an
  unlimited source of pitfalls. Program code must remain
  untouched, if the search for errors was not to become a
  nightmae. Program's self-modification was recognized as
  an extremely bad idea.

···

--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Technical editing and writing, programming, and web development

Rich Morin wrote:

FYI, here is a quote which seems relevant to Ruby:

  Although the possibility of program modification at
  run-time was heralded as one of the great consequences
  of John von Neumann's profound idea of storing
  program and data in the same memory, it quickly turned
  out to enable a dangerous technique and to constitute an
  unlimited source of pitfalls. Program code must remain
  untouched, if the search for errors was not to become a
  nightmae. Program's self-modification was recognized as
  an extremely bad idea.

That's a gross misinterpretation of the facts. Not on your part -- thanks for posting something interesting -- but on the part of many self-styled pundits. The fact that self-modifying code has its own set of problems doesn't meant that the code should not be pursued at all, any more than we should have stopped coding altogether the first time we realized there were such things as bugs.

Not only does self-modifying code still offer the benefits originally envisioned, but those benefits are finally being realized. The Java HotSpot VM is a good example of real-world use. When we are working with high-level languages to write portable code, we usually don't mind if the machine code changes on the fly according to provably valid rules.

Yes, indeed.

Wirth's criticism is probably valid in the context of developing code for tax accountants. But in the context of developing code intended to pass the Turing test, his criticism is completely fatuous. A well-know AI researcher once said something like: if our programs can't modify themselves, then they will never do anything very interesting. Was is Shank? Was it Minsky? I can't remember.

Regards, Morton

···

On Oct 16, 2006, at 8:40 AM, Jeffrey Schwab wrote:

Rich Morin wrote:

FYI, here is a quote which seems relevant to Ruby:
  Although the possibility of program modification at
  run-time was heralded as one of the great consequences
  of John von Neumann's profound idea of storing
  program and data in the same memory, it quickly turned
  out to enable a dangerous technique and to constitute an
  unlimited source of pitfalls. Program code must remain
  untouched, if the search for errors was not to become a
  nightmae. Program's self-modification was recognized as
  an extremely bad idea.

That's a gross misinterpretation of the facts. Not on your part -- thanks for posting something interesting -- but on the part of many self-styled pundits. The fact that self-modifying code has its own set of problems doesn't meant that the code should not be pursued at all, any more than we should have stopped coding altogether the first time we realized there were such things as bugs.

Not only does self-modifying code still offer the benefits originally envisioned, but those benefits are finally being realized. The Java HotSpot VM is a good example of real-world use. When we are working with high-level languages to write portable code, we usually don't mind if the machine code changes on the fly according to provably valid rules.

[snip] A well-
know AI researcher once said something like: if our programs can't
modify themselves, then they will never do anything very interesting.
Was is Shank? Was it Minsky? I can't remember.

Not that it's what you're thinking of, but I read "The Story of Mel" a
long while back ( The story of Mel ), and recall
this quote:

I had been hired to write a Fortran compiler for this new marvel and
Mel was my guide to its wonders. Mel didn't approve of compilers.

"If a program can't rewrite its own code," he asked, "what good is it?"

Fun little read, btw, though quite off-topic here.

---John

···

On 10/16/06, Morton Goldberg <m_goldberg@ameritech.net> wrote:

> I had been hired to write a Fortran compiler for this new marvel and
> Mel was my guide to its wonders. Mel didn't approve of compilers.
>
> "If a program can't rewrite its own code," he asked, "what good is it?"
>

Fun little read, btw, though quite off-topic here.

Metaprogramming is the new COME FROM statement.

;p

Martin