Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subroutine calls in the ancient world, before computers had stacks or heaps

devblogs.microsoft.com

Post reply on HN
Print view View original

71–80 of 241 posts

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#71

Post by mannyv »

munificent wrote: post #34
autoexecbat wrote: post #24

Earlier quoted context omitted.

Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell

This opinion is totally wild to me. Do you never work with tree data structures? I can't think of a non-trivial program I've written in the past two decades that didn't have some recursive tree traversal in it.

Recursion in production code is bad news, because you can't control the depth of your call tree.

At some point you will crash because the runtime won't be able to allocate any more stack. And you can't preflight it because if you could preflight it you wouldn't be doing recursion.

Recursion is a nice toy, but in real life it's a ticking time bomb.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#72

Post by le-mark »

Cobol upto and including the 85 Standard was stackless and heapless which is quite a cognitive divide. For those going to and coming from that language.

I didn’t read Raymond say anything about security in the present article, but the advantages a clear. No stack or buffer overflow vulnerability for example.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#73

Post by layer8 »

lenerdenator wrote: post #50
082349872349872 wrote: post #2

Note that before we had arbitrarily extensible heaps, programmers always did at least a little engineering, in that they had to consider the probable distribution of inputs and size* all their intermediate storage appropriately. * giving rise to "BUGS AND LIMITATIONS "

Really, the mistake was letting humans provide input to computer programs.

In particular input to assemblers, compilers, and interpreters.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#74

Post by samatman »

CyberDildonics wrote: post #68
Joel_Mckay wrote: post #23

Earlier quoted context omitted.

Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)

I agree. People love making things clever instead of making things done. Recursion for iteration is just more complicated iteration. I've never seen a good argument for it in modern programming, it just ends up being the classic backwards rationalization of something people want to believe. Recursion for traversing a tree is just using the call stack as a stack data structure. Any balanced tree is never going to exce…

The same argument suggests that a recursive stack traversal will never consume more than 64 stack frames, so consuming stack frames is no reason not to use a recursive function.

It's just as easy to limit recursion depth, if you need to, just pass along a counter and check it. I haven't found that hand-rolling a second stack, instead of using the program stack, is easier to debug, the opposite if anything, but your mileage may vary on that one.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#75

Post by Toorkit »

gigel82 wrote: post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

If that had been the way it was intended, I think it would have been phrased "stacks and heaps."

I.e. "the ancient world had stacks and heaps" as opposed to "the ancient world had stacks or heaps," which sounds weird.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#77

Post by HeyLaughingBoy »

A long time ago (1991 maybe?) one of my first freelance projects during my first job out of college was to design an RS232 serial multiplexer -- take an incoming serial datastream, parse it, and redirect it to one of n outputs based on its header.

I remember doing something similar to what he describes. My hardware design was basically a Z80, a 2716 EPROM (I may have also had a Parallax EPROM emulator to speed debugging) and a couple of Z80-SIO serial devices. Notice that there is no SRAM chip :-)

The Z80 has enough registers that I could hold all the data I needed internally so I decided against the extra cost of RAM. This was the early 90's, remember. The one thing I was missing was a stack to make function calls. This was done (memory is fuzzy here) by preloading the return address onto a register pair and then calling the function. When the function was done, it would do an indirect jump to the location held in that register pair, which would return to the next instruction after the call.

I don't remember how I passed and returned values, but I probably dedicated a register to that. I have a couple of old hard drives around here somewhere. I should see if I saved the code anywhere; I was quite proud of it.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#79

Post by anthk »

howerj wrote: post #67
anthk wrote: post #47

Earlier quoted context omitted.

I was about to talk about subleq, but it's damn difficult even to write a "Hello world".

Yeah, it really is a pain to do anything in it. I got around that by writing in another language instead as soon as possible. You can paper over many issues with a VM, although it will slow things down on such limited computers.

How does muxleq work? It looks like a 'concurrent' subleq...

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#80

Post by 082349872349872 »

layer8 wrote: post #73
lenerdenator wrote: post #50

Earlier quoted context omitted.

Really, the mistake was letting humans provide input to computer programs.

In particular input to assemblers, compilers, and interpreters.

I once wrote a 16-bit assembler as a recursive function, which emitted code and fixed data on the way down and patched in relative offsets on the way back up.

In principle, one might worry about blowing the stack, but as the sole purpose of this function was to assemble at most a half-k boot sector, in practice they fit.

Post reply on HN