
How Recursion Got into Programming (2014) - headalgorithm
https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/
======
gumby
It was hard for a moment to get my head around the idea of static activation
records. That makes “procedure call” simply into a goto. I guess I tend to
write assembly code this way though.

Ironic that almost 20 years later the idea of dynamic activation had been so
well absorbed that it was possible to write an influential paper all about how
procedure call (and lambda) could be considered a goto (via tail recursion)!

~~~
Stratoscope
Yes, imagine that a function looks like this in memory:

    
    
      +-----------------+
      | return address  |
      +-----------------+
      | executable code |
      +-----------------+
    

The way you call a function is to store your desired return address in the
first slot, and jump to the code in the second slot. The function jumps to the
saved return address when it's done.

We did it this way for years.

Now given that mindset, how could you even contemplate recursion? Where would
you put all the return addresses?

~~~
Sniffnoy
What's a little confusing here is that they talk about "static allocation" vs
"dynamic allocation"; but these days, use of the stack is referred to _as_
static allocation! Even if it's not as fully static as the old way. The shift
in terminology makes the old debate opaque for the modern reader, and without
your comment (and some similar ones) I wouldn't have known what was going on.

~~~
kragen
I haven't seen that usage anywhere.

~~~
gowld
Sniffjoy is referring to static allocation of local variables on the stack (vs
dynamically on the heap), not static allocation of the stack itself.

~~~
kragen
Referring to stack allocation as "static allocation" is just not something
I've seen before. I suspect you're simply in error; maybe you misheard someone
saying the phrase "stack allocation", or you've been talking to somebody who
misheard it that way. You _can_ statically allocate a local variable in C, for
example:

    
    
        static char *err = NULL;
    

But that specifically does _not_ allocate it on the stack. Both heap
allocation and stack allocation are dynamic, not static.

There _are_ things that are a bit more of a gray area in C and Unix and
Win32/64 — are "statically allocated" variables of a shared library really
statically allocated if they aren't there when the program starts up and they
may be at some unexpected address? — but this is not one of them.

------
ookdatnog
I took a History of CS course in college, where this controversy was
discussed. The way I understood it, the two camps approached the question of
what ALGOL should be slightly differently.

One camp (against recursion) was trying to design a language that would be
productive for programming in the (then) here and now, with the machines they
had at the time; in other words, the language is molded after the machine.
Since efficiently implementing recursion wasn't well understood at the time,
adding it to the language was a no-go for them.

The Dijkstra side of the argument was that the language should be designed to
be as elegant as possible, without much concern for the limitations of the
machines of the day. The idea was that, once a broadly accepted programming
language was designed, computer designs would follow to support it.

I think both are valid viewpoints (especially in context), although with
perfect hindsight Dijkstra et al seem to have been the more prescient side.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=8073361](https://news.ycombinator.com/item?id=8073361)

also 2015:
[https://news.ycombinator.com/item?id=10131664](https://news.ycombinator.com/item?id=10131664)

------
_bxg1
It's strange to me that recursion wouldn't just naturally fall out of any
language design that has a call stack. Even if you forbid the current
procedure from calling itself, it could achieve the same thing by having two
functions call each other.

~~~
ken
As the other comments here said, languages at the time did not generally have
call stacks. It'd probably be more accurate to say that languages like Algol
got call stacks _because_ they were needed in order to implement recursion.

------
mtreis86
Turing's paper in 1939 describes a machine whose operation is recursive.

~~~
tuyiown
Well, the infinite memory tape was quite a concern for actual programming

------
bArray
How Recursion Got into Programming (2014)

[https://vanemden.wordpress.com/2014/06/18/how-recursion-
got-...](https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-
programming-a-comedy-of-errors-3/)

------
gowld
It's more accurate to say that recursion got into recursion.

------
woliveirajr
There's some discussion here:
[https://news.ycombinator.com/item?id=23061881](https://news.ycombinator.com/item?id=23061881)

------
chadlavi
it did it by getting into programming

~~~
Aperocky
but how

~~~
taneq
Well, it all started when they used recursion.

~~~
eru
It's useful if your recursion does some work before recursing. (Just like your
loop bodies should do something.)

~~~
smabie
What's interesting is that church numerals don't do anything except "recurse."
So calling a function that does nothing is useful after all!

~~~
eru
Church Numerals apply the function you give them, n-times. That's hardly
nothing.

------
bregma
Very poorly worded title, but I guess it's more click-baity than "A History of
the Personal Politics Involved with the Promotion of Alternative High-level
Computer Programming Language Designs Among European and American Academics in
the 1950s and 1960s". Maybe a little too dry?

