Fortran (Was: The "does Python have variables?" debate)

[Rustom Mody]

On Tuesday, May 13, 2014 3:30:36 PM UTC+5:30, Chris Angelico wrote:
> Actually, even the file system can do some of this to you. I was
> checking lsof on one of my Linux systems a little while ago, and found
> that I had half a dozen old versions of a program, all with the same
> file name, all deleted. (When you unlink a running binary on Linux,
> the program keeps running the old version, and then you can put a new
> version in its place, with the same file name. Any new invocation will
> pick up the new binary; existing ones keep what they have.) So a
> program can unlink itself, write out a new version of itself, and
> happily keep going - letting new invocations take the changed version,
> safely. Again, not exactly self-modifying code... or is it? Again,
> tamed by boundaries.

Your lsof example looks like a rather typical case of ugly self-modifying code
Self-modifying code has many flavours; consider:

$ sudo apt-get upgrade apt-get

relatively harmless but self-modifying nonetheless

When its more invisible its more dangerous

# apt-get upgrade linux-image

My understanding of Mark Harris' original reference to 'self-modifying' is a more
standard, ubiquitous, ugly but indispensable example -- the use of the
interactive interpreter.

I write a function:
def foo()...
   ... recursive use of foo()

I then rename the foo to FOO but forget to rename the internal call
For normal file/module loading one would get a straightforward error message
At the interactive interpreter one gets massive confusion.

Does it mean we stop playing around in the interactive environment?
Hopefully not!
But there are pitfalls and its good to be straight about them.

As far as I can see, recursivity is the foundation of our field;
self-modifying code, self-reference (y-combinator) are just some of its
many faces:
http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html